Todd Biske: Outside the Box

Archive for the ‘Enterprise Architecture’ Category

Presenters: Anne Lapkin and Colleen Young

One thing all of the presenters in the EA Summit are very good at doing is using consistent diagrams across all of their presentations. This is at least the third presentation where I’ve seen this flow diagram showing linkage between business goals and strategy, and business planning and execution. Unfortunately, Anne points out that the linkage is where things typically break down.

Colleen is now discussing strategic integration, which begins with an actionable articulation of business strategy, goals and objectives. From there, she recommends a standardized, integrated, results-based management methodology. As a result, she claims that we will see exponentially greater benefits from enterprise capabilities and investments.

Anne is speaking again and emphasizing that we need a unified contextual view. This consists of a goal, which is one level deeper than the “grow revenues by XY%” which includes a future end state with a timeline and measurable targets, principles that establish the desired behavior and core values, and relationships.

Colleen now has a great slide up called, “The Implication of ‘Implications’.” The tag line says it all- “Unclear implications lead to inconsistent assumptions and independent response strategies that inevitably clash.” Implications that must be investigated include financial implications, business process implications, architecture implications, cultural change implications, and more. All parties involved must understand and agree on these implications.

A statement Colleen just made that resonates with my current thinking is, “Based upon these implications, what do I need to change?” All too often, we don’t stop to think about what the “change” really is. Work starts happening, but no one really has a clear idea of why we’re doing it, only an innate trust that the work is necessary and valuable. If the earlier planning activities have made these goals explicit, the execution should be smoother, and when bumps in the road are encountered, the principles are right there to guide the decision making process, rather than on relying on someone’s interpretation of an undocumented implication.

Once again, this was a good session. I know I’ve commented on a few sessions that they could have been a bit more pragmatic or actionable, this one definitely achieved that goal. I think the attendees will be able to leave with some concrete guidance that they can turn around and use in their organizations.

Presenter: Richard Buchanan

The first topic Richard is covering is the need for enterprise architects to master strategic thinking. His current slide is consistent with an earlier talk today, showing that enterprise strategy is at the intersection of three disciplines: Enterprise Strategy and Planning, Enterprise Architecture, and Enterprise Portfolio Management. He states that enterprise architecture must translate business vision and strategy into effective enterprise change. He’s discussing how a budget and the organization chart are not part of the business strategy, pointing out that a budget should be a downstream deliverable derived from the business strategy. Great point. His definition of strategy includes an organization’s environment, goals, objectives, major programs of action, and the resource allocation choices to execute them.

The next topic he is covering are the categories of tools and techniques that are used in developing a business strategy. These are not software tools, as the first one he’s showing is Porter’s 5 Forces Model (this is second time Michael Porter has been referenced at the Summit). He’s challenging us to go and find the people in our organization that are looking at these things. Good advice. There’s no doubt that if you want to do strategic planning, you need to be looking at these five forces, and there’s a good chance that someone at the company (probably outside of IT) is already doing this. The same thing holds true for the other categories of tools that he has went through.

The final point he’s covering is how to leverage these strategic tools within the EA process. To some extent this is motherhood and apple pie, but it’s very good advice, especially knowing that many EA’s have grown out of the world of application development and may still be very technology focused. As a result, it’s entirely possible that the EA team has never read the company’s annual report. It’s even more likely that EA hasn’t seen things like competitive analysis documents. If an EA doesn’t understand how a company competes, how can they make appropriate decisions? Speaking very broadly and citing Michael Raynor’s earlier presentation, do you know whether your company differentiates on cost or on products? Both of those can have significant impacts on how information technology is leveraged. A company that differentiates based on product excellence and customer service must have significantly better technology for understanding their customers than a company that simply tries to be the lowest cost provider in the marketplace.

