What is Successful SOA?

Monday, November 30, 2009 |

It's a timely topic given all the interest lately in measuring the value of SOA. After all, success or failure in a given organization is utterly dependent on adoption - whether by stealth of by fiat. So timely, that I ran across an interesting poll around SOA Governance in LinkedIn Groups that I'm reposting with the link:

Which of the following elements essential for successful SOA?

  • a) Service Management and Governance

  • b) SOA Reference Architecture

  • c) SOA Maturity Model

  • d) Service Registry
Be a part of our survey: http://bit.ly/2H8W1X

The real answer, of course, is all of the above, and none of the above. SOA is not about SOA governance, regardless of what vendors in that space will have you believe. Governance is just a management approach to ensure that SOA investments to become too complex. SOA is a disciplined approach to building technology capabilities, so while the options given in the poll are useful, they are not a necessity. Even with all of the technical capabilities in place, SOA adoption may fail (and has in several instances). Without modification to the business, organizational and risk mitigation capabilities (depending on Business Operating Model) technology itself is a money pit. In case of SOA, or any other large scale change program, success is unlikely through 'if you build it they will come' approach. Chances are, if you build it, and the organization is not ready for it, nobody will show up to your SOA party.


Why Reference Architecture(s)? (Part 2)

Monday, November 23, 2009 |

The first post elicited quite a few great comments, so here's part deux.

To the right is a sanitized example of a hierarchical federated EA model*. At the top level of EA Framework reside the Reference Models. These models are quite flexible and can accommodate multitude of notations and purposes - some examples would be SOA Reference Model (from OASIS, for instance) or PMI Reference Model better known as PMBOK. In short, these are the "meta" portions of what we do and how we do it. They provide the vocabulary and rules of engagement. Whether they are acknowledged formally - or not, as the case may be - these models are in use in every single for-profit and non-profit entity.

Within these reference models reside Reference Architectures. So why are Reference Architectures valuable? The real value is the glue that they provide between conceptual realm of Reference Models and the two Brick and Pattern layers below. The Reference Models have a level of complexity that is difficult to translate into working process and technology. The value of Reference Architecture is in complexity reduction that is suited for implementation. For example, a Security Reference Architecture would contain Architecture Patterns (logical solutions for technical security capabilities like Authentication, Authorization, Access Control, et al) and Physical Patterns (here's how our organization implements role-based access control in J2EE-based application layer or here's how our organization implements authorization for .NET-based application layer, etc.)

ROI of any such Reference Architectures to an organization can then be tracked through the adoption of these patterns in both pre-project and project activities. While concrete value is through implementation, to quote Deming: "In God we trust; all others must bring data." If these patterns are implemented, but nobody collects metrics to validate and update ROI for Reference Architectures, it never happened. Also, collecting useful metrics on value through adoption must start when a project is in planning phases. Comparisons between Ref-Arch based solutions sets and point solution sets should be a part of decision-making process (that may sound like heresy coming from a former Chief Architect, but point solutions do have their place in our tool belt.) True costs and value of these decisions need to be documented and presented to the stakeholders who own the P&L that is impacted both before, during and after projects. I've never heard of a stakeholder frown during "here's how much money we saved you this quarter" portion of a regular update - as long as those numbers were backed up by agreed to and solid metrics.

That brings me to the "gray" row in the Reference Architecture Hierarchy. The color choice is apt because there is a tremendous amount of ambiguity involved in connecting Reference Architecture artifacts with Projects. Successful linkage depends on many "soft" things like organizational culture(s), human resource strategies, and stakeholder alignment - just to name a few. Without implementation of methods and processes in the "gray" row, however, there is little chance that those who promote, and sometimes evangelize, the concept of Reference Architecture will be able to demonstrate value on a sustainable basis.


* Domain Architecture Frameworks are not necessarily the same as the Enterprise Framework for some Business Operating Models. For Business Operating Models that do not require federation across business units, this may not be applicable so EA and DA levels can be combined.

IT Finance: Why Capabilities?

Tuesday, November 10, 2009 |

Why is Technology Investment Management Method (TIMM) focused on Capabilities?

If we look at the IT finance arena, from which viewpoint we would like to valuate an IT investment, the investment should look like something multiple stakeholders can easily comprehend in the same or similar way. Such an investment must have boundaries that are semantically clear. And clear means clear to the customer who would attribute value to the investment.

