Pay As You Go

In a recent post, Dave Linthicum talked about the Pay As You Go Challenge, and describes the benefits of Pay-As-You-Go in terms of shifting the risk from the user to the provider. Instead of the user paying for something upfront, before even knowing whether something works (generally, or in that particular use-context), the user pays only if and when it works, and can cancel at any time.

This pay-as-you-go model applies to software-as-a-service of course, and Dave urges that SOA vendors should adopt this model for SOA platforms as well, in other words, something like platform-as-a-service.

But there is a more fundamental economic basis for the pay-as-you-go model, which Dave doesn't mention. As well as shifting risk, the model shifts the balance of costs for the user - from fixed costs to variable costs.

Put very simply, the user's total cost equals fixed cost plus variable cost. Variable cost increases with volume, while fixed costs stay the same. (If you want a more sophisticated explanation, ask a friendly accountant.) Now fixed costs are subject to the economics of scale. If the user has a business process with a significant proportion of fixed costs, then the average cost will go down as the volumes go up. In some cases, a fixed-cost business process may only be economically viable if a constantly high volume can be maintained. But with a variable-cost business process, the average cost is much less affected by volume, and it is possible for the process to remain economically viable across a much wider and perhaps fluctuating range. In other words, a variable-cost process is much more adaptable to changing levels of demand than a fixed-cost process.

And this is where SOA comes in. Under certain circumstances, SOA can support the shift from fixed-cost to variable cost, and therefore can release a whole set of benefits related to adaptability and economic viability - the so-called On-Demand Business.

But only under certain circumstances. The problem isn't with the technology; the problem is with the traditional structures of funding and cross-charging within a typical enterprise or ecosystem or marketplace, which can make it rather difficult to establish adequate pay-as-you-go mechanisms, especially if noone else is doing it yet.

Thus pay-as-you-go is generally more difficult than traditional funding and charging mechanisms. If you are just starting out on your SOA journey, it might make sense for you to defer these difficulties until you have developed some experience and capability in other areas.

And this is where an SOA Adoption Roadmap or Maturity Model comes in. The purpose of one of these is to help you work out which capabilities you need in order to achieve which classes of benefit, and to help you tackle the difficulties in an organized fashion.

SOA Centre of Excellence

When I was researching my article on Organization Models for SOA Adoption (CBDI Journal, June 2007), I found lots of people talking about Centres of Excellence (CoE). But they all meant different things by that. Consultancies often use the term to refer to their own SOA practices, rather than something that explicitly supports the organizational change required for SOA adoption across a large enterprise.

Apart from that, I found three alternative models of CoE.

• Body of Expertise
• Vehicle for Change
• Champion of Excellence

Obviously if you define the CoE solely as a vehicle for change, then it has no further purpose once the change is complete. But in many cases, we would recommend a composite model of CoE, in which the CoE may have an ongoing role in terms of expertise and excellence.

Some of the functions of the CoE in the early stages will be spun off into other organization structures, or merged into mainstream IT management, as SOA spreads through the organization. For example, at some (indeterminate) point the SOA Programme Office simply turns into the Programme Office for the whole of IT.

There are questions of scalability here. If you have an IT organization over 5000 people, you might start with a small CoE team, running pilot projects and then controlling perhaps as many as a few dozen projects, perhaps 200+ developers, perhaps even growing to 5% - 10% of the whole of IT.

But when SOA coverage gets above 25%, you're talking about supporting (probably not controlling) thousands of developers, you're talking about a significant chunk of the entire IT budget. Although there may still be a role for a CoE as a facilitator, the main IT functions (including planning, programme management, coordination/integration and infrastructure) are almost certainly going to be run by experienced IT managers rather than SOA experts.

The CoE therefore needs to establish good SOA-friendly processes for all aspects of IT management, and then transfer these processes over to mainstream IT management. The CoE may still exist, but remains relatively small and certainly shouldn't grow in proportion to the growth of SOA across the organization.

Original Article: SOA Center of Excellence and other Organizational Support Models - Organizational infrastructure for SOA Adoption and Excellence (CBDI Journal, June 2007).

Barriers to SOA adoption

ZapThink is getting a lot of coverage from a recent post blaming the IT department as a barrier to SOA adoption. See also discussion by Todd Biske.

I went through the first couple dozen hits on Google for "barrier SOA adoption", and identified a number of competing ideas. (Some links no longer current / available.)

The Organization Itself

says CBDI

IT Department

says Zapthink

XML Skills

says Perficient

Lack of Business Justification

says IDG

Vision, People, Management and Resources

says InfoSys

Lack of awareness and familiarity with SOA