My final thoughts: There’s not much to disagree with in this presentation. I think he paints a great picture of what many of us would like to be doing. The challenge I suspect that many attendees have is that our EA organizations, as a previous presenter put it, “are mired in the world of technology architecture.” Somehow, we need to find a seat at the strategic planning table so when we ask about some of these artifacts, everyone knows its importance versus stopping us in our tracks and asking, “Why do you need it?”

Presenter: William Clark

I’m looking forward to this talk, as it’s a new area for me. I don’t remember who told me this, but the key to getting something out of a conference is go to sessions where you have the opportunity to learn something, and you’re interested in the subject. That’s why I’m avoiding sessions on establishing enterprise technology architects. I’ve been doing that for the past 5 years, so the chances are far less that I’m going to learn something new than in a session like this one, where it’s an emerging space and I know it’s something that is going to be more and more important in my work in the next few years. The only downside is I’m now on my fourth day in Orlando which is starting to surpass my tolerance limit for sitting and listening to presentations.

He’s started out by showing that the thing missing from the digital experience today is “me.” By me, he implies the context of why we’re doing the things that we’re doing, such as “where am I,” “what have I done,” “who are you talking to,” etc. He points out the importance of user experience in the success and failures of projects, especially now in the mobile space.

Some challenges he calls out with incorporating context into our systems:

• Blending of personal contexts and business contexts. For example, just think of how your personal calendar(s) may overlap with your business calendar.
• Managing Technical Contexts: What device are you using, what network are you connecting from, etc. and what are the associated technical capabilities available at that point?
• Context timing: The context is always in a state of flux. Do I try to predict near-term changes to the context, do I try to capture the current context, or do I leverage the near-past context (or even longer) in what is shown?

It’s always a sign of a good presentation when they anticipate questions an audience might ask. I was just about to write down a question asking him if he thinks that a marketplace for context delivery will show up, and he started talking about exactly that. This is a really interesting space, because there’s historical context that can be captured and saved, and there’s an expense associated with that, so it makes sense that the information broker market that currently selling marketing lists, etc. will expand to become on-demand context providers with B2B style integrations.

All in all, I see this space with parallels to the early days of business intelligence. The early adopters are out there, trying to figure out what the most valuable areas of “context” are. Unlike BI, there are so many technology changes going on that are introducing new paradigms, like location aware context with cellphones, there’s even more uncertainty. I asked a question wondering how long it will be before some “safe” areas have been established for companies to begin leveraging this, but his answer was that there are many dimensions contributing to that tipping point, so it’s very hard to make any predictions.

This was a good presentation. I think he gave a good sampling of the different data points that go into context, some of the challenges associated with it, and the technical dynamics driving it. It’s safe to say that we’re not at the point where we should be recommending significant investments in this, but we are at the point where we should be doing some early research to determine where we can leverage context in our solutions and subsequently make sound investment decisions.

Presenter: Robert Handler

He’s showing a slide on IT Portfolio Management Theory, and how there is a discovery phase, a project phase, and an asset management phase. Discovery explores new technology, projects implement new technology, and the asset management phase operates it once it’s in production. Next, he’s shown an Enterprise Architecture diagram and discusses the whole current state/future state approach, risk tolerance principles, etc. He now has a slide with a summary of three areas: IT Strategic Planning, Project & Portfolio Management, and Enterprise Architecture. He shows that all three of these have overlapping goals and efforts that could be better aligned because at present, they tend to exist in vacuums.

He’s now talking about some of the issues with each of these disciplines. First, he used Wikipedia’s definition of technology strategy to show the challenge there (Wikipedia claims it’s a document created by the CIO, the audience chuckled at that). On to Project and Portfolio Management, he’s calling out that only 65% of organizations cover the entire enterprise in their portfolio, and most PPMs are focused on prioritizing projects. On the EA side, he calls out that most efforts are mired in the creation of technical standards.

His recommendations for creating a win/win situation are:

