Todd Biske: Outside the Box

Archive for the ‘Enterprise Architecture’ Category

Presenter: Al Newman, Director of Architecture Services at Allstate Insurance Company

Al discussed Allstate’s journey on the path to establishing a business architecture practice at Allstate.

He walked us through an eight step process:

1. Define business architecture
2. Secure executive sponsorship
3. Develop a framework
4. Secure an initial engagement
5. Build an engagement team
6. Creating a competency center
7. Build out infrastructure
8. Formalize the operating model

Two highlights that I wanted to call out. First, he’s emphasized the need for an engagement model. I’ve seen too many teams, whether formally on the org chart or not, that don’t have an idea on how either the team members or the artifacts that they may create will be utilized within project efforts. In the IT organizations I’ve seen, the work gets done in projects, period. Architecture teams that don’t have people formally allocated to projects need to figure out how their artifacts and/or staff will be utilized in those projects.

Second, he emphasized the need for business architecture in making solid project decisions. I couldn’t agree more, and have a chapter discussing this in an SOA context in my book. In the context of SOA, one question that gets asked is “How do I build the right services?” Asking this question after a project has been initiated is already problematic as the project establishes scope boundaries, and changing those requires more effort than it would have if those discussions were had during the project definition process.

I will be at the Gartner EA Summit in Vegas on Thursday the 11th and Friday the 12th, including being a panelist on EA and SOA on Friday morning. Introduce yourself to me there and perhaps you will get a discount code for my book. Offer open to attendees only.

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.

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.

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.

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.

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.

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.

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.