Todd Biske: Outside the Box

Archive for the ‘SOA’ Category

Joe McKendrick recently reported on a quote of mine from a podcast I recorded with Dana Gardner in both his eBizQ and ZDNet blogs. In the discussion, Dana asked me a very good question on what the telltale signs are that an organization is missing the governance boat. Now that I’ve had some time to think a bit more deeply on this, I’d like to expand upon my original answer.

In the podcast, I suggested that one telltale sign is that you are in meeting after meeting with people disagreeing over priorities. I still stand by this, although I’ll say it’s probably more likely that they’re saying, “This is what I want” rather than “This is what my management told me is my priority.” When governance is really bad, people don’t know what the priorities are, and as a result, they fall back to their own interests, which may or may not be the best interests of the company as a whole, if anyone even knows what that is.

Another telltale sign of a governance problem is when people outside of project efforts have nothing but criticism for the people working on projects, and the people working on the projects have nothing but criticism for the people whose jobs lie outside of project efforts. It could be the workers versus the managers or the developers versus the architects. Whoever the two (or more) parties are, it’s clear that they’re not working effectively, and one possible source of that is ineffective governance.

How about consistency? How many times have you heard someone say, “We need to be more consistent in how we do this”? Once again, this can be a governance problem. Has someone defined what consistency is? What are the policies that people should be following? It’s easy to point out that something is done differently every time, but it’s difficult to articulate one way that it should be done, and to then get the people to actually do it that way. Keep in mind, however, that not everything should be consistent. There are some things that should change every time, and some things that shouldn’t. If we attempt to apply consistency and standardization in the wrong areas or across the wrong domains, we could wind up making things even worse.

Finally, the biggest sign has to be a general feeling of being on a sinking ship. While this can be due to far more than governance, if your efforts are consistently viewed as not good enough, and everyone knows it, then it’s very likely that there’s a governance problem.

There has to be many more signs that people can add to this list. Please add a comment or trackback with your telltale signs of ineffective governance. And, if these signs are hitting a little too close to home, I can recommend a good book.

I recently completed a certification in ITIL v3 Foundations. On the plus side, I found that the ITIL framework provided some great structure around the concept of service management that is very applicable to SOA. There was one key question, however, that I felt was left unanswered. What are the services?

My assumption going in was that ITIL was very much about running IT operations within an enterprise, so I expected to see some sort of a service domain model associated with the “business of IT.” That’s not the case, at least not in the material I was given. There are a number of roles defined that are clearly IT specific, but overall, I’d say that many of the processes and functions presented were not specific to IT at all. As an example, ITIL foundations won’t tell you whether server provisioning or application deployment should be services in your catalog or not. Without this, an effort to adopt ITIL can struggle in the same way as an SOA adoption effort can. I’ve seen first hand where an organization thrashed around what the right operational and engineering services were. ITIL does offer the right guidance in helping you define them, in that it begins with understanding your customer.

This is the same question where many SOA initiatives struggle. We can have lots of conceptual talk about how to build services the right way, but actually defining the services that should be built is a challenge. In both ITIL and SOA adoption, there is a penalty for defining too many services. It’s probably much more pronounced in ITIL, because those services likely have a higher cost since managing and using those services tends to have a higher cost in the manual effort than managing and using a web service, although, if you’re doing business-driven SOA, the costs may be very similar.

Overall, I definitely felt there is a lot of value in the ITIL v3 framework, and I think if you are leading an SOA adoption effort, it’s worth learning about, as it will help your efforts. If you’re looking to improve IT operations, it will likewise help your efforts. Just know that there you’ll still need to figure out what your services are on your own, and that can have a big impact on the success of your adoption efforts.

My book, SOA Governance, has received some great reviews and I thought I would share them here for my readers that may still be considering a purchase for themselves or as a gift to their favorite enterprise IT worker. It is completely vendor-neutral, so all you vendors of SOA Governance tools can consider sending it as a gift to your customers or prospects. 🙂