1. Collectively maintain, share, and use business context.
2. Use EA to validate strategic planning and improve portfolio management decisions.
3. Use portfolio management to generate updates against IT strategy and EA design and plans.

He proceeded to go into detail on each of these. Overall, I think this was a good 100-level presentation to tell an audience of EA’s that they can’t ignore IT strategy efforts and PPM efforts. They need to be aligned with them. It could have been a bit more pragmatic to emphasize how one would go about doing this.

Presenter: Michael Raynor, Deloitte Consulting

This session is from Michael Raynor, author of “The Strategy Paradox.” The title is “The Accidental Strategist: Why uncertainty makes EA central to strategy.” He feels that it is ironic that there is a separation between the formulation of strategy and the implementation of strategy. He doesn’t agree with this approach. He feels that formulation and implementation should be a more interactive process and less linear, minimizing the strategic risk that an organization takes.

On this slide, his observation is that strategic uncertainty has been ignored. He used an example of the search engine competition of years ago and how, at least in part, Google won the space by making the best guess with regards to their strategy. It’s not that AltaVista made poor choices, they simply guessed wrong with what would be the most important factors in that marketplace. There is uncertainty associated with strategy.

An interesting anecdote he’s showing us now is that organizations that have a high commitment to strategy, which often times are the companies that we try to emulate, have an extremely high chance of failure, while companies with a relatively low commitment to strategy have a very low failure rate. To me, this seems be an example of low risk/low return and high risk/high return.

Extreme positions help customers know what to expect. Companies that are in the middle, “wander around like a stumbling drunk.” His example of the continuum was Wal-Mart at one end (cost differentiation, if given a choice of make it better or make it cheaper, Wal-Mart makes it cheaper), Nordstrom at the other end (product differentiation, Nordstrom makes it better), and Sears in the middle. Margins are best at the extremes and squeezed in the middle, yet most companies are in the middle. The reason is that at the extremes, it’s a winner take all approach. K-Mart can’t compete with Wal-Mart, Lord & Taylor couldn’t compete with Wal-Mart, yet Sears and JcPenney can both co-exist just fine. The reason for this is that companies in the middle have chosen to minimize their strategic risks. Companies at the extremes take on more risk in their strategic choices.

He’s now discussing Microsoft. He’s explaining the Microsoft manages strategic risk through their portfolio and understanding that things will change over time. This is different than diversification, where the profits of one division would cover losses in another. This is where if what’s important to revenue changes, the company is positioned to quickly leverage it. For example, if consolidation of computing in the home is centered at the gaming console rather than at the PC, Microsoft has XBox.

Another good example he’s presenting is Johnson & Johnson. Their Ethicon & Endo-Surgery division sells colonoscope, an area that previously differentiated on the technical excellence of the product. For growth, however, the problem was enough people weren’t getting colonoscopies. In the US & Canada, a colonoscopy is a sedated procedure, which greatly increases the cost associated with it. In order to manage the strategic risk that selling colonoscopes may switch and become a pain management rather than technical excellence issue, Johnson & Johnson’s VC arm invested in a company that was advancing sedation technologies. (Hopefully, I got this recap right…)

The metaphor that he believes captures how to manage strategic risk is not evolution, but gene therapy. That is, if the environment changes in certain ways, the genes can be recombined in new ways to leverage that environment appropriately. Good talk!

The presenter is Gary Doucet, the Chief Architect for the Government of Canada. His summary is that EA makes everything the business does better. EA needs to be ubiquitous, not owned by any single non-EA process. He emphasized that there are hidden architects all over the place, producing artifacts (artefacts, if you’re from Canada like him), that are the descriptions of the business today. EA’s role is to discover and align these efforts, not necessarily to own them all. Interesting talk.

Presenter: Betsy Burton

The presentation is starting out with a future vision statement. They believe that “by 2011, the majority of automated business processes at Global 1000 organizations will have evolved our thinking about processes with a shift from linear to nonlinear. Processes will have evolved to include a combination of formal workflow, information analysis, social networks, collaboration and ‘person-centric’ processes.”

