« Alignment rap: Cats and Dogs, playing together, nicely | Main | Investing in Returns on Infrastructure »

May 11, 2005

The new architecture of Business alignment: Services

This discussion is one in a long series about how Business derives value from IT.

In this discussion, Business is wondering how IT can better support the functional capacity that Business needs in order to address its market requirements.

This functional capacity decomposes into qualities, economies and availabilities derived from the arrangement and interactivity of "components" of information technology.

But here is where the going gets gnarly. The notion of components is meaningless unless components are given roles that explain their reason for being involved and that effectively issue design requirements for the components. Examples of roles would be support functions that make up data communication, information management, or event synchronization.

Architecture manages the design of both the components and their relationships, according to their roles. Given that, the superceding business issue is to agree on what kind of effects the roles are supporting.

Establishing the value of roles

Rather than listing an undifferentiated universe of "important business effects", effects should be classified according to the way the business recognizes value being generated.

These classes of effects make sense when they logically discriminate the conditions in which a given effect has a certain type of value.

Generally, the business needs to run in certain conditions, and in those given conditions it needs to do certain things to a certain effect. This means we should take into consideration a difference between environmental values and operational values. They need to be respected separately because they can change independently of each other.

Despite that, IT implementations are often asked to solve both problems -- that is, to create the conditions and to prosecute functions in the conditions that they created.

After all, that is precisely the holy grail of "automation". Think of it this way: we ask a Hum-Vee to make inhibiting terrain navigable so that we can transport something through it in the Hum-Vee. Likewise, we ask radar to guide missiles. We ask spreadsheets to derive answers. We ask process modelers to write executable code. Or as the guys at Sun Microsystems used to like to say, we want the network to bethe computer...

Since we admit that we mainly like technology because we like automation, it's understandable that we might struggle with separating the environmental aspect and the operational aspect. We don't like the environment and the operation to be separate.

Engineering the effectiveness

Annoyingly, they don't readily cooperate with us unless we intervene in a big way.

The latest industry-level intervention -- the new zenith of automation -- is utility computing. Utility computing does things to the computing environment that makes the environment more worth doing things in.

As noted by Quocirca (and found via Silicon.com), "vendors such as IBM, Microsoft, Oracle and HP use terms as diverse as 'on demand', 'agile business', 'grid computing' and 'adaptive infrastructure' to describe their visions of utility computing, but the general push is similar, even if the rhetoric is different."

Despite the similarities, there are really two different pushes: one is about IT serving the business, and the other is about the business serving its market.

This starts to remind me of a typical "value chain" -- in which several different roles correspond to fulfill an order for a deliverable of known (or at least agreed-upon) effective value. We already know that value chains are actually complex and asynchronous, distributed over time and space. But then they are brought to the task of fulfillment specifically by agreements amongst them to also collaboratively operate a supply chain.

The value chain is how we can catalog the classes of effects. For example, printing a finished report at my desk, developed from live raw data stored in a computer in Switzerland, means invoking a value chain with links that can:
- understand and accept my request
- decompose it into subrequests
- farm out the subrequests to producers
- produce the components of the deliverable
- coordinate those production artifacts in the desired format
- route the resulting compound product to me.

In fact, each link in the value chain can represent a certain class of services, resulting from supplier and consumer agreements (about effects) typically made at each link.

But for the chain to finally deliver value, alignment of the services is needed, meaning that the success of the precedent service reliably promotes the success of the subsequent one. So it seems reasonable to ask more carefully what "success" means in both cases.

When it comes to services, the specific issue of "providing for" is crucially important to understand: a supplier may or may not be the creator of the product or operator of the production effort that we expect to be the "deliverable" gained by the consumer. But the supplier arranges for the deliverable to be received by the consumer, more or less on demand. The agreements that constitute the "service" also include definitions of when the demand will be respected by the supplier. That is, the demand itself must satisfy certain criteria, just as the deliverable must.

As consumers, though, one thing we always want is the maximum convenience in navigating the value chain to reach our fulfillment. I like exotically designed plastic pens, but I have no interest in being involved in the original oil-drilling that is making them available.

As suppliers, we want to maximize the economy of scope of our influence in the value chain. I don't want to be both a distributor and a manufacturer if I can get better "ROI" just being a distributor.

And the zinger is that at every link there is competition both for demand and for supply. I'm not the only one who wants to use the oil, and not everyone wants plastic pens.

Making it all workable

This is where an architecture of services kicks in.

The business purpose for architecture is to instantiate a value chain as an environment of several infrastructures -- that is, an environment that allows supply chains to be dynamically constructed from networks of value chains, for fulfilling demanded deliverables. By any name, this is basically what the Business wants the capability to do.

This is also where the difference emerges amongst the vendor spins on SOA. They differently prioritize the need for this environment.

For example, consider a business's current strategic priorities in its relations to its market. Does the business's current degree of automation allow the desired level of:
- Business capacity? (agile business)
- How about responsiveness? (on demand)
- How about risk? (grid)
- How about change? (adaptive infrastructure)

Now, for whichever of the above types, what is it that the Business thinks is suffering from an underlying undersupply of automation?
- Horsepower?
- Applications?
- Security?
- Continuity?
- other?

Role-based IT "components" will be conceived to support whatever issues the business has from combinations of concerns like the above. There are many many possible combinations... which tells us that there will be a wide array of value chains designed.

For now it seems that each link in each value chain might have its own optimal definition, which challenges the idea that a link can be shared by two chains (e.g like a node shared by two paths...) and threatens to dis-integrate infrastructures instead of integrating them. And should the infrastructure for a service link exploit a particular architecture to ensure its optimization?

Because we're already accustomed to having a network of networks (the internet), we can already abstractly imagine an architecture of architectures. But the complexity of that makes a unified environment seem quite far off into the future.

To make this struggle immediately less aggravating for the Business, we have the concept of services.

The practical usefulness of this concept is that it lets us represent a situation in which a "supplier" and a "consumer" agree on what are the salient characteristics of an "effect" -- and also agree on the terms of providing for that effect -- thus mapping the value chain. The question is, with more than one value chain at stake, how hard will it be to manage all the services desired?

The key to meeting this challenge would seem to be a broker that can discover, qualify and select advertised services. And this makes the service qualification process the heart of the new architecture.

Posted by Malcolm Ryder at May 11, 2005 10:56 AM

Trackback Pings

TrackBack URL for this entry:
http://www.malcolmryder.com/cgi-bin/mt-tb.cgi/40

Comments

Post a comment