Todd Biske: Outside the Box

Archive for the ‘Governance’ Category

Presenter: Scott Bittler, Gartner

This presentation got me on my soap box. This talk took the traditional approach to governance, framing it around decision rights. In my opinion, this is too narrow of a scope and leads to the typical review board approach that contributes to the negative connotation most project staff have around governance. A focus on decision rights always jumps to some kind of an exception process, or better stated, a situation where there is a project that is not compliant with the architecture. The problem I have with this view is that these decisions assume that the project was knowingly out of compliance. More often than not, I don’t think that’s the case. I think the project team isn’t aware of what “in compliance” is, makes decisions based upon their knowledge and context, and only when (and if) someone else who has some other context comes into the picture, does a discussion around “decision rights” even enter the mix. When that happens, it’s usually too late in the project, and the schedule wins. What’s the real source of the problem here? It’s not a problem with decision rights, it’s a problem with not providing the people making the decisions the knowledge they need to do it right. What’s even worse in that if we didn’t even find out about the non-compliance, the focus is misplaced on inserting a checkpoint/review instead of actually getting the project team to make the right decision to begin with.

Put another way, how fast would you drive on a road that has no speed limit signs posted? If everyone was speeding, is the right answer to put police officers out there every mile, or is the right answer to post speed limit signs. Unfortunately, with projects, we’re doing the former. We stick more police out in the form of big review boards, but we still haven’t bothered to give the teams the information they need to do things right.

Instead of focusing on who has authority, focus on what the policies are that state what the “right” thing to do is, and enable the people that are must make the decisions to make them properly, rather than taking away their ability to make decisions by requiring them to guess which decisions must be escalated up the ladder to the person who is deemed the authority. The person who is the authority shouldn’t be making decisions, they should be making policies and enabling the decision makers.

The session is now over, and I want to point out that his recommendations slide did have a bullet point encouraging lots of proactive communication on the architecture. I also want to add that there was good content in the presentation, especially the brief discussion on federated governance across business units near the end, I just wish he had emphasized his recommendation on proactive communication (and introduced the concept of policy as part of that) in the earlier slides instead of so much focus on review boards and waivers. I caught him after the presentation and told him about my book, hopefully we can continue the conversation. He’s not on Gartner’s blogroll yet, so I’ll have to hope for some offline communication on the topic.

Chuck Allen, in this blog entry posted after he read my book, felt that the book was missing a discussion on the role of iteration and test-driven development in building a canonical model. He felt that my description of the role of a canonical model felt like a waterfall methodology. I had posted a comment on his blog, but it hasn’t shown up there, so I’d thought I’d post a response here.

There’s two things that came to my mind as a result of Chuck’s post. First, Chuck’s viewpoint is consistent with a lot of people’s thinking around governance as some big, heavyweight process that has more in common with BUD (big up-front design) practices. When applied to agile methodologies and iterative development, they feel it won’t work. This is not my view on it, however. My view is that governance is a requirement, regardless of your methodology. If your project teams feel it’s getting in the way, it’s not that you need to get rid of governance, it’s that you need to change your approach. Where teams get frustrated is where they’re forced to go before some review board or reviewer who starts asking them, “Did you do this? Did you do that?” and the answer is always, “No, I didn’t know I needed to do that.” Therein lies the rub. The team didn’t know about the policies that existed. If the policies aren’t documented, how can we expect projects to be compliant? If the policies are documented, then there should be no reason why a technical lead or project architect can’t bring them up as appropriate within an iterative approach, or bring them up as part of some up-front design, if that’s your preferred approach.

The second thing that came to mind is more about developing those policies and that reference material. If we’re adopting SOA at an enterprise level, then there will need to be policies that define what that “enterprise” success is. My book calls out what those reference materials are, because those are what’s important to good governance. The book did not, however, go into depth on how some of those artifacts would get created. It doesn’t describe how to develop a canonical model or a business capability map, rather, it describes how those artifacts should be used to achieve SOA success. That is the governance question. Developing a business capability map is a business analysis and architecture question. Developing a canonical model is an information architecture question. There are books out there that can teach you how to do that. To Chuck’s point, however, when these artifacts are intended to define something at an “enterprise” level, there is significant risk that they never get created because we go into analysis paralysis. I did call this out in my book, as Chuck pointed out, but I think he offers some good advice that it may make sense to not only apply iterative approaches to your software development effort, but also to your efforts to produce policies and reference material. That’s embodied in my four processes of governance, where the last process is one of continuous improvement. Establish some policies, communicate and educate, enforce them, measure the impact, and then adjust as needed.