She states that the goal of business architecture is to create the foundational artifacts for people to define the organization and enable change in the organization toward a future state. The interesting term in this statement for me is “organization.” Having roots in IT, we often want to talk about technology, and the application of technology, but when we bleed into organizational discussions, many architects think that it’s the job of management. Guess what? Organization can be an impediment or an enabler for being successful with technology so it is something that we need to think about. If it’s management’s responsibility, then invite them to the table and include them in the discussions so your efforts can be successful. As she just stated, “70% of what EA does is family counseling.” Don’t ignore the people!

She’s now moved on to the dimensions of business architecture. She includes people, financials, organization, and process. All of these are layered across the business functions of the organization. If we have these dimensions, we then need to develop requirements of business processes, the principles that guide people’s use of business processes, and the models of what the processes should look like in the current and end state. She now has a slide, and she’s showing an example of an anchor model and it’s importance to Enterprise Architecture. I’m really glad she called this out, because it aligns directly with my horizontal/vertical thinking I’ve mentioned before. I called this out back in the December EA Summit, and it’s nice to see that their thinking has continued to evolve. The anchor model is a representation of the business capabilities of the organization, and as the name suggests, it’s an anchor for other efforts like SOA and BPM.

There’s a ton of good information being presented here at a very fast pace, so I’m not going to keep trying to quote things. They’ve given a great walkthrough from the anchor model into some swim lane diagrams of processes, and have stated that this example is available online. If you’re a Gartner subscriber, and interested in this, I recommended looking for the “Bank XYZ” example artifacts that they have. As someone hoping to look more into business architecture in the future, I think this material is going to be very useful.

Her final recommendations in the standard Gartner powerpoint template are:

• Don’t do the business architecture in a vacuum.

• Focus on interdependent business and IT viewpoints, aligned in the solution architecture.
• Use a multidisciplinary team approach.
• Business architecture is much more than process optimization.

Presenter: Colleen Young

This is the opening keynote for the EA Summit. Colleen is telling us that we are the individuals that need to bring the message to the business that IT can contribute to growth, rather than simply being about back-end processes and support. Things that she says that are critical to success of EA:

1. EA’s must be bilingual- speaking the language of the business and the language of IT.
2. Architects must be political.
3. Architects must be influential. Architects need to be confident, with a firm grasp on the business’ needs.
4. Architects must deliver distinctive solutions. How do we do this? We need to evolve toward integrated IT and business strategic planning. Architecture needs to bridge the gap.

Overall, a good presentation.

Presenter: Andy Kyte

The title of this session is, “If You Had an Application Strategy, What Would It Look Like?” So far, I think I’m going to like it, because he’s emphasizing the need to manage the application lifecycle. That’s application lifecycle, not application development lifecycle. The application lifecycle ends when the last version of the application is removed from production. He’s emphasizing that an application is both an asset and a liability, with the liability being all of the people, technologies, and skills required to sustain it.

He’s now getting a ton of laughs by using a puppy/dog metaphor. He stated that we don’t buy a puppy, we buy a dog. It may be all cute and playful when we get it, but it will grow in a dog that sheds, eats, etc. Applications are the same way. Great quote just now: “Business cases are focused on putting applications in, and not on what to do after it. We are contributed to the problem by not addressing this.” He emphasizes that an application strategy should cover the next seven years, or half the expected remaining life of the application, whichever is the greater.

He’s now talking about stakeholder management and hitting on all the points I usually mention when talking about Service Lifecycle Management. The application is an asset, it must have an individual who is responsible for it, lifecycle decisions should be transparent, and all stakeholders (i.e. users of the application) must be identified and actively encouraged to play some role in the governance of the application.

