The SOA Manifesto is to a business perspective as...

Thursday, January 28, 2010 |

The SOA Manifesto published in 2009 contains a few references to SOA’s importance to business. If we take the idea of “business value“ or business related directives within the SOA Manifesto part of the SOA Manifesto as opposed to the Guiding Principles part of the SOA Manifesto we see that about 3 out of 9 statements relate to the business. Specifically, we have words like ”sustainable business value,“ ”Business Value“, and ”Strategic Goals“ in this section.

The Guiding Principles section repeats the same pattern of emphasis where the following lines may qualify as business related:

  • Identify services through collaboration with business and technology stakeholders.
  • Verify that services satisfy business requirements and goals.
  • Evolve services and their organization in response to real use.
I realize that this 3 out of 14 record may not convince you that SOA practitioners are serious about business alignment despite their insistence to the contrary but this is probably better than it was before they made their statement. Even if the SOA Manifesto is weak business-wise it was probably necessary to say it and we can thank the signatories for their hard work.

Now we can move on as a community. Now that we have some agreement on SOA as a platform of thought maybe we can apply the same patterns that services bring to technology to other areas such as organization, risk, and business. Then we can also tackle the myth of a monolithic SOA definition.

The Business of Manifestos

Tuesday, January 26, 2010 |

My short and brief research on manifestos started with my reading of the SOA Manifesto published in 2009. I have a couple of responses, one about the need for manifestos in software related causes and the SOA Manifesto in particular.

Let’s start with what I consider the comical side of software manifestos. In general manifestos first applied to political statements, serious political statements about what the authors considered life and death issues. Witness the short list below:

Manifesto of the Communist Party
Unabomber Manifesto

There’s also the Chipotle Mexican Grill Manifesto here.

Their juxtaposition certainly stretches the idea of what a manifesto is and who can use that particular form of expression. Like the term ‘Whitepaper’ it has taken a spectacular popularization of purpose.

Here are some links to software manifestos.

GNU Operating System Manifesto
Manifesto for Agile Software Development

The need for a SOA Manifesto is rationally explained by Thomas Erl here. But despite his reasonableness and the lucid principles expressed in the SOA Manifesto how can such a proclamation help business, P&L owners, understand the need for SOA? If SOA is for business then its primary expression should be directed to business leaders in business terms, no?

Does a SOA manifesto help here?

Business Operating Model of IT (Part 2)

Wednesday, January 20, 2010 |

In the last post of 2009, I asked business leaders how they can be proactive in assuring that their technology leadership is properly aligned and delivering the decision-grade information they need to make the optimal technology investments. Several of them replied in private, so I'll paraphrase these conversations (along with some very interesting tweets) in this post. In today's world of Information Technology, the question of Business/IT Alignment seems to be asked by lines of business struggling to understand optimal use of technology while, at the same time, the IT departments struggling to justify necessary budget levels, seem obsessed by the issue. In reality, it takes two to tango. Perhaps, if we start with a presumption that IT does indeed have a business model that is sufficiently differentiated from a line of business operating model, perhaps we can shine a bit more light on the subject.
In "Enterprise Architecture as Strategy", Jeanne Ross et al lay out the notion of Business Operating Model. This is not new to regular readers of this blog - we've been exploring this concept and its implications for quite a while! They also provide the four common models - Diversified, Unified, Replicated, and Coordinated. They then provide a set of rough Business/Technology alignment constraints with what they call "Enterprise Architecture States." What's interesting to note is that Business Operating Model types can be applied to the IT Department as well as the business under which they operate. We can see these operating model types in IT Departments regardless of size, type, and vertical. For instance, in a diversified model, separate IT departments will run separate networks, separate mail servers, separate shared drives, separate everything. And yet, if Enterprise Architecture States can be properly applied in this context, it suggests that IT Business Operating Model can be assessed and assured via these states just like any other line of business Operating Model.

As I noted in my last post, our capability models illustrate that there are two inherently competing business models within IT - run the lights (don't rock the boat) and technology as competitive advantage (invent new boats or move the boat around). I see this conflict in the formation and dissolution of Enterprise Architecture, Portfolio Management, Business Architecture and other efforts that collectively define the "Office of the CIO" - a regular occurrence in most large organizations. Some of this is certainly due to a dearth of qualified resources, an issue that several groups (e.g. CAEAP, PMI) are trying to address. However, most of these organizational changes occur within technology groups. So perhaps a lot of this upheaval is due to the inherent conflict between the “run the lights” and “technology as competitive advantage” perspectives? Regardless of root cause, this internal IT fracture regularly contributes to IT/Business misalignment rather than alignment.

Another source of IT organization instability comes from a lack of segregation of duties, a violation of one of the enduring models for organizational stability. A technology organization responsible for both perspectives, governance and execution, will be inherently unstable, and therefore unable to sustainably align with the Business, because the priorities are not just competing - they are polar opposites. This point has not gone unnoticed by others. Chris Curran's concept of IT Czar that sits outside of IT is just the latest in this chain of thought. The flurry of thought activity around Running IT as a Line of Business (RITLAB here, here, and here) on both sides of the debate is also contributing to the conversation. But while the technology management thought leaders argue about the concept, here's the reality on the ground: as our Technology Investment Management practice has evolved, several new engagements follow the model of our technology investment managers reporting directly to the business leaders responsible for profit and loss. Besides being good business practice for our clients, this seems to strike the right organizational alignment cord with my risk management experience: oversight is rarely effective when those who are overseen are conducting it.

Value of Enterprise Architecture in a Diversified Business Operating Model

Sunday, January 10, 2010 |

This question came to me from Bala Somasundaram via LinkedIn, and is being reposted with author's permission


Read your blog post on Business Operating Model mismatch during M&A and how EA/Capabilities can help iron out some of the persistent problems.

I wanted to discuss with you on other point. As mentioned in the book EA as Strategy book, some of the models - for e.g. - Diversified - models are able to grow inorganically by making mergers/acquisitions - especially large ones. They are clearly profitable and clearly growing year-on-year. But, they dont necessarily do EA-led planning or treat IT as their competitive advantage. [Am sure many leading businesses/CEOs dont treat IT as their partners, instead a utility].

In the book, authors have mentioned that such companies would rely on their pure 'management' capabilities rather than architecture capabilities.

So, what do you think, from your perspective that would make a case for EA in such operating models?
There are two parts to the answer - first, when we released our Enterprise Architecture Capability Map into the wild, one of the accompanying caveats was that maturity of each capability would be dependent on several factors, including Business Operating Model (both as-is and to-be.) Second part of the answer is done in a roundabout through application of Appropriate Use for Enterprise Architecture - full EA is of limited value in such context, however, parts of what EA should be responsible for can be leveraged for competitive advantage as detailed in my Object Management Group presentation.