says Vinita Gupta, journalist

Complexity

says BEA

IT Integration and Flexibility

says Sandy Carter of IBM

Detangling the web of applications and old systems

says NSW Police

Lack of discretionary spending in IT

says Dana Gardner of Interarbor Solutions

The Desktop

says ZDNet

Resistance to Change

says IDC

---

Additional resources on SOA adoption

Roadmap - PGFSOA Wiki

A Roadmap for SOA adoption - from the Practical Guide to Federal SOA (PGFSOA)
See also PGFSOA Version 1.1 (PDF June 2008)

CBDi Web Services Roadmap

CBDI Web Services Roadmap - Guiding the Transition to Web Service and SOA

Richard Veryard on SOA Adoption

Selected posts from Richard Veryard's SOAPbox blog.

---

Todd Biske adds

While resistance to change and the organization itself are somewhat the same thing, my instinct is that it's the broader organization that is typically the barrier, and it's usually that the entire org is resistant to change. (May 11, 2007)

Updated 18 Feb 2016

SOA Maturity Models

David Sprott (CBDI) and Jason Bloomberg (ZapThink) are both critical of the attempts by vendors to produce so-called Maturity Models for SOA - especially the recent attempt by four SOA vendors (AmberPoint, BearingPoint, SonicSoftware and Systinet). (White paper via eBizQ.)

Part of the problem is a failure to understand the difference between a maturity model and a roadmap. While a roadmap is (or at least should be) a practical template plan, based on a consolidation of experience from many organizations, a maturity model is a more theoretically grounded framework, based on a logical analysis of capabilities and their dependencies.

The essential tone of a roadmap is supportive, helpful. It gives you permission to tackle things in a manageable sequence. Start here, it says, and feel free to defer these more advanced matters until later.

The essential tone of a maturity model, on the other hand, is parental. Don't imagine you can get anywhere with X until you have mastered Y. Don't walk until you can run. You're not old enough to buy alcohol, cigarettes, knives or glue. Have you finished your homework? Eat your greens, and be home before ten.

One of the strongest messages that came out of the SEI's earliest process improvement work was a negative one - don't even think about implementing tools until you've sorted the process out. These are the kind of statements from which a maturity model is built.