The rest of the session is focusing in on the creation of the strategy document and making sure that it is a living, useful document. He’s emphasized that it is a plan, but also stressed the first law of planning: “No plan survives contact with the enemy.” It’s recognized that the plan is based on assumptions about the future. By documenting those assumptions, including leading indicators, leading contra-indicators, and expected timings, we can continually monitor and change the plan.

Overall, this is a very, very good session. What’s great about this is it is promoting a genuine change in thinking in the way that probably 90% of the companies here operate. Add a great speaker to the mix, and you’ve got a very good talk.

Raf Cammarano posted a great response to my last two blogs (here and here) on his blog. The title of his entry says it all: “No More Groups, Committees, Centres or Offices.” He asks the question whether a center of excellence or competency is even necessary at all. The risks he calls out are (with quotes from his blog):

1. Staffing: “Who is going to look after the other things when the best architects are poached by another group?”
2. Overlapping Responsibilities: “There will be huge overlap between the functions of the new group and the existing EA Group.”
3. Cross-functional teams are usually temporary: “The simple reason cross-functional groups are temporary is because the best people are reluctant to get off their career path within the business and move into a ‘special project’ permanently. SOA is not a ‘project’ and it’s certainly not ‘short term’.”

His recommendation is simple: “If your EA Group can’t deliver on everything that a Centre of Excellence would be expected to – then fix your EA Group!”

I really enjoyed this post as Raf raises many good comments that you should think about before you decide to go down the path. My posts were intended to offer some advice once you’ve made that decision, but it’s absolutely critical that you first look at whether it’s even needed. Addressing Raf’s concerns one at a time, let’s start with staffing. He’s absolutely right that staffing is a concern, as most groups aren’t willing to let someone go and live within some other virtual organization that controls their day to day activities. I’ve seen an organization where the top people, the ones who should have been driving the effort, specifically weren’t chosen due to the “hero” culture that existed and the dependency the organizations had created on them. I’d be willing to bet that these organizations may struggle to establish an EA team for the same reason. The successful COEs and Competency Centers I’ve seen had sponsorship from a very high level, typically the CIO or one management level beneath them. This helps prevent people from hanging on to resources that should be contributed at an enterprise level.

As for overlapping responsibilities, again this is certainly a risk. I’ve seen this resolved by actually assigning staff from EA to the COE, as well as having sponsorship from the Chief Architect. One thing to note, though. I think any COE or CC will have overlapping responsibilities with one or more organizations. It’s important that the COE is seen as an authority (just as EA must be seen as an authority) to help mediate when it occurs. The one thing you do want to avoid is complete overlap of responsibilities with another team. A COE or CC makes sense when there may be partial overlap and focus on the effort is needed. When there’s complete overlap, then you should have been looking at the team being overlapped to begin with, whether it’s EA or any other organization.

Finally, he points out that cross-functional groups are temporary. This was actually the original theme of my posts, so I don’t view this as a concern, but rather an option. What is bad is when a group that was supposed to be temporary lingers on indefinitely.

Anyways, thanks to Raf for the great comments. If you review my posts as part of your decision making process on a COE or CC, I suggest you review Raf’s as well.

In a blog entry last week and his podcast for this week, David Linthicum lamented the fact that many technology vendors are too focused on integration and not enough on architecture. My opinion on this is that the problem lies first with enterprises, and not with technology vendors.

In order to first explain this, I need to split the technology product space into two large groups. First, there are products that are pure infrastructure. They are platforms on which someone else builds solutions. This is the familiar space of database platforms, application servers, network appliances, EAI platforms, ESBs, MOM servers, etc. For products in this space, I have absolutely no problem with the vendors providing products that are focused on making integration easier. Does this enable enterprises to build up layers of “glue” in the middle? Absolutely, but at the same time, the enterprise had to have a need (whether perceived or real) to make their integration efforts easier.

The second group of technology products are the actual business solution providers, whether it’s a big suite from SAP or Oracle, web-based solutions like Workday and Salesforce.com, or anything in between. These vendors absolutely should be focused on architecture first. At the same time, I don’t think many of these products are being marketed and sold on their integration benefits, they’re being sold on their business capabilities.

