Todd Biske: Outside the Box

Archive for the ‘Governance’ Category

Go figure, just as I post an update on articles, etc., I have another one published. I wrote an article titled, “Implementing SOA Governance” for InfoQ and it has now been published. It’s not a direct extract from my book, more of a short overview of a few of the key points from it. I hope you enjoy it, and if you want to read more, please consider the full book.

A couple of items that I thought I’d call attention to:

1. I wrote an article for the latest issue of Architecture and Governance magazine titled, “Does SOA Really Matter?” My opinion, not surprisingly, is yes. This article requires registration to read.
2. Jordan Haberfield, Senior VP of IT Client Services for System One Holdings, interviewed me for his Agile Elephant blog regarding my book on SOA Governance.
3. Thank you to the people who purchased the book from Amazon today and allowed me to watch my Amazon sales rank go up from somewhere in the 200,000’s to 32,042. While my target audience is a bit more narrow than that of Brisngr, it would be really cool to see the sales rank make it to the four figure barrier.
4. Speaking of Amazon, consider adding to your order the latest book from Patrick Lencioni, “The 3 Big Questions for a Frantic Family.” While this book has nothing to do with IT, Patrick’s leadership fables gave me the inspiration for the style of my book. I can only aspire to become as good an author as he is. I heard him speak at a Gartner summit, and he’s an excellent speaker on top of it.

Keep an eye out for an interview with Loraine Lawson of IT Business Edge. I also plan on doing a few podcasts in the near future to talk about the book, as well. I’ll post information about them here as they come online. Thanks for being a reader of the blog, and please let me know your comments and questions about the book at soagovbook at biske dot com.

I just read David Linthicum’s “Governance Monday” post, Can SOA governance technology be distracting? In it, he discussed some of his conversation with Anne Thomas Manes of The Burton Group. He states that SOA governance technology can “muddy up the water in the early stages” of the effort. I certainly agree with this. These technologies can be complicated, especially when striving for a highly integrated, automated approach. There is a risk that the reason for using the technology can be forgotten as the focus shifts toward getting the technology implemented.

There is another question I would like to address: can governance itself be distracting? While Dave covered the technology angle, what about the governance processes? I did an interview with Loraine Lawson of IT Business Edge last week, and in that interview, I stressed that organizations must avoid starting too late with their governance efforts. If you are adopting SOA to change the way you approach solution development, you need to make the desired behavior known early and often. If you wait until a team “misbehaves” before making them aware of the correct behavior, it will create animosity. If you wait until the situation is critical before embarking on the change associated with SOA, you’ll be forced to take a heavy-handed approach, much as world governments were forced to take heavy-handed actions with current financial crisis. It was necessary, but no one is happy about it.

Want to know more? Check out my book, SOA Governance.

This was too good not to share. Word of my new book on SOA Governance made its way to the Yahoo SOA group this week and Steve Jones had a great comment:

Now as it’s a governance book it should be big, it should be heavy and you should be able to hit people with it. I’m a bit concerned that this one looks a bit fragile and quite frankly a PDF goes against the whole principle of Governance enforcement.
Wait…I’m meant to READ the things?

Yes, the book is paperback, and at just over 200 pages, it won’t do much damage if you beat people over the head with it. Thanks for the laugh, Steve!

Unless you’re completely disconnected from mainstream media, you’ve certainly heard the word “policy” in the news recently. It’s been frequently prefaced with two additional words: “failed economic” as in “the failed economic policies of this administration.” With this, there should be no doubt that there is a connection between policy and governance. Policies are the rules that, if followed, should lead to the desired behavior for an organization. In the case of the current financial crisis, economic policies are ones that should lead to the desired behavior of the economy.

The current situation actually serves as a very good example for a discussion on policy and governance. First off, I’ve yet to hear any of the candidates call out the specific policies that they believe were wrong. The closest that they have come is to attack the deregulation that went on the 90’s. Now, you can argue that deregulation is a policy. In effect, it’s a policy that says, “We’re going to make this domain someone else’s responsibility” and that’s perfectly all right. If your view of governance is that it’s all about decision rights, this is in line with that approach. The policies don’t end there, however. The next policy that could be examined is the lending policies of the institutions that gave mortgages to people who had no hope of ever paying them off. My personal opinion is that this is the failed policy, which wasn’t a policy put in place by democrats or republicans, but by the lending institutions.