Brenda Michelson, Principal of Elemental Links and Program Director for the SOA Consortium wrote, “The reference chapter is worth the price of the book. Even if management fables aren’t your thing, you’ll find Chapter 8, Establishing SOA Governance at Your Organization, to be an indispensable reference. … The advice on governance — policy establishment, communication, enforcement, measurement and feedback — is pragmatic, not autocratic.”

Richard Watson, analyst with Burton Group, said “Todd is spot on in focusing on the team interactions in (fictional enterprise) Advasco’s SOA Centre of Excellence.”

David Linthicum, SOA blogger and Podcast host for InfoWorld, says “Todd’s ability to drive through the hype, and the noise, and get to the essence of the topic is the value of this book. His pragmatic approach to SOA governance defines both the value of the concept, and the approaches required to get SOA governance working within your enterprise. In short, he nailed it.”

David Bressler of Progress Software wrote, “He tells a story, which in addition to being easy to read, importantly makes it easy to remember. And, his story focuses on what’s really important – the results. And he does this from the perspective of an IT organization.”

Mike Kavis, CTO at a tech startup, past Chief Architect at a typical enterprise, and frequent EA/SOA blogger, wrote, “This is one of the few books that actually shows us what success looks like. This is why the book is so good. Many books talk about processes, structure, and controls but fail to provide us with a glimpse into what the fruits of that labor looks like. Todd takes us from project inception, to successes, to set backs, to mitigation strategies, and ultimately to enterprise wide success.”

Robert McIlree, EA and Project Management consultant wrote, “This book is a must-have for all IT managers, architects, PMs and business analysts dealing with SOA issues, be they implementation, governance, or both. I also highly recommend this book for those who are starting or facing IT governance issues in general, even if they aren’t contemplating or building-out an SOA at present – the governance principles, techniques, and advice Todd gives apply to much more than SOA.

Neil Ward-Dutton, Research Director for Macehiter Ward-Dutton, wrote, “SOA Governance is a very good book indeed, in that it does something that so many technology and business management books fail to do: it breaks a complex and hype-laden subject down into very manageable chunks, and walks through the topic clearly and at a steady pace – but it still manages to move quickly enough to prevent the reader getting bored.

This post, by Robert Swanwick, was brought to my attention by Brenda Michelson courtesy of her followup post. In the first post, Robert describes a situation of a company that has historically operated as autonomous business units, each doing what was best for their own customers, including each building their own web channel. As they tried to incorporate more customer contributions into those web channels, he states that “they sought to build a common platform.” He didn’t provide additional details on what common means, whether it was shared customer presence across all of the web channels, or if all of the web channels were consolidated into one. He goes on:

However, the autonomous business units lived on. Because they are quite independent, they are constantly seeking to diverge in order to meet the specific needs of their customers. At the same time IT continues to work towards increased centralization. As you can imagine, this is creating some tension.
A service oriented architecture (SOA) with shared web services and appropriate SOA governance might be their salvation. If IT can control the main architecture and help facilitate the sharing of approved web services, this firm may be able to get the centralization they need while allowing for business units to meet their own customer needs.

Personally, I think there is a risk that SOA could muddy the waters in this situation. I do agree that this is a governance problem, however, it’s not SOA governance, though, it’s IT governance. Based on the description provided, it doesn’t seem like there’s any immediate business desire to consolidate the channels to the customer or to stop viewing these units as autonomous. The second governance question is more about the goals of IT. Why is IT trying to centralize everything and strive for commonality? Are solutions not being delivered on time? Are IT costs running wild? If they are, and these costs can be tied back to the redundancies that exist across these autonomous units, then the governance board needs to determine which of these competing goals, business autonomy or IT cost reduction, is more important. If the stakeholders decide that IT cost reduction is more important, then there’s a high likelihood that SOA is going to help achieve that goal. If the stakeholders choose that business autonomy is more important, an effort to adopt an enterprise SOA is going to continue to be in conflict with that desire and may do more harm than good. Individual business units may want to run with SOA within their domains, and IT may be able to take it a bit further under the radar, but keep in mind that those efforts would not be in support of the stated business goals. In other words, even though there may be opportunities where SOA could be applied, if it puts the stated goals of the organization at risk, that’s a problem. I would encourage the leaders of this organization to first read Jeanne Ross’ excellent book, IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, to assist in getting their priorities straight. I also address how the priorities of the business must be factored into your decisions around SOA in my own book on SOA Governance.