In order to substantiate such statements properly, you need a model of capabilities and their dependencies. (For example, what capabilities are dependent upon a given set of metrics.) This is why a maturity model (of the kind we're talking about here) is always (implicitly if not explicitly) a capability maturity model. (I have been talking to Microsoft recently about their Capability Modelling method, known as Motion, which has some interesting uses for service-oriented analysis and design, but is also relevant for building maturity models.)

And this is the source of confusion behind some of the SOA Maturity Models that are being disseminated. What exactly are the capabilities that are being referenced here - capabilities in developing service-oriented solutions, or the service capabilities themselves? (If both, how tightly coupled are they?) Whose maturity are we talking about - the IT development organization or the whole service-oriented business?

At the end of the 4vendor white paper, each vendor provides a summary of its own tool capability in respect of the so-called maturity levels. After comparing these summaries carefully, I got a strong impression that each of the four vendors has interpreted the levels in a different way. In any case, what is the correct marketing strategy for a vendor - to support Level 5 (and imply that customers shouldn't implement these tools until they have reached the right maturity level) or to support Levels 1 and 2 (and imply that the tools are only good for beginners)?

No doubt some vendors like to appeal to the ego of their customers. ("Only the most clever and sophisticated user can deploy our tool successfully.") But this sounds like adolescents selling to adolescents.

“Adolescence is a series of unsuccessful attempts to skip adolescence.” [Jon Elster, Making Sense of Marx (Cambridge University Press, 1985) p 306]

Perhaps vendors would be wiser to stick to Roadmaps. Or better still, leave the Roadmaps to the industry analysts (click here for the CBDI Roadmap) and stick to implementing products and solutions.

Technorati Tags: capability maturity maturity model roadmap SOA service-oriented

Supply Chain Complexity

Clive Longbottom of Quocirca has just published a survey of the adoption by medium to large organizations of supply chain automation. Here is his conclusion.

Automation of transactions has long been touted as an enabler of efficiency in the B2B supply and demand chains. The irony is, however, that the more broadly organisations attempt to apply automation, the more they fall foul of the complexity and expense of dealing with the myriad of technologies and standards that exists across their customer and supplier bases. Few have the capability to solve this problem in-house cost effectively, so outsourcing options that leverage economies of scale are key to achieving broad and inclusive automation and realising the benefits that come from this. (via Conmergence blog)

There are many sources of supply chain complexity implied in this piece, besides the complexity and continuing evolution of technical standards.

• a significant focus on ad hoc activity particularly with customers, where one off sales are common
• large numbers of partners with differing characteristics and capabilities
• high complexity in the standards
• rate of change of partners’ technical solutions
• multiple versions of standards in the value chain
• geopolitical issues e.g. local legal, native language and logistical issues
• myriad of technologies and standards

While it seems like a good idea to delegate some of these dimensions of complexity to a managed service provider, this may not be appropriate for all of them. The most obvious solution is that the service provider handles the technological complexity, leaving the company to concentrate on the business complexity. However, it is unlikely to be as simple as this in practice, because of possible interactions between the technological complexity and the business complexity.

What is needed here is to analyse the dimensions of complexity in detail (obviously this analysis won't be identical for different companies) and produce a service geometry with a clean but flexible division between core and non-core.

Technorati Tags: B2B complexity outsourcing supply chain technology adoption

Purpose-Agnostic

Sean McGrath (Propylon) thinks purpose-agnosticism to be one of the really useful bits of SOA. He refers to a posting he made to the Yahoo SOA group in June 2003, where he wrote:

The real trick with EAI I think, is to get purpose-agnostic data representations of business level concepts like person, invoice, bill of lading etc., flowing around processing nodes.

The purpose-agnostic bit is the most important bit. OO is predicated on a crystal ball - developers will have sufficient perfect foresight to expose everything you might need via an API.

History has shown that none of us have such crystal balls.

Now if I just send you the data I hold, and you just send me the data you hold - using as thin an API as we can muster - we don't have to doubleguess each other.

Propylon has been implementing this idea in some technologies for the Irish Government.

• IAMS (Inter-Agency Messaging System)
• PSB (Public Services Broker)

However, Sean believes that purpose agnosticism can only be pushed so far. He cites the service example “test for eligibility for free telephone allowance”, which is evidently purpose-specific. Thus there are some areas where very prescriptive messages (which Sean calls "perlocutionary") are more appropriate.

Let's push this example back a little. Why does B need to know if a particular customer is entitled to a free telephone allowance? Only because it alters the way B acts in relation to this customer. We should be able to derive what B needs to know from (a model of) the required variety of B's behaviour. Let's suppose B delivers a telephone to the customer and also produces an invoice. And let's suppose the free telephone allowance affects the invoice but not the delivery. Then we can decompose B into B1 and B2, where only B2 needs to know about the free telephone allowance, allowing us to increase the decoupling between B1 and A. Furthermore, the invoice production may draw upon a range of possible allowances and surcharges, of which the free telephone allowance is just one instance.

On a cursory view, it appears that the technologies Sean has been building for the Irish Government support a programme of deconfliction - using some aspects of SOA (or whatever you want to call it) to separate sociotechnical systems into loosely coupled subsystems. If this is done right, it should deliver both IT benefits (productivity, reuse) and business benefits. This is all good stuff.

---

Joined-Up Services - Trust and Semantics

But the deconfliction agenda leads to a new set of questions about joined-up services - what emerges when the services interact, sometimes in complex ways? How do you impose constraints on the possible interactions? For example, there may be system-level requirements relating to privacy and trust.

One aspect of trust is that you only give data to people who aren't going to abuse it. Look at the current fuss in the US about data leakage and identity theft involving such agencies as ChoicePoint. The problem with Helland's notion of trust is that it deals with people who come into your systems to steal data, but doesn't deal with people who steal data elsewhere. So you have to start thinking about protecting data (e.g. by encryption) rather than protecting systems. (This is an aspect of what the Jericho Forum calls deperimeterization.) Even without traditional system integration, an SOA solution such as PSB will presumably still need complex trust relationships (to determine who gets the key to which data), but this won't look like the Helland picture.

A further difficulty comes with the semantics of the interactions. If we take away the assumption that everyone in the network uses the same reference model (universal ontology), then we have to allow for translation/conversion between local reference models. As Sean points out elsewhere, this is far from a trivial matter.

---

Technology Adoption

My expectation is that the deployment of technologies such as the Public Service Broker will experience organizational resistance to the extent that certain kinds of problem emerge out of the business requirements. In my role as a technology change consultant, I am particularly concerned with the question of technology adoption of SOA and related technologies, and how this is aligned with the business strategy of the target organization. I invite readers of this blog to tell me (in confidence) about the adoption of SOA in their organizations, or their customers' organizations, and the specific barriers to adoption it has encountered.

---

See also

Collaboration and Context (January 2006) Context and Purpose (February 2006)
Context and Presence (Category)