Best of all, they reached back into ancient history, and asked me to moderate a panel Friday, September 9th, from 10:15 – 11:15, entitled Moving Into the Cloud – Practical Experience.

We will four great panel members:

• Fred Whiteside, NIST; who will focus on the Government policy issues
• Wolf Tombe, Customs and Border Protection, DHS; who will take the perspective of the Government implementor
• Bob Hansmann, Blue Coat; who will discuss what it is like to be a commercial provider supporting cloud initiatives
• Dmitry Sokolowski, BAH; who will talk about the issues in providing support as an internal to Government consultant

George Washington University Slides on Cyber-Security

I wanted in this entry to talk about my thoughts on what organizations should consider when dealing with cyber-security issues. My discussion here is based on slide 18 – Thoughts On What To Do (duh). I will cover the final slides in a following entry.

I believe a lot of people start with the wrong premise. They assume that the goal of cyber-security implementation is to end-up with a secure systems architecture. In fact, at least in my opinion, that goal is unrealistic and planning with that objective in mind can lead to negative results.

Money is wasted playing what I refer to as whack-a-mole security, chasing after incidents that have already happened, and spending too much of an organization’s limited resources defending everywhere when the bad guys only need to find one vulnerability.

As I write “The fundamental question is how to be secure when every component is insecure.” I suggest two parts to the response, the first of which I discuss here.

As step one, practice security hygiene. Make sure that you have not made it easy for your systems to be penetrated. The reason we put locks on the doors of houses is not because this makes it impossible to break in, but at least we make it hard for the casual intruder and we slow them down to increase the chance of apprehension.

Much of what I talked about while I was at the Department of Transportation is in fact being accomplished, better than I did for that matter, currently in the Federal Government. There is an increasing movement away from the static oversight of FISMA report creation to the dynamic oversight of real-time situational awareness.

You cannot defend something when you do not know what is happening. Integrating sensors into your network or even better developing systems that themselves provide situation status are a big plus.

Second, it is important to build security into the budget process. My not well-formed thoughts at DOT were that depending on the categorization of software projects, low/medium/high, from a criticality (or some other kind of measurement) there should be a percentage range of the total budget that was required to be associated with security explicitly with a separate plan as to how the money would be spent. I found that when I went back and looked at systems that had been developed at DOT before I joined, the security investments were often not documented and when documented, the percentage of the total expense varied very dramatically.

The key point here is that security dealt with after development generally has little value and even then costs much more than when designed into the system development process.

Third, it is important to be as transparent as possible. There is a tendency to try and hide security status with the excuse that this makes a system more vulnerable by exposing weaknesses that would otherwise not be known.

This premise is generally wrong for at least two reasons. Bad guys will eventually find all of these weaknesses anyway; they spend more focused time doing so then most of us have in protecting. Most important, it is only with transparent exposure of status that we are likely to focus on fixing problems.

It is just as likely that resistance to transparent exposure of status is fear of oversight more than security protection. Management visibility is the biggest cure for problems.

This last issue is representative of the broad issue of information sharing versus information protection, a topic I have discussed many times. I remain convinced that while both have to be paid attention to, organizations that want to be successful in accomplishing their mission need to lean to the information sharing side of the argument.

Next will be my wrap-up of the presentation continuing the conversation about what to do about security while having inherently insecure systems.

Since the classes I teach at the University of Maryland and Syracuse University are on-line distance learning, it is always a treat for me to have actual live students in the same classroom as I am to interact with. This year the exchange of information was really great, Dr. McCreight has a wonderful class. For all of these activities, I deal with what I call the “avoidance of appearing like an idiot in front of people syndrome”, which forces me to at least to scan and keep up with the literature before the class is held.

While I am one of those people who learn best by doing, being able to talk to and/or discuss with bright students is still very helpful and fun to do.

I have posted my presentation below and during the next few weeks hope to write a few columns based on the later slides, of course I have still not written my last two posts I promised on cloud computing, as as usual what I plan to do with this blog and what actually happens continues to diverge.

GWU Cybersecurity Presentation

On slide 13, I put a quote from Professor John Mueller, who is the Woody Hayes Chair of National Security Studies at Ohio State University, parenthetically a title which gives one pause for a number of reasons. I really like to read Professor Mueller’s papers not because I agree with all of them but because he is a contrarian. It is from those people who do not follow the crowd, that much can be learned.