I recorded another podcast about my book, SOA Governance, and also a little bit of discussion on President-Elect Obama’s call for a federal CTO. This was part of Dana Garnder’s Briefings Direct Insights Edition, sponsored by Active Endpoints. Joining the podcast with myself and Dana were Jim Kobielus of Forrester Research and Tony Baer of Ovum.

Listen to the podcast. Download the podcast. Find it on iTunes/iPod. Read a full transcript of the discussion. Purchase the book.

I recorded a podcast discussing my book and SOA Governance with David Linthicum as part of his regular InfoWorld SOA Report. You can download it here.

In my post on a CIO and CTO for the USA, at the very end I called out Jim Kobielus’ idea for an online presidential scorecard. As it turns out, I think this has merits in the world of EA and SOA, as well.

First, in the spirit of full disclosure, this idea came from some very smart co-workers of mine. It’s great having colleagues that make you go, “Why didn’t I think of that?” Consistent with my governance views that stress empowerment over enforcement, the use of self-assessments via scorecards can be a powerful tool. We need to be able to determine whether solutions the architectural goals of the enterprise, but we also need to ensure that a bunch of time isn’t wasted preparing documents whose usefulness begins and ends in the timespan of the formal review. To meet these goals, a self-assessment may be just the right thing, if done properly.

The first criteria is that the assessment shouldn’t take a long time. It shouldn’t require submission of PowerPoint or VIsio, but rather be a series of questions where the answers are yes, no, not applicable, and then one or two “partially compliant” answers. The second criteria is the questions themselves. These should be derived from the policies associated with your architectural governance. This is another reason why I emphasize policies over decision rights. If the policies are known, anyone can make the right decision because we have given them the tools to do so.

With these self-assessments, the group responsible for EA governance can now track compliance without creating a heavy burden on the project teams. The assessment can’t be the only means of communication, because the governance team must be able to determine when someone is falsely claiming compliance, but that’s a challenge for any audit-focused group. The governance group should be reporting the results so that teams will want to be compliant in the future, rather than having to explain to their manager why they showed up lower on the report than their peers.

Shameless plug: Looking for more help in implementing effective SOA governance? Get my SOA Governance book from Amazon or via the publisher.

Loraine Lawson has published her interview with me regarding my book on SOA Governance on IT Business Edge as a two part series. Part one can be found here and part two can be found here.

I recently was asked about the proper size for a competency center/Center of Excellence. While many might immediately try to base the size of the group on size of the organization as a whole, my recommendation was based on two key factors:

1. The engagement model of the group
2. The current IT organizational structure and paths of information flow

The engagement model is important, because it has a direct impact on the ability of the group to fulfill its mission. Will your centralized team strictly be responsible for establishing policies and perhaps play a role in reviews and approvals? Or, will your team take a more hands-on role, either as a resource center for projects building or consuming services or as an outsourcing center for service development efforts? The first variety is almost completely divorced from the projects being executed in the organization, and as a result, its size should not be influenced by the number of concurrent projects. The latter two varieties, however, are directly involved with projects. Choose too small, and you’ll have projects executing without your involvement, potentially running down different paths. Choose too large, and you’ll have people sitting idle or doing other non-service related work on projects. Personally, I’m not a big fan of the outsourcing model, but that’s a subject for another blog.