I’m pleased to announce that my “soapbox derby” presentation from the September meeting of the SOA Consortium is now available in podcast form from the consortium’s website (basic registration required to download). I thought the “derby” format worked very well, with all of the derby participants given 15 minutes to present, followed by a discussion from the meeting attendees. It kept things brief and to the point on a narrow, but important area. I had just completed my book, so naturally I talked about governance. Give it a listen, as well as the other excellent presentations from Victor Harrison of CSC, Mike Kavis of Kavis Technology Consulting, and Britta Schatz of Penn National Insurance.

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.

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.

In a soon-to-be-released podcast I did with Dana Gardner, Tony Baer, and Jim Kobielus, we briefly discussed the topic of President-Elect Obama’s desire to create a federal CTO position. Some articles are now coming out about this topic, including this one on ZDNet’s Between The Lines blog, this one from Business Week, and this one from the Wall Street Journal. Unlike these articels, I’m not going to pontificate on who might make a good CTO of the USA. Rather, I’m interested in what a CTO of the USA must do, and whether one person is enough.

One of the very early decisions that will help determine the right person for this role is whether the whole take on technology will be inwardly focused or externally focused. Compare this to SOA adoption in an enterprise. Two common questions that must be addressed are, “how do I build services the right way?” and “how do I build the right services?” Both of these questions are important. The first is more inwardly focused, the second is more externally focused. What is the more pressing question for the CTO of the USA? Is more about fixing the way we leverage information technology within the federal government and its multitude of agencies? Or, is this more about how the government makes information technology services available to the constituents?

Interestingly, if we look at President-Elect Obama’s policies in this space, he actually addresses both sides of this, but only one of them references the creation of a CTO position. Both of them are under the header of “Create a Transparent and Connected Democracy.” The first bullet item in this section is “Open Up Government to its Citizens.” Specific actions (not all are listed here) he calls out include:

• Making government data available online in universally accessible formats to allow citizens to make use of that data to comment, derive value, and take action in their own communities.
• Establishing pilot programs to open up government decision-making and involve the public in the work of agencies …
• Lifting the veil from secret deals in Washington with a web site, a search engine, and other web tools…
• Employing technologies, including blogs, wikis and social networking tools, to modernize internal, cross-agency, and public communication and information sharing to improve government decision-making.

Clearly, this seems all about the external view of the federal government and its interaction with the constituents. Note, however, that there is no mention of the CTO position in this bullet point. Where the CTO is mentioned is in the next bullet point, “Bring Government into the 21st Century.” Here, he calls out:

• Appoint the nation’s first Chief Technology Officer (CTO) to ensure that our government and all its agencies have the right infrastructure, policies and services for the 21st century.
• The CTO will have a specific focus on transparency… The CTO will also focus on using new technologies to solicit and receive information back from citizens to improve the functioning of democratic government
• The CTO will … ensure technological interoperability of key government functions.

The bullet items here are much more inwardly focused, with the exception of the “also focus” portion of the second one.

I think these two areas actually each require their own dedicated attention. Interesting, the two articles I mentioned earlier that call out people for the CTO role are all tapping the private sector for people that would seemingly be more appropriate for handling the portions of President-Elect Obama’s policies on opening up government to its citizens, the externally-focused portion. For the role where the CTO position is called out, the important factor here seems to be an ability to implement consistent technologies and interoperable messaging across all of the federal agencies. While you can argue that an outsider may be required to actually get these legacy agencies to change, I would think that someone with strong familiarity with the operation of these federal agencies is going to be critical.

What I think would be the perfect situation would be to have both a federal CIO and a federal CTO. The CIO would likely come from the private sector and be focused on opening up the government to its citizens through the use of information technology. The CTO, on the other hand, would have more experience in the public sector and would be focused on fixing things on the inside to ensure the goals of the CIO and the administration can be met.

One final comment on this. In this blog, Jim Kobelius calls out the need for an “online presidential scorecard.” The fourth process of governance that I define is “measure and feedback,” so I think a scorecard makes great sense, although I also think that this could be a very difficult scorecard to create and make consumable for the average citizen. That sounds like a great task for a federal CIO tasked with opening up government to its citizens. What better way to show transparency than to present a scorecard that shows how the administration is viewing its own efforts toward its goals.

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.

No SOA Governance today, it is all about the governance of the United States. Look at the people, the policies they will put in place, and the processes used to support them, and then place your vote!

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.