Professor Mueller basically claims that the ability to predict what a terrorist would do is so small and the cost of protecting everywhere so high that we need to rethink our entire approach to national security. He has written a number of papers on this subject including doing mathematical analysis of the value of the lives saved or lost, which I expect makes some readers uncomfortable, but in the end makes a pretty strong case that we are throwing a lot of money down a bottomless well and not achieving very much with the investment.

I do not have enough expertise to figure out if he is right or wrong, but wanted to mention the related issue which his premise touches on which is prioritization.

The lesson from Professor Mueller is that prioritization in order to work has consequences. That is, when one decides what is a high priority and what is a low priority, then more attention and resources need to be invested in the high priority items – this is the easy part – and less attention and resources need to be invested in the low priority items – AND THIS is the actual hard part.

Interestingly to me, there is lots and lots of attention in the Government in how to create and implement performance based measurements. Doing so in the Government has difficulties not present in commercial situations in large part due to the less clear goals or at least less agreed to goals that a Government program may have. But as hard as creating a performance based approach is, in reality in the end it is the easy step. Much, much harder is acting on the results.

Taking ownership for NOT dealing with a low priority item is not a goal for most Government managers. If you do so and something goes wrong unexpectedly with the area you didn’t get to, you will own the negative results which is not so hot in our blame-first, analyze-second culture. Thus regardless of how we prioritize and how we measure performance there is a tendency to peanut-butter the investments, spreading them around so everything gets at least some attention and none, including the potentially identified high-priority items, get solved.

The lesson from this to me is that it is as or more important to focus on getting agreement from all stakeholders, and their management, as to how to prioritize and the implications of prioritization as it is to create the measurement systems. If the implications are not agreed to up front in a public fashion, then even after performance is measured, you will still end up not acting on the results.

Francis has a show called In Depth which is broadcast from 1pm – 3pm every day. The focus of the show as the title suggests is to look at topics that have been in the news but taking a deeper examination.

On Friday’s he does a Countdown from 2pm – 3pm. He invites two or three people to talk about the three stories each thinks is important for the week. First, the invitees go over their third most important story, then their second, and finally their top story of the week.

Amazingly over the weeks, the stories are only rarely duplicated.

If I might digress for a moment, there was a commercial that ran a number of years ago where a user got to the end of the Internet, http://www.youtube.com/watch?v=HZ5vFvGllTI.

Evidently Francis actually ran out of people to have on the show, because he recently invited me to show up this coming Friday, February 18th.

So this is a long way of asking if anyone has suggestions as the week goes on as to which articles I should bring up to please let me know by passing comments on my blog or to any of my social networking pages.

For those of you are are thinking of becoming a political appointee or wonder about the process, it is worth reading.

In December, 2008, I wrote a column about what I learned from personally being a political appointee in President Bush’s Administration for FedScoop, http://fedscoop.com/2008/12/lessons-from-a-political-cio/.

I thought it might be useful to repeat it here:

“As one of the chief information officers who was politically appointed and thus will be out of a job January 20, 2009, I have been reflecting on the lessons learned that I might pass on to the CIOs who will have a chance to serve in the next administration. Perhaps a few of these thoughts may be useful to any political appointee.

I mention six of them here. I suspect given time I could come up with many more.

First, respect, reach out, and work with the career staff that report to you at the agency you serve. You will find them dedicated, caring, competent, and tremendously hard-working. You will learn much from them, and it will be only with their support that you have an opportunity to accomplish great things.

One of the real values that a political appointee can bring is to provide broad-based support (“high air cover”) for those career staff who want to cause change but are not empowered to do so. When you can use your connections to the departmental political leadership to provide that support, take advantage of those relationships.

Second, remember that political appointees can never speak in a whisper. A truly wonderful professor, Shelley Metzenbaum of the University of Maryland, who has done work supporting the Department of Transportation, provided me that insight. I have never forgotten it though sadly not always kept in mind. The point is that I have found that most career staff very much want to be as supportive as they can. However, if you are not clear in what you want accomplished, or if you are like me and think out loud, you will unintentionally provide inconsistent and confusing direction, especially until your staff gets used to how you operate.