Now that the candidates are now trying to offer solutions for the situation, it shows that there are many ways of addressing the fact that the desired economic behavior is not being achieved. We can certainly change the people involved, and I think there’s an underlying assumption that with a change in people, the policies will change too. Second, we can change the policies. In this example, there are two areas for change, however. Changing the policies around regulation only changes who can set the policies around lending. It could be just as easy for a different set of people to keep the same bad lending policies in place. The second area is the lending policies used by the banks. Clearly, changes here would certainly stop the bleeding, so to speak. Finally, we can change the processes. Perhaps the lending policies on paper were fine, but were routinely ignored. Putting more rigid enforcement and auditing in place would be one way of addressing this.

So how does all of this apply to SOA Governance? The same general approach is applicable to the world of SOA governance. If you’re not getting the desired outcome from your SOA efforts, then perhaps you need to look at the policies you have that govern your SOA efforts. Have you “deregulated” your SOA and simply expect your projects to do the right thing? Do those projects care about the greater corporate economy, or are they simply concerned about the project “shareholders” and focused on delivering on-time and on-budget and nothing else? Perhaps the problem isn’t that critical, but the efforts are disjointed. A centralization of policy administration into a Center of Excellence may be in order. Or, perhaps the policies are there, but aren’t being followed, so a change in processes is needed. Finally, it could be in such dire straits that a complete change in leadership is needed. In my opinion, however, it all begins with policies. If you’re not getting the results you want, take a look at the policies you have (or the lack thereof). Either the policies are not yielding the results desired, or the policies are not being followed. If the latter, look at your processes and make changes there. If the former, you need a policy change. Your current SOA leadership can change the policies, or if they are blind to the problems in front of them, then make a change to the leadership to people that will put new policies in place. A change in personnel with no corresponding change to policies or processes is no change, and a change in personnel without an analysis of the policies they will put in place to determine if they will yield the desired behavior will also fail.

Want to learn more about governance as people, policies, and process? Check out my book on SOA Governance available now from Packt Publishing, and from other online book stores soon!

I’m now officially a published author. All of the final edits are done, and my book on SOA Governance is now available via the store at Packt Publishing. It will also be available through amazon.com and other online bookstores. Please consider it as part of your effort to learn about SOA Governance and don’t hesitate to contact me if you have further questions or comments.

Nick Malik posted this response to my previous post on governance and decision rights. In it, Nick claims that what I posted was a workable set of decision rights, which I partially agree with. He made three comments on quotes from my post, and it is the third where I disagree. He stated:

“If we focus on creating policies” — And here really is the confusion. What are those policies called? They are called “decision rights.”

While a policy can be statement of decision rights, such as “All solution architectures for projects costing more than $X must be approved by Enterprise Architecture,” they don’t have to be and I argue that the majority shouldn’t be. A policy like “All services must be entered into the registry/repository at the time they are identified.” is not a decision right, rather, it is a statement of expected behavior. If followed (in conjunction with other policies), the expectation is that the goals will be achieved, such as reduced redundant implementations of business logic. If goals aren’t reached, you need to revisit policies and processes, or even the people involved.

Decision rights are certainly part of governance, but a view that makes them the defining part is wrong, in my opinion. If we focus too much on decision rights and not enough on decisions, we are at risk of creating fiefdoms of power that perpetuate the negative, command and control view of governance. If we focus on policies that enable anyone to make the correct decisions, I think that is a better position for success.

Shameless plug: Want to learn more on SOA Governance? Check out my book by the same name, available now for pre-order and generally available in late October 2008.