So, what’s the problem then? The problem comes when the enterprise IT staff involved with technology identification and selection is too focused on integration, rather than architecture. Almost always, when I hear an enterprise talk about integration, it’s a just in time effort. Someone is building some new system and as part of the design of that system, they decide they need to talk to some other system. No thought of this need occurred in advance from either side of the integration effort. In putting together the solution, the focus is simply on the minimal amount of work to put the glue in the middle. As long as this trend continues, the infrastructure vendors are going to continue to market their products to this space. While it’s a noble quest to try to educate and market at the same time, it’s a risky strategy to present using a different mental model than your target audience.

The change that needs to occur is that integration needs to be a primary principle that is thought about at the time a system is placed into production. Normal behavior is to build a solution for my stakeholders and my users, and not think about anything else. In past posts (here, here), I’ve talked about three simple questions that all projects should start thinking about. One of those questions is “What services does your solution use / expose?” How many projects actually identifying anything other than just what their front end consumes? Does anyone see this as a problem? Let’s come back to the infrastructure vendors. They actually do need to think about architecture and services, but in a different space- management. I’ve railed on this in the past. How many vendors expose all of the capabilities in their user-facing management console through one or more service interfaces? If I want to embrace IT Systems Automation, how on earth am I going to do this what what these vendors give me? I’m not. I’m going to have to leverage management adapters in more automation environment. Does this sound familiar? It sure sounds like EAI to me. The best way I see to address this is think about integration in advance. Don’t think about it at the time someone comes and says, “I need to talk your system,” think about it at the time you build your solution and ask the question, “How will other systems need to interact with this.” Yes, this is a bit of predicting the future, and we’ll probably expose things that no one ever uses, but I think an enterprise will be in a better state if they try to anticipate in advance, thinking about architecture, rather that continue with today’s approach of integrate on demand.

Since Dave was nice enough to give me another shout out in his podcast this week, I thought I’d follow up in my blog. I thought he did a much better job in discussing my post when he said that these new breeds of applications and services that are available on demand are (my words) another tool in the toolbox of the enterprise architect. There’s no doubt that there are potential cost benefits to these platforms, and a review of them should be something you consider as your architecture evolves. Just remember, however, that they don’t define your architecture any more than any product installed on site defines your architecture. They only define your architecture if you let them, and that’s a bad situation. Rather, define your architecture, and choose the solutions that best fit your needs, whether it is building it in house, buying an off the shelf product to install on site, or going with a web-based provider. Don’t focus on functionality alone. Make sure that it aligns with your management needs and your information needs as best you know their future direction. You need to be in control, not at the control of your vendors.

A recent post from James McGovern reminded me about some thoughts I had after a few different meetings with vendors.

Vendors have a challenge, and it all stems from a view that they can be the center of the universe. A customer buys their product and builds around it, thereby becoming the “center of the universe” for that customer, exhibiting a gravitational field that attempts to mandate that all other products abide by its laws of physics. In other words, every other product must integrate with it, but that’s the responsibility of those products. For reasons I went into in my last post, that doesn’t work well. It’s a very inward-facing view rather than being the consumer-oriented view.

The challenge is that even if a vendor didn’t want to come across as the center of the universe, for some customers, it is required. For example, if a customer doesn’t have a handle on enterprise identity management, a vendor can shoot themselves in the foot if their own product doesn’t provide some primitive identity management capabilities to account for customers that don’t have an enterprise solution. In the systems management space, you may frequently hear the term “single pane of glass” intended for the Tier 1 operations person. Once again, however, every monitoring system that deals with a specialized portion of the infrastructure will have its own console. It’s a difficult challenge to open up that console to other monitoring sources, and it’s a difficult challenge to open up the data and events to an outside challenge. So what’s an enterprise to do?