Traditionally IT systems, and all types of staff have been targets for valuation. Departments, divisions, products, customer acquisition systems and backend processing systems, infrastructure all fall into the current valuation perspective. But if that mix feels a bit disjointed then it could be a problem. Departments, divisions, etc. are all things in the generic sense but they’re not peers. Some of them depend on others. Also they don’t always resemble each other enough for a fair comparison much less a comparative valuation. There are too many details to manage in an annual planning effort.

So what to do?

By talking to your IT consumers and using the capabilities they want to qualify their goals you will move away from telling them about your services to a dialog about how you can satisfy them. The capability approach uses a consumer perspective to define consumer investment and it is based on their language and knowledge.

From Marketing Myopia, Harvard Business Review, Jul 01, 2004 by Theodore Levitt, “It is constant watchfulness for opportunities to apply their technical know-how to the creation of customer-satisfying uses that accounts for their prodigious output of successful new products.” Mr. Levitt was writing about Dupont and Corning but the same holds true for IT Finance and how IT Finance can serve their customers, consumers of IT services.

Organizations have many consumers, business, technical, risk, and human resources at a minimum. Each of these groups look at their organization in a different way. Each requires its own view. But the views sometimes overlap slightly and they clearly interconnect in support of each other.

So TIMM uses the detail of all these systems, technology infrastructure pieces, departments to validate what we call Capabilities. These capabilities are lightweight, logical, abstract, conceptually meaningful to stakeholders from one area to another in the consumer pantheon listed above.

Using capabilities with which to plan gives all stakeholders a handle on a range of topics that they can easily identify and comprehend in the same way across consumer disciplines (the pantheon again). And because they can easily understand what they are, the valuation task becomes much simpler and direct.

That is an important breakthrough and a big deal.

Poll Results

Thursday, November 5, 2009 |

For the month of October, we asked our readers which Sample Capability Map would be of most value to them. Of the possible answers (Enterprise Architecture, Office of the CIO, Technology Finance, Governance Risk and Compliance, and Portfolio Management) it wound up being a tie between Office of the CIO and GRC. So look for these two sample capability maps to make an appearance in the next two months!

Thank you for your participation,


Chatting Up the Relationship between Capabilities & Projects

Monday, November 2, 2009 |

The posts on this blog have mentioned capabilities quite often. I thought we'd dive into the relationship between capabilities and projects for a moment. Here we go...

Can a project embody a single capability at a time? Yes. Can a project deliver multiple capabilities at the same time? Yes. Can multiple projects deliver a single capability? Yes.
Is there a preferred relationship of projects to capabilities? Yes, there probably is -- and the relationship most relevant to your corporate planning culture is likely different than the relationship most relevant to anyone else’s corporate planning culture. We are at the beginning of our understanding of business capability-based project planning. There are no ‘best practices’ as of this writing.

But still, why are there so many possible project-to-capability combinations? The reason is that different layers of capabilities represent different layers of granularity. The closer you move toward the technology layers, the more granular the layer becomes. As the granularity
approaches the typical project granularity in your organization the more comfortable you will be in seeing the capability as a project candidate.
A sample process that determines project-to-capability relationships should work something like this: First perform the capability identification and analysis; that is, identify the high level capabilities and then perform the decomposition. After you have two or three levels of capabilities and their dependencies see if you understand their value to the business. Value as well as dependencies determines build order. After that, see if the capability granularity makes sense to turn the capabilities into projects. Here is a quick view of the same:

Figure 1 – Quick Path Capability Identification Process

Some people will have trouble separating the abstraction for capabilities useful in planning from the exercise of identifying capabilities for projects. But good governance practices such as separation of duties can help. Separate the analysis from the project identification phases and let different roles address those steps.

If you’re having difficulty breaking capabilities into projects, the capabilities you’ve identified are either too broad or too granular for your corporate planning culture. Try rolling them up or decomposing them further for better results. Organizations that employ capability-based project planning will find that they develop new terminology around projects. Communicating the value of your projects will become easier. Capability-based projects will be in the language of your domain because capabilities are already in your domain’s language.

For more information download the white paper: Will the Capability Revolution Cause Project Evolution? (July 2009).