At the SOA Consortium meeting, Fill Bowen of IBM asked me a question after my soapbox on SOA Governance that I thought would make a great post. He was surprised that I didn’t mention the words “decision rights” a single time in my post. It’s a great question, especially because the IT Governance book from Jeanne Ross and Peter Weill of MIT’s CISR defines IT governance as “specifying the decision rights and accountability framework to encourage desirable behavior in the use of IT.”

In all of my posts on SOA Governance, and in my SOA Governance book, I don’t think I’ve talked about decision rights once. While this was certainly unintentional at first, I’ve now given it some thought and I’m happy that I didn’t include it or emphasize this viewpoint. The closest I’ve come is in my discussions around the people component, and stating that the people do need to be a recognized authority. Obviously, recognized authority does imply some amount of decision rights. At the same time, I think that’s emphasizing the wrong thing. There is a negative view around the term governance because people associate it with authorities flaunting their power. The emphasis needs to be moved away from the people, and instead focus on the policies. As I stated in my “Governance does not imply Command and Control” post, if you focus on education, you can allow individual teams to make decisions, because you’ve given them the necessary information to make the right decisions. If they don’t have the information to make decisions that will lead toward the desired behavior, it turns into a guessing game. Not only can there be confusion in what the correct decisions are, there can also be confusion on what decisions should be escalated up the chain. If we instead focus on creating policies and making those policies known so that anyone in the organization can make the right decision, we’re in a much better state. Yes, you will run into some situations with conflicting policies, or the absence of a policy, but if those are the exception, it should be far easier to know that those decisions require escalation or inclusion of others.

In a post on his Fast Forward blog, Joe McKendrick asked the question, “Does Enterprise 2.0 Need to be Governed?” This title brought to mind a common misconception about governance. It’s not an optional activity. While there may be people that aren’t aware of it, it’s there. Even in the smallest organization, governance is there, it’s just that it’s completely manageable because everyone can talk to everyone else and there’s a small number of goals that everyone is aware of. In a startup, there needs to be desired behaviors and policies that guide the business strategy of the company. For example, what will be the balance between funding for marketing and funding for engineering? Both are needed, and failure of either one can doom the startup, yet competing startups will often take very different approaches.

In the writing of my SOA Governance Book, the reviewers both asked about connections between SOA Governance and IT Governance, or even the overall corporate governance. In my post about the four processes of governance, Rob Eamon asked why the processes couldn’t apply to architecture governance in general. The truth is, the fundamentals of governance- desired behavior, people, policies, and processes- apply regardless of the domain being governed. If you reach a point where there are enough variables involved with the efforts of your organization, whether that be the number of people employed, the number of projects executed, or many other factors, that there is now risk of people going off in a variety of directions due to unclear or competing priorities, you need governance. Anne Thomas Manes pointed this in out in the context of REST in Joe’s post. From Joe’s post:

Anne Thomas Manes says a lot of REST advocates she speaks with feel that governance isnít required for REST-based services. ìAt which point I respond saying, are you kidding? Think about how many people have created really, really bad POX applications that they claim to be rest and actually have almost no representation of the REST principles involved. They donít follow any of the constraints, and theyíre basically just tunneling RPCs to URLs.î

Put simply, we need to ensure that rather than just building things, we are building the right things, the right way. Good governance that can make that happen. Poor governance results in teams doing whether they deem as important in their corner of the world, or more likely, whatever the easiest path is for them, by first focusing on things completely within their control.

As a side note, it was disappointing to see that ebizQ’s SOA Governance Panel didn’t include any practitioners. They had 2 analysts and 4 vendors. While I’m not campaigning for future panelist slots, and I know and respect all of the panelists, governance is one of those topics that shouldn’t be discussed without at least one practitioner, preferably a corporate practioner. Some of the big federal consulting practices would also have a lot to offer, since they effectively are the corporate IT for the government agencies. There are plenty of ways to get anaylst and vendor views on it, let’s here from the people that are dealing with it on a day to day basis on what works and what doesn’t.

During my soapbox derby discussion at the SOA Consortium meeting, I chose to discuss SOA Governance, and I thought that one of the messages I delivered would be another appropriate post to highlight some of the content in my upcoming book.