Third, participate in the various groups that exist within the government to allow the exchange of information. These include the federal CIO Council and perhaps more importantly the committees associated with the Council. Also participate in those groups set up to allow information interchange between the Government and their partners including ACT/IAC, AFFIRM, ITAA/AEA/GEIA, and NAPA. If nothing else, you can learn what all of these abbreviations and acronyms mean and be entertaining at cocktail parties and other events. By attending and perhaps speaking at these meetings, you will meet truly interesting people who will provide advice that will make your job easier.

Fourth, learn to accept that you will not get everything done, and therefore make the hard decision to prioritize. If you have never been in public service before you will find that unlike the private sector where the goals are fairly simple and the stakeholders relatively consistent in their interests, the opposite is true in government. Private company goals are generally to make more revenue and/or reduce expenses. In the public environment, the goals are less distinct and more complex. Your many bosses on the Hill, in the White House, among the public, and within your own organization often will provide contradictory and ever-changing direction. Try telling a congressional committee or the inspector general that their issue was a low priority and let me know how that goes for you.

Fifth, reach upward as much as you can. The CIO position within government is often or even completely focused downward toward technology optimization. While this is important, the real value you bring is in enhancing your organization’s mission by looking upward. One clear emphasis of the next administration — on social networking and the use of the Internet — will provide new opportunities to make IT useful in enhancing the interaction of the government with the American citizen and other key external stakeholders. Seize the opportunity to be supportive of such efforts — become an Internet gardener.

Sixth, and finally, have fun. I can honestly say that the last two-plus years have been the most enjoyable and rewarding time I have ever had as a professional. I would not have traded one minute — well maybe one or two — for anything. You will have the opportunity to have great consequence at a place that itself has great consequence for the American public. Enjoy it and pass on that feeling to all you work with.”

A student wrote:

“Who has time to share information? Codifying one’s knowledge can be a very time intensive task. While many people share their knowledge via blogs, wiki’s and other such tools, getting individuals who are already overburdened to do this can be a challenge.  I’ve seen organizations try to force its employees to do this kind of thing resulting in very shallow products.”

From this conversation, I started to consider how this relates to some of the work my company, Powertek Corporation, www.powertekcorporation.com, has been doing with knowledge management. It seemed to me that in the end in the simplest sense knowledge management like information sharing solutions are all built upon the foundation of tagging information in a fashion that allows retrieval.

In the interactions I have had with Jeff Jonas, http://jeffjonas.typepad.com/, one of the smartest people I have met who studies all of this, he has impressed on me the importance of tagging information when it is ingested. Doing so afterwards is something liking trying to add the Dewey Decimal coding to a book after you put it on the shelf in the library. It would take so long to find the untagged books you typically wouldn’t get around to it.

If I can digress for a moment, and since this is my blog I guess I can write anything I want anyway I want to, while I was at the Department of Transportation and while watching what Vivek Kundra is trying to do with dashboards, I have pondered a similar issue – what tends to make some performance measurement systems and dashboards successful and some not.

I have come to believe that those dashboards whose metrics are automatically generated by the performance of the action being measured have a greater chance of surviving over time. The reason is that whenever an intermediate step is needed to generate the dashboard entries, organizations have many reasons to reassign or eliminate altogether the resources used to perform the intermediate step. Thus useful and even pretty successful measurement systems often last only as long as their sponsor stays and stays engaged.

So the common thread would be that the ‘sharing’ and ingesting into the knowledge management system, that is the tagging, should be accomplished when the information is created.

Looking specifically at knowledge management implementations that I am familiar with, most do the knowledge management part after, and often long after, the knowledge creation. The question then becomes whether it is necessary, or practical, to move tagging and ingesting to the actual knowledge creation.

I am sure experts in the field already know the answer to these questions, but if so, they often don’t seem to have sufficient impact on the large number of unsuccessful knowledge management implementations.

I seemed to remember that I had talked before on this blog about proposals but upon searching around, found the only other time was in fact my first post where I provided anecdotes but not brilliant insight, http://www.ourownlittlecorner.com/2009/06/08/first-post/.

So, while recognizing that I am now giving away the secrets I have learned over my many (many) years of working on proposals, here are the rules I follow:

• Answer yes. Engineers take multiple pages to respond with what is functionally ‘maybe’.
• Answer with what the Government wants, not what they are asking for. Requires knowledge and courage.
• Prove it. “No, this time I REALLY mean it.” is not a proof.

