Todd Biske: Outside the Box

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!

CNet ran this story yesterday on Pizza Hut’s new Facebook application. They generally panned the application, but I, for one, was glad to see a corporation trying to leverage this platform. Think about it. Pizza and college students go hand-in-hand. Facebook was originally designed for college students, so if a pizza company wants to target a key demographic, why not build a Facebook application? If it is simply an embedded version of their web page, as long as it makes it even easier for those college students to order pizza, they’ve accomplished their goal. Don’t get me wrong, if it has poor usability it will fail. But the fact that it simply allowed Facebook users to order pizza and did not include “additional social features … to enhance the experience” isn’t a problem, in my opinion. I do agree that the forced friend notification is bad, but an optional one could be good. Once again, if the target demographic is college students, the intent is to tell friends that “pizza is available at my place, head on over!” All in all, however, it is the goal of Pizza Hut to sell pizza. Let Facebook provide the social aspects, let Pizza Hut provide the pizza.

What really interests me, however, is the notion of Facebook as a platform for reaching desired demographics. Previously, companies tried to “build communities” via their Internet presence. This is problematic because the company’s primary goal is to sell product, not build community. It simply makes sense to leverage these web properties whose primary purpose is to build communities and augment them with apps/widgets/whatever that can fulfill the primary purpose of your company, like selling more pizza. As a result, if you have a demographic that is likely to leverage these online communities, you need to be thinking about your architecture and how you can easily support the new “channel” of online communities like Facebook.

Today is blog action day for 2008 and the subject is poverty. Like many of the bloggers have posted, I am very thankful for all of my blessings. I still remember traveling outside of the U.S. for the time in 1995 and seeing the poverty in some areas of Jamaica, which is certainly nothing in comparison to many other areas of the world, but was still far worse than what we would consider poor in the United States. There are many excellent organizations out there. The one I will call out is the Christian Foundation for Children and Aging. My wife and I have been sponsoring a young girl in Guatemala since 1997, and I am very glad that this is enabling her to have proper clothing, care, and education, and to share her learnings with her family. With every letter we receive from her, it reminds me to be thankful for what I have, and thankful that I can help a family get on the path of a better life with each generation. Please considering helping out.

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.

Since I first learned a bit about virtualization, there’s been one question that I’ve had that still keeps nagging me: isn’t this what operating systems were originally supposed to do? Back in my undergraduate days in the Computer Science department at the University of Illinois at Urbana-Champaign, I took a course in operating systems, and I seem to recall it being all about the allocation of memory, I/O, storage, and processor cycles among processes. This seems to be the exact same problem that virtualization is trying to achieve. About the only differences I can see is that virtualization, at least on the server side, does try to go across physical boundaries with things like VMWare’s VMotion, and it also allows us to avoid having to add physical resources just because one system requires Windows Server while another requires SuSE Linux.

So, back to the question. Did we simply screw up our operating systems so badly with so much bloat that they couldn’t effectively allocate resources? If so, you could argue that a new approach that removes all the bloat may be needed. That doesn’t necessarily require virtualization, however. There’s no reason why better resource management couldn’t be placed directly into the operating system. Either way, this path at least has the potential to provide benefits, because the potential value is more heavily based on the technology capabilities, rather than on how we leverage that technology.

In contrast, if the current state has nothing to do with the operating systems capabilities, and more about how we choose to allocate systems to those resources, then will virtualization make things any better? Put another way, how much of the potential value in applying virtualization is dependent on our ability to properly configure the VMs? If that number is significant, we may be in trouble.

This is also a key point of discussion as people look into cloud computing. The arguments are again based on economies of scale, but the value is heavily dependent on the ability to efficiently allocate the resources. If the fundamental problem is in the technology capabilities, then we should eventually see solutions that allow for both public-cloud computing as well as private-cloud computing (treat your internal data center as you own private cloud). If the problem is not the technology, then we’re at risk of taking our problems and making them someone else’s problem, which may not actually lead to a better situation.

What are your thoughts on this? Virtualization isn’t something I think about a lot, so I’m open to input on this. So far, the most interesting thing for me has been hearing about products that are designed to run on a hypervisor directly, which removes all of the OS bloat. The risk is that 15 years from now, we’ll repeat this cycle again.

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.

Just a note of thanks for Brenda Michelson and the SOA Consortium for a great meeting and the opportunity to participate in the Soapbox Derby. It was a bit like an un-conference in that the participants were free to talk about anything SOA-related for 15 minutes, followed up by 15 minutes of group conversation. I’m pretty sure that these will likely be posted as a podcast, but I hope they decide to repeat this effort at another meeting. We had some great conversations around governance, actual project experiences, organizational change management, SOA and model-driven architecture, EDA, and more. I think it could easily be a great draw again at a future meeting. A great part of organizations like the SOA Consortium is the opportunity to share experiences with fellow practitioners, and I thought the Soapbox Derby was a great way of doing it. I encourage my fellow practitioners to keep an eye out for the next time they do this and take the time to share for a few minutes.

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.