As I’ve said in this blog, SOA governance is the combination of people, policies, and processes that an organization uses to achieve the desired behavior associated with SOA adoption. This post, not surprisingly , will focus on the process component. Previously, I had a post explaining that governance does not imply command and control. Those two words only bring to mind one of the four processes: enforcement. There are three additional processes that your governance effort must also implement. The four processes are:

• Policy definition
• Education and communication
• Enforcement
• Measurement and feedback

Policy definition is concerned with establishing the policies that the governance team feels will result in the desired behavior if they are followed. Without policy, the rest of the organization must either guess what the correct decisions are to get to the desired outcome, or involve someone from the governance team on every single project. The first option is unlikely to lead to success, and the second option has both scalability issues as well as being prone to variation based upon the “tribal knowledge” of the particular person from the governance team involved. Defining and documenting the policies is step one toward gaining consistency in the outcome.

Education and communication is the next step, not enforcement. Just because the governance team has reached agreement and documented the policies doesn’t mean they’re going to be followed, or even known for that matter. A formal, planned communication effort to educate the organization on why you’re adopting SOA, the desired behavior you hope to achieve, and the policies that are being put in place to achieve them is required. It’s not a one time presentation to all of IT, but rather a series of targeted communications for the various roles in the organization, large group presentations, small team presentations, blogs, wikis, and appropriate surveys and followups to ensure that the communication is effective.

Enforcement is the third step. Even if your communication efforts are incredibly successful, you still need to put processes in place to ensure the policies are being followed. What you will find, however, is the better job you can do on communication and education, the easier your enforcement processes can be. If education is poor, enforcement will likely need to be more heavy-handed. Where possible, automated testing and reporting can certainly make the processes more efficient and cost-effective.

Finally, the governance group must have measurement and feedback processes to ensure that progress is being made toward the desired behavior. If the desired behavior is not reached, something needs to be changed, and it could easily be the policies, the processes, or the people involved with governance. Accountability is lost if the team puts policies and processes in place, but then does nothing to verify that all that effort actually paid off.

I’m here at the SOA Consortium meeting in Orlando. The first speaker at the event was Jeanne Ross from the Center for Information Systems Research at the MIT Sloan School of Management. They had recently completed a study on SOA adoption, and she presented some of the findings to the consortium. If you’re not familiar with Jeanne Ross, I thoroughly recommend two of her books, IT Governance and Enterprise Architecture as Strategy. I continue to refer to some of the concepts I learned from these books as part of my day-to-day job.

One of the interesting takeaways I had from Jeanne’s presentation was the information on the value companies are getting out of reusing services. What the study has found is that while there is definite measurable value that comes out of reuse, in many cases that effort comes at a very significant cost, a cost that often usurps the value generated. This made me think about a discussion that I frequently have with people concerning “enterprise” services versus “non-enterprise” services. In these discussions, it’s always been a black-or-white type of discussion where my stance is that we should assume a service has the potential to be an enterprise service unless told otherwise while the stance of the person I’m speaking to is frequently the exact opposite. It turns out that neither of these positions is the right way.

If you took my old stance, the problem is that you incur costs associated with building and operating a service. If that service doesn’t get reused, you won’t recoup that cost. If you took the opposing stance, you avoid the initial cost, but then you’re at risk of incurring an even higher cost when someone wants to reuse it. To maximize the value that you get out of your services, we need to find something in the middle. There does need to be a fixed amount of cost that will get sunk into any service development effort, but it needs to be focused on answering the question of whether or not we should incur the full cost of making it an enterprise service with full service lifecycle management, or if we should simply focus on the project at hand and leave it at that. I’m going to give this topic more thought and try to determine what that fixed cost should be and hopefully have some future blog entries on the subject. In the meantime, if you have ideas on what you think it should be, please comment or trackback. I’d love to hear more on how others are approaching this.

I will be attending the SOA Consortium meeting next week in Orlando. As Brenda announced on the SOA-C blog, I’ve agreed to be a soapbox derby participant.