To me, it all comes back to architecture. When evaluating these products, you have to evaluate them for architectural fit. Obviously, in order to do that, you need to have an architecture. The typical functional requirements don’t normal constitute an architecture. You can make this as complicated or as simple as you’d like. A passion of mine tends to be systems management capabilities, so I normally address this in an RFI/RFP with just one question:

Are all of the capabilities that are available in your user-facing management console also available as services callable by another system, orchestration engine, or script?

Now, there are obviously follow-ons to this question, but this does serve to open up the communication. Simply put, the best advice for corporate practitioners is to ensure that you are in charge of your architecture and setting the laws of physics for your universe, not the vendors you choose.

On the Yahoo SOA group, there’s been a long conversation going on regarding (among other things) whether or processes operate at a higher level of abstraction than services which inevitably leads to a BPM first or SOA first debate. For the record, I don’t think that a process-centric approach necessarily leads to success. I made the point that I’ve seen first hand where a process-based viewpoint did nothing more than turn the silos 90 degrees. That is, where we previously had some capability locked away inside an application and only of value to that application, we now have the same capability locked away in a process, and only of value to that process. Both situations can be problematic. A service-centric approach, however, where we focus on a business capability and build outward focusing on consumption, seems to represent that “middle-out” approach.

Anyway, to get to the point of the post, a comment that both I and Anne Thomas Manes of the Burton Group made is that we’ve seen very few (in my case none) organizations that are structured around this notion of capabilities. Rob Eamon, a frequent commenter on this blog, replied to one of Anne’s messages (where she suggested that IT organize around capabilities) with this:

What does this really look like? Does the business organization line up in any way with the capabilities? What is the interaction between those responsible for business and those responsible for IT? Does business group A accept that “capability group X” has responsibility for business groups A, B, C, M, and N? So before capability X can be extended or changed, coordination is needed with all of them? Or is there a proliferation of different interfaces for X? …To paraphrase an old, old Byte magazine humor piece (http://home.tiac.net/~cri/1998/elehunt.html), we have little information about hunting the elephants but lots and lots about packing the jeep.

I thought Rob’s message was great, and one that we should all think about. SOA isn’t a panacea for all things wrong in IT, and even more importantly, if it isn’t broken, don’t fix it. That being said, there’s also a lot of “well, we’ve been doing it this way for 20 years and nothing has fallen apart yet” mentality as well, and the right answer certainly lies somewhere in the middle.

Getting back to Rob’s message, he presents a scenario where 5 business groups all need a common capability. If this is the case, the question is how is that being handled today, and is it a problem? If all 5 groups have their own implementation of that capability, is that an issue or not? If the current organization handles that dependency fine, and the current path is in alignment with the long term strategy, why change anything? If it’s not in alignment with the long term strategy, then you have justification to change. The real disaster is when we don’t even know that those common capabilities exist. Then, you don’t even know whether you have a problem or not, and by the time you figure it out, you now lack the time to get it fixed. This is the situation where I think most organizations are. They’ve read the press and think SOA has potential. They know that there is room for improvement in the IT/Business relationship. Beyond that point, it gets really fuzzy. An integration-centric approach to SOA has some legs, but that really lives in the IT space and produces incremental gains, at best. Any other approach really requires some analysis of the business and the information technology that supports it to determine whether there’s value to be obtained or not. Unless someone has that view, it’s hard to say whether enterprise SOA will provide significant value or not. I’d go so far to say that it’s difficult to say whether anything of a strategic nature will provide significant value or not.

So, the question remains, how do you organize for SOA? Clearly, there’s no one answer. As many, many people have said, it has to start with the business and the things it’s trying to do. As Rob suggested in his message, simply changing the structure of IT may not be enough. If the business side hasn’t recognized that there are benefits to leveraging shared services, then anything IT does along those business capabilities may not help. Sure, there are some things that can be done strictly within IT, but those have more to do with the business of IT, than the true business. Any change in organization has to make sense for the business objectives, however. Take sales and marketing as an example. There are plenty of organizations that have shared sales and marketing, and plenty of organizations that have separate sales and marketing organizations along some other dimension. I think the same thing will likely hold true for organizing around SOA. Where the business needs dictate shared business capabilities, you adjust the organization, both business and IT. Where the business needs don’t, efforts to push SOA may run into resistance. If the business lacks the necessary domain knowledge to know where SOA can fit and where it may not, then it really doesn’t matter what structure you pick, it’s going to be a struggle.

It’s been a while since I’ve blogged (a really nasty sinus infection contributed to that), so this comic seemed appropriate.

Anyway, I, like many other people, did a double-take after I read this blog post from Anne Thomas Manes of the Burton Group. In it, Anne states:

It has become clear to me that SOA is not working in most organizations. … I’ve talked to many companies that have implemented stunningly beautiful SOA infrastructures … deploying the best technology the industry has to offer … And yet these SOA initiatives invariably stall out. … They have yet to demonstrate how all this infrastructure yields any business value. More to the point, the techies have not been able to explain to the business units why they should adopt a better attitude about sharing and collaboration. … Thus far I have interviewed only one company that I would classify as a SOA success story.

I’ve always believed that the changes associated with SOA adoption were a long term effort, at least 5 years or so, but it was very surprising to only see Anne only find one success story, although further comments indicated she had only talked to 7 companies. 1 out of 7 certainly feels right to me. Things became even more interesting, though, with some comments on the post which indicated that Anne’s definition of success was, “Has the initiative delivered any of the benefits specified as the goals of the initiative?” She indicated that every company said that their goals were cost reduction and increased agility. My question is how did they measure this?

Another recent post that weighs into this was Mike Kavis’ post on EA, SOA, and change. Mike quotes Kotter’s 8 steps for transformation which include creating a vision and communicating a vision. Taking this back to Anne’s comments, if a company’s SOA goals are increased agility, my first question is how do you measure your agility today? Then, where do you want it to be at some point in the future (creating the vision)? If you can’t quantify what agility is, how can you ever claim success? Questions about success then are completely subjective, rendering surveys that go across organizations somewhat meaningless. While cost reduction may appear to be more easily quantified, I’d argue that many organizations aren’t currenlty collecting metrics that can give an accurate picture of development costs other than at a very coarse-grained level. It would be very difficult to attribute any cost reduction (or lack thereof) to SOA or anything else that changed in the development process.

This brings me to the heart of this post- setting expectations for your SOA efforts and measuring the success of your SOA journey is not an easy thing to do. Broad, qualitative things like “increased agility” and “reduced costs” may be very difficult to attribute directly to an SOA effort and may also fail to address the real challenge with SOA, which is culture change. If culture change is now your goal, then you need to work to describe the before and after states, as well as some tactical steps to get there. In a comment I made on one of my own posts from quite some time ago, I spoke of three questions that all projects should be asked:

1. What services does your solution use / expose?
2. What events does your solution consume / publish?
3. What business process(es) does your solution support?

The point of those three questions was that I felt that many projects today probably couldn’t provide answers to those questions. That behavior needs to change. Now while these were very tactical, they were also easily digestible by an organization. The first step of change was simply to get people thinking about these things. The future state certainly had solutions leveraging reusable services, but I didn’t expect projects to do so out of the gate. I did expect projects to be able to tell me what services and events they were exposing and publishing, though.

This type of process can then lead to one of the success factors that Anne called out in her comments which was the creation of a portfolio of services. Rather than starting out with a goal of “cost reduction” or “increased agility”, start out with a goal of “create a service portfolio.” This sets the organization up for an appropriate milestone on the journey rather than exclusively focusing on the end state. Without interim, achievable milestones, that end state will simply remain as an ever-elusive pot of gold at the end of the rainbow.