There you have it. Follow the three rules and you win, do not and you lose. Well, also bid low. That helps also.

For most of my professional career I did not particularly think about the differences between management and leadership. I was not in a position where it mattered particularly; I was always ‘in the room’.

Generally I was either managing a single large program generally customer facing or managing people who themselves were managing single large programs. The way one achieved results was to use the importance of the program, either due to the importance of the customer or the size of the program, to leverage the rest of the organization I was working for.

“You need to listen to what I am asking”, a typical interaction would occur, “This is worth $100 million to us this year.” Few had the nerve to say no at that point.

When the projects were small it generally meant the other part of the conversation WOULD have the nerve to say no.

As the years passed, I was given additional responsibilities and had to learn to prioritize and help my staff prioritize better, but fundamentally had the same kinds of responsibilities.

In early 2006, I was appointed the CIO for the US Department of Transportation. Suddenly I was in a situation where I had hundreds of people reporting to me directly and thousands who I had at least nominal impact on through the myriad policy responsibilities that a Departmental CIO was responsible for.

I had sort of very faint dotted line relationships to all of the DOT agency CIO’s, created by the Clinger-Cohen Act, which established what I refer to as the negative authorities of CIO’s. By negative authorities I mean the Act gave CIO’s the authority to prevent results, for example not agreeing to a budget submission, but much less power to implement results, for example, without Department or Agency specific legislation or implementing authority, a CIO couldn’t consolidate or modify the resulting budget.

My ability to get things done was almost completely dependent, not on managing a project, but on providing leadership, whatever that was, to get people to do what I wanted without the direct ability to tell them to do it.

Now that I serve as the Chief Operating Officer at Powertek Corporation, www.powertekcorporation.com, while a bit smaller than the Department of Transportation, I still have the same issue of having indirect impact.

Having thought about this a lot over the last almost five years, I have come to five thoughts that provide me with some direction as to how be a good leader, or being perhaps a bit more realistic, to be as good a leader as I can be.

THE NARRATIVE. In my opinion the best leaders are storytellers. They explain how they want people to behave and what values are important to them by telling stories of behavior illustrating those values and actions. It amazes me how often I find out that the stories I have told are repeated to others. Amazed and pleased.

If you have read biographies of President Lincoln you will read how many anecdotes he told.

Even people who do not consciously or explicitly do this, they still are conveying a narrative about themselves and what they expect from others. How often they talk about their family, what they wear, the jokes they tell (or don’t tell), how they deal with people, whether they raise their voice or not, and so on.

NIGHT AND DAY. If you are in a leadership position everything you do and how you do it is watched and analyzed. It all becomes part of that narrative thing, whether you like it to or not or intend it to or not.

My father-in-law, a wonderful person I have been very lucky to get to know, used to tell me when he was President of a manufacturing company in Michigan, that when he was feeling sick and acted that way around the office, this impacted negatively the work of everyone at the plant. At first this surprised him, but over time he came to understand how important how he acted every day was.

About a year after I started at DOT, a young woman who worked for me asked for a meeting. When she came in she told me that she had heard that I was in a good mood and thus wanted to go over some difficult issues that she needed to be resolved. I reflected on the fact that never before in my business life had anyone cared about what mood I was in, or generally noticed.

I reached out to a wonderful person, Shelley Metzenbaum, who is now an appointee within OMB, who gave me advice about being a political appointee at DOT. Shelley told me “Political appointees are unable to talk in a whisper.” Wise advice. Over time I have come to recognize that this advice is true for all people in very senior positions in any organization.

BE TRUE TO YOUR SCHOOL. My final comment about narratives is to emphasize that the most important aspect of the narrative is to be true to who you are. Over time people can tell if you aren’t. The rare exceptions being if you are an extraordinary actor or a professional politician. When people detect a false note, everything else you say or do will be much less likely to be paid attention to.

I have read many books about leadership which provide lots of advice on how to act. All the advice in the world is of limited value if it is inconsistent with your nature. Understand yourself and go with that.

ROADRUNNER VERSUS COYOTE. I tell people who work for me that sometimes you have to go running off the cliff without knowing if you are the Roadrunner or the Coyote, http://www.youtube.com/watch?v=fUq9hynzCVo, and not knowing how far down the ground is.