I haven’t yet decided which soap box I want to climb on. There’s the obvious and likely SOA Governance topic, given my new book, but I’ll have to find the angle that can stimulate discussion. I could talk about how just because the media has shifted discussions toward WOA and other shiny new things, doesn’t mean that SOA should be put out to pasture. It’s safe to say that I will be talking. In my role as an enterprise architect, I understand that it is my job to have an opinion and provide direction. There’s nothing that drives me nuts more than a meeting where everyone knows something needs to be done, they may even agree on what needs to be done, but no one wants to step up and do it. There’s a soap box for you right there!

Anyway, I’m really looking forward to attending one of the face to face meetings for the first time. I’m especially looking forward to the keynote from Jeanne Ross on SOA adoption and value. If you’re going to be at the meeting, please at least stop by and introduce yourself.

With the upcoming publication of my SOA Governance book, which will be shamelessly plugged on this blog, you’ll be seeing more posts on SOA Governance, whether they are teasers to the book’s content or complementary material.

Many of the discussions I’ve had with colleagues on the topic of SOA governance is how to get started. Everybody’s heard from all of the analysts, bloggers, and other pundits on the importance of governance, but they don’t have a clear plan on how to put it in place at their organization. This isn’t a surprise, because organizations at this points are now facing the need to change head-on.

My definition of governance is the people, policies, and processes an organization uses to achieve a desired behavior. If you’re not achieving the desired behavior, than change is needed.

It is at this early stage where the first breakdown can occur. All too often, the steps of articulating the desired behavior and the policies that will lead to that behavior are not done, or done insufficiently. Rather, the focus immediately jumps to enforcement. Not surprisingly, the people involved with governance at organizations in this situation make statements like, “The developers are going to do whatever they want, and we can’t stop them.” Strong enforcement may catch things before they go live, but it doesn’t address the behavior that did things the wrong way to begin with. While it may result in some behavior change the next time around, it is unlikely, because it did nothing to change the understanding of the project managers, architects, and developers on what they should be evaluating themselves against as the right thing to do. If change is needed, but you’re not stating what you want to change into, the behaviors are unlikely to change. This truth applies whether we’re talking about pre-project governance, project (design-time) governance, or run-time governance, although it’s most easily understood in the world of project governance.

All too often, architects and developers lament the fact that the only concern of the stakeholders is that the project is delivered on time and on budget. If this is an impediment to success with SOA, then that mentality needs to change. If it does not, you’re always going to have this tension between the project manager and the technical leadership on the project. There’s a ripple effect to this, however. The resistance to such a change is that, in general, IT has not been able to demonstrate how adding technical concerns into the success criteria has an impact in IT’s ability to deliver solutions in a timely manner. If you are able to change the success criteria to where projects can be delayed in order to address architectural concerns, you’d better be collecting metrics to show that things are improving over time. This again comes back to establishing your desired behavior and policies first. If you have these in place, now you have something to measure against. If you’re not achieving the desired behavior, it doesn’t mean that you need to scream louder. A change in policy, people, or process may be what is needed.

So, if you’re looking for a place to start, my recommendation is not to focus on enforcement. My recommendation is to define the behavior you’d like to see out of your organization, the policies that will help guide that behavior, and then focus first on education of the organization on those items. If your staff is better educated on the outcomes the organization wants to achieve, they’re more likely to comply with the policies that will lead to that behavior, lessening the need for strong enforcement.

I can finally let my secret out. For the past few months, I’ve been working on my first book, SOA Governance, and I’m now happy to say that it is available from my publisher, Packt Publishing. It can also be purchased from Amazon.

If you’ve followed this blog, you’ll know that my take on SOA governance is that it’s all about using people, policies, and process to achieve a desired behavior, and that same theme carries through the book, showing how it applies to all aspects of your SOA efforts, ranging from project governance, to run-time governance, and finally to what I call pre-project governance.

The style of the book is inspired by the great books of Patrick Lencioni, including Five Dysfunctions of a Team, Death by Meeting, and Silos, Politics and Turf Wars. In it, he presents a fable that illustrates the concepts and points. In my book, I present the story of a fictitious company, Advasco, and their journey in adopting SOA. Along the way, the book analyzes the actions of Advasco and the role of SOA governance in the journey.

Please check it out, and feel free to send me your feedback or questions. I hope it helps you in your SOA efforts.

I’m sure David Linthicum is growing to expect a follow up blog from me after his “SOA Governance Monday” posts. True to form, I couldn’t let this week’s entry go by without commenting. There’s a good reason for that, however. Thanks to the good people over at Packt Publishing, my first book, SOA Governance, is now available for pre-order from Packt, with expected availability in October. It will also be available from your favorite online bookseller. Anyway, back to Dave’s blog entry.

The theme of this entry is SOA Governance as a service, which Dave states could be “a complete design time and runtime SOA governance system delivered out of the cloud.” I couldn’t help but think of the animation from Monty Python’s Flying Circus with the hand (or more frequently, foot) of God emerging from the clouds and squishing something beneath it. All humor aside, my first thoughts immediately came back to my usual comments on Dave’s past governance posts, which is that he’s focusing too much on the tools, and not on governance. His post probably should have been titled “Registry/Repository as a Service.” Of course, that’s what the original authors of UDDI tried to push, and that never came close to realizing that vision, but admittedly, the landscape has changed.

I have no issues with providing a registry/repository as a service. Certainly, the querying interface must be available as a service for any company exposing service outside their firewall. Likewise, if I’m consuming many services from the cloud, it would be great to let someone else handle putting all of those services into a common, queryable location, rather than me having to establish some form of federation or synchronization between my internal registry/repository and the registries/repositories of the service providers in the cloud. This is no different than the integration problem faced by a company that builds some services from scratch, but gets others from third party products like SAP that may have their own registry/repository, like SAP ESR.

Exposing the publishing interface is another story. If we get into the public service marketplace, we’d need this, but I think that’s a niche market today. Even if we consider a scenario where I deploy services into the cloud, I would argue that the publishing service is internal to the cloud provider. In short, the registry/repository capabilities would be part of the service hosting service (is that confusing or what?) made available by the cloud provider.

Back to governance. My constant theme on SOA governance is it is about people, policies, and process. The only role of tools is to make the processes more efficient. The cloud can only provide tooling. The degree to which you will need a registry/repository in the cloud will be completely dependent on the degree to which the rest of your tooling is in the cloud. If your services are deployed in the cloud, then it follows that the cloud must provide policy-driven run-time capabilities, such as request throttling, security, metric collection, etc. If your services are developed in the cloud, then the cloud must also provide metrics, code inspection, automated testing capabilities, and the same things that the design time tools used inside the enterprise provide. The cloud can not provide people, although I guess if a company wanted to outsource all of IT, and take a crowd-based governance model where everything they did would be open to the scrutiny of the developer community at large, then putting it all in the cloud would be a necessity.

The one upside to this notion of a registry/repository and all of the associated metadata associated with consumer/provider relationship out there in the cloud is that some large company with massive data centers (i.e. Google) could run their magic over all of that data and begin to extract out best practices for governing consumer/provider relationship, codifying policies, etc. Dave did call this out in his post, stating:

As the services are revised so are the design artifacts and the policies, both shared and private. In short, you’re taking advantage of the community aspect of SOA governance delivered as a service to do most of the work for youÖ100,000 heads are better than one.

While I don’t think the majority of large enterprises would be willing to allow their data to be analyzed in that manner today, it won’t surprise me at all if it happens in the future. If we think about it, this type of analysis on vendor contracts with enterprises is already done by companies like Gartner, so why shouldn’t a company like Google do the same for consumer/provider interactions with SOA? Even if that happens, it’s still not governance, it’s only analysis, which at best, provides better tools information for having good governance, but it won’t govern for you unless you choose to let it, at which point, you’re stating that the utilization of technology is a complete commodity for you, and you’ll just take whatever the big brother, be it Gartner, Google, or anyone else, tells you is the norm.