My statement today is that SOA’s definition greatly lacks a business context. Even the term itself, SOA, feels monolithic in its application as if once size fits all. While SOA yields services for business, the community of SOA proponents has not included a definition of SOA along business operating models but along the model of their own technical experience and insight.

I’m tired of hearing about SOA as something in singular form when business reality indicates that it takes many forms. And it’s not just that different organizations have different sized SOA projects or deploy SOA to support different customer facing situations. It is that business operating models can differ so much that their respective SOA naturally differs by equal measure.

That difference means that SOA strategy from one company to another would be unrecognizable.

Look at a company that has absorbed other companies over time. It probably has a set of business and technology silos to deal with. Depending on how many customers these silos share, SOA will look quite different to this company than to a company that has a large catalog of products that its customers choose from,,, meaning that the catalog company has a large set of similar customers while the company that requires silos to support its customers is quite diversified. If business units don’t share customers then they don’t share customer data either. And if you’re not sharing customer data then you don’t need to share services do you?

In a diversified company one of the things that business silos can share, since they don’t share customers, is the technology base: network, servers, security infrastructure, application platforms. The reason for sharing these “services” in a diversified company is to support a single business goal: Reduction of Cost of Goods Sold.

So in what way would SOA apply to such a company? At the enterprise level it would apply in the areas mentioned in the previous paragraph: network, servers, security infrastructure, and application platforms. But these aren’t generally regarded as business services. They are technical services. Possibly some shared and centralized services could be built around HR, Accounting, and Sales Reporting. But this would take business ownership of business architecture and a vision of reducing costs across an organization that is organically divided to support its customers, in other words, to do its business.

SOA can still be used within a business unit in the usual way proscribed by SOA proponents as long as customers within the business unit are shared by the different product groups; otherwise, the same pattern of diversification appears at the business unit level.

The takeaway here is this: there is an enterprise level of SOA and possibly a divisional level of SOA. the extent to which, services are shared within a division. The enterprise level of SOA depends on the business operating model and how diverse the model is. The less diverse the more sharing of services can occur.

If you are a proponent of SOA you need to understand the business operating model implications and constraints on your SOA.

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.

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?

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.

AAB

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

Aleks,

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.

AAB