If you want people to attempt great things and run off cliffs for you, you need to be there to catch them and not blame them for trying. Toleration for the occasional failure is a characteristic to me of great leadership.

EMPATHY, NOT SYMPATHY. I read somewhere that leaders needed to show empathy, but not necessarily sympathy.

What I take that to mean is that it is important to understand the motivations of the people who work for you. You want to use those motivations to support your goals. You double the level of energy by having people working toward your objectives both to support you and to achieve their own goals.

At the same time, you have obligations to the entire organization, not just one person within it. Sometimes you are able to scratch individual itches, but often you cannot or at least not in the way that the individual might like.

TREAT PEOPLE WITH RESPECT. I say frequently that people will never act better than they are treated.

If you treat them poorly, not sharing information or objectives, just ordering them around, not empowering them in any fashion, most will act just like they are treated and no more. To have a successful organization you need people to take ownership of their responsibilities.

IN SUMMARY. So there you have it my five rules of leadership, reworded slightly:

• Understand and articulate a coherent narrative that explains to everyone what kind of person you are and what kind of organization you want to lead
• Recognize that everything you do regardless of the setting impacts on that narrative
• Be authentic, people will see through a false story over time
• Tolerate risk taking and its inevitable partner, the occasional failure
• Treat everyone with respect

I divide leaders into two types, those that want to win and those that want to avoid losing. These rules will help you be the first type, the winners, who are much more enjoyable to be around and build the best organizations.

While I also consider the possibility of cost savings associated with Cloud Computing important, I believe other implications are more important in the long-term. I discuss a second one today, and will touch on two more in the next few blog entries.

When we start thinking about moving applications to the cloud it leads us to reconsider how we develop applications. This change in thinking has, as a foundation, the move to object oriented design, and has been encouraged by  a change in conceptual ownership. I talk about both of these in this post.

OBJECT ORIENTED DESIGN. First, I want to emphasize that I am far from an expert in software development, let alone object development, and all of the implications. As usual, however, this does not stop me from having opinions.

When I was a beginning programmer, when I actually had jobs that resulted in results as opposed to my current responsibilities to produce insubstantial policies and hard to measure roles as a manager or heaven forbid, a leader, computer programs were written functionally. That is if you were writing a payroll program you would consider the steps one took to do the payroll:

• Hire a person
• Enter the time for the week
• Process the payroll

And so forth.

In more recent years, the focus changed to objects. That is when designing that same payroll program you might start with what were the ‘objects’ that would be involved in the system:

• A person
• The personnel record
• The check

Where an object could be a ‘thing’ or a process. You would then work through what information that object might expose and/or what actions the object might do or have done to it.

Cloud Computing lends itself well to the concept of object oriented implementations. It is likely to be difficult to think through how to do something functionally in a cloud, e.g. how do you divide up the function between your desktop computer and the work being done remotely over the Internet. But it is not so difficult to think through putting some objects in one location and some objects in the other. While you are still left with the issue of how to find (“discover”) an object and how to get them to ‘talk’ that is send messages to each other, these are solvable problems.

While I am sure I am over simplifying the concept, the way I look at it this is the basis for what has now become Service Oriented Architecture (SOA).

If you consider the object as a service, that is, it provides a service to someone (or something), then SOA allows us to take a coherent approach to putting objects in the cloud and provides a discipline regarding how they interface.

OWNERSHIP. As important as how one develops software applications is the change in how organizations and developers look at the ownership of the result.

When something is developed in-house and implemented on the organization’s own computers in their own datacenter, there is a tendency to look inward for everything associated with the application. One is less likely to think about using external resources to optimize any of these activities.

However, when the application ends up partially or completely housed in a cloud, whether private or public, then the orientation for planning inevitably starts to focus on how to optimize the situation using at least some resources that are not under internal control. That is, it forces developers to think about the external provisioning.

Once one starts down that path, many additional options start to be under consideration.

What about using someone else’s services/objects to supplement my development? What would I have to do when designing and implementing my application to take advantage of such external resources?

Internet/cloud based providers have incentives to make this kind of interaction easier since this enhances their value-add. Mash-ups, http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid), which can enable very creative solutions with significantly less development investment have become increasingly commonplace.

In summary, the second value-add of the movement to cloud is the change in approach to architecture of and implementation of applications.

I talk about and eventually will write about the movement from Ptolomaic, earth centered, to Copernican, sun centered, to Warholian, nothing centered, thought processes. This is the movement we are undergoing in application development, hastened by the move to the cloud.

What we design for today is not what will exist even two to three years in the future. The impact is only starting to be understood.

I have been part of a number of panels over the last few months which focused on the subject of Cloud Computing, the current state of the’art’, and as usual what barriers exist that need to be dealt with to make it easier to utilize. There certainly has been much written about it both pro and con and it remains a high-priority focus for the current Administrator and, in particular, Vivek Kundra, the Federal CIO.

For one of the graduate classes I am teaching this semester at the University of Maryland University College, the subject is touched upon as part of a broad look at technology changes and implications. The topic generated much comment by my students.

It seems to me that the subject starts from the wrong side of the discussion, the technology side. When the discussion turns to the impact, it starts at an important but not the most important concern, that of return-on-investment (ROI).

Today and in a number of future blog entries, I will talk about what I think are the current important issues associated with cloud computing. Today I start with what I perceive as a foundational issue, cost, but later in the week will move to what I believe are more important considerations and goals.

Note: I do not plan to rehash what cloud computing is, or is not, there are too many other write-ups that do this. Look at the National Institutes of Standards work on such definitions, I think it is pretty good.

SAVING MONEY. To me the least important, though I hasten to say not unimportant, goal of cloud computing is to reduce costs.

In the simplest sense, the provisioning of IT services costs money because of an overhead cost associated with buying computers and putting them somewhere as well as the operating costs of running them. When you spread that cost over more users then the cost per application usage goes down.

With cloud computing you have the potential, emphasis on the word potential, to achieve these savings by running multiple applications on the same computing equipment. This can be achieved when you use techniques to allow more than one application to run at the same time on the same computer increasing its utilization or when the peak levels of demand are different for each application, or both.

This much can be achieved by using what is called a private cloud, that is one that you run yourself. For organizations that have not centralized the provisioning of IT services, this one change can have a significant cost savings. The barriers to doing this are to some extent technical, it is necessary to gain experience in how to do this; but in large part cultural and organizational, it requires different groups within an organization to plan and work together.

Historically, computer usage in data centers is amazingly low, on average between 5 and 15 percent of capacity. By running multiple applications at once, using techniques such as virtualization, this capacity usage can usually be brought up to over 50% and often higher. This reduces the need for additional computing resources and cuts down on environmental costs such as cooling and power.

Moving to a more public cloud, which is one provided outside the organization, has the potential to achieve greater cost savings (maybe). Again looking at this in the simplest fashion, it spreads the overhead cost across still more users, with a public cloud perhaps in the thousands or more.

The other added advantage is that those organizations who have recognized that running data centers is not actually their core competency can out-source, currently a politically complex word, data center operations. On the other hand, organizations that do so need to develop a core competency of working with outside providers, which many organizations do not do.

It is interesting also to realize how many organizations want to move to externally provided IT resources because they feel they are too disorganized internally. This hope generally is not realized. There is an old saying that IT cannot organize a disorganized situation. I can promise you that outsourcing IT will not bring management controls to a situation where none currently exist. You first have to organize internally and only then look for outside provisioning. Electric power providers do not untangle the wiring in your house.

This last step, moving from an internally provided centralized IT provisioning process, private cloud, to an externally provisioned process, public cloud, is made still more complicated for Government due to security and privacy issues as well as fear of embarrassment issues; who needs to read in the Washington Post that your personnel system was hacked while sitting on some public provider; I speak from personal experience that testifying on the Hill about security issues is not why most people go into public service.

Having said that the first step, centralized provisioning, achieves a large percentage of the gain, and is worth working toward.

The other challenge associated with saving money is that many organizations do not do such a great job of tracking the costs which they are trying to reduce. Government organizations in particular often have in place rudimentary, or non-existent, cost accounting systems which keep track of all of the overhead associated with doing such work in-house. Thus the cost comparisons relate lower than actual internal costs against actual external costs. It is not a surprise that different organizations produce different conclusions.

I used to joke when I was at the US Department of Transportation that if you wanted to achieve a certain ROI I could help do so with 10 minutes and Excel.

To be continued …