The second factor, and certainly the more important one from a governance perspective, is the way information flows through your organization. If you are establishing a Center of Excellence or Competency Center as part of your SOA governance efforts, the first two processes of governance are establishing policy and then educating and communicating those policies outward. Every organization is different. In an organization where information does not flow easily, and collaborative sessions quickly become fruitless due to the multitude of personalities and opinions that exist, a small group of people may work better, but that group will need to do a lot more of the work to communicate and educate, ranging from IT-wide conversations to more intimate conversations with the small teams at the bottom of the organization chart. In an organization where information does flow more freely, it may be easier to bring in a broader set of people to ensure the full organization is represented, but push the burden off to each individual member to cascade the message throughout their respective areas.

In the context of governance, a feeling of representation tends to be very important. When someone doesn’t feel they have a voice, they’re less apt to comply with the policies. While there will always be some who won’t budge unless the policy is what they want, many more are content with the policy direction, even if it is different from their own views, so long as they feel their concerns have been heard. Keep these things in mind when structuring your Center of Excellence/Competency Center, and hopefully it will help you find the right size for a successful effort.

I recently heard a story from a colleague about an EA group that created some work products with the sole purpose of meeting a stated goal. It didn’t matter whether or not those work products were used by the rest of the organization, only that the work products were produced. I suspect that these work products didn’t do much to change the state of the organization.

This story reminded me of a key point in regards to SOA Governance. This blog and my book emphasize the role of policies in SOA Governance. There’s a risk, however. If we focus to much on policy compliance and lose sight of the desired behavior, we may be no better than the EA group. Yes, we achieved 100% compliance, but if we haven’t achieved the desired behavior, such as a specific percentage reduction in the time to deliver solutions, we’re no better than the EA team at the beginning of this blog.

The other factor that must be kept in mind with policies is that they are normally a contributor to the desired outcome, but may not have a direct cause-and-effect relationship. Think about the current economic crisis. There are so many factors that influence the economy, many of them outside of the control of governmental policies, that policy compliance alone may not get us all the way to success.

The takeaway from this is that governance must be an active effort, and we can’t forget the fourth process of governance: measurement and feedback. If you are not achieving the desired behavior, you need to understand why and make adjustments as needed. These adjustments may be new policies, modifications to existing policies, different people, more education, more enforcement, or maybe a reset of expectations because some external factors have changed. Simply put, never assume that your first pass at policies for SOA governance will be both complete and accurate from the beginning. Put them in place, but also put in place efforts to measure their impact in achieving the desired behavior. After all, 100% compliance is not the goal, the goal is a quantifiable change in the way IT delivers business solutions.

Loraine Lawson of IT Business Edge asked the question, “Is there a right time for SOA Governance?” and offered her thoughts on the answer. In it, she quoted her interview with me, when she asked me about starting with buying a tool. But the meat of the article was a discussion around a recent Aberdeen report on SOA Governance. Key points she calls out:

“Truly effective SOA governance infects itself into the organizations’ DNA…”

This is absolutely true. My view on governance is that it is about guiding an organization to a desired behavior. If the organization is behaving that way, no one even realizes that governance is there, simply because the desired behavior has become second nature. Interestingly, at least one group I’ve spoken with that is closer to that path had to go through a heavy-handded phase first. I’m interested to know whether that is typically the case or not.

The real thing that I want to call out were her conclusions at the end though, which I feel are very consistent with the approach I espouse in my book. She states:

This suggests to me that there are more important questions to consider with SOA governance than when you should start. For instance, ask who’s driving SOA governance (you or the technology tool)? Where should you begin (the report provides a hint that it should be with securing executive business support)? And what steps should you take now to support long-term success?

My definition of SOA governance is the people, policies, and processes that an organization leverages to achieve the desired behavior associated with SOA adoption. Who is driving SOA governance? That’s the people involved. Where should you begin? The Aberdeen report suggests securing executive business support. I suggest that it begins with articulating the desired behavior. Who does that? The stakeholders of the effort which very well may be your key business sponsors. How do you achieve long-term success? By having your “governors” establish the policies that will lead to the desired behavior, and by not forgetting the fourth process of governance (see my four processes of governance post), measurement and feedback. If you just establish policies and then focus on enforcement, but never stop to look and see if complying with the policies actually results in the desired behavior, you may not achieve the intended success.

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!