SOA Fable: Do you know the intent?

Before advent of SOA, enterprises opened up their central systems to a limited set of users, thru initiatives called 'Extranets'. The idea being stakeholders can have a limited visibility into workings of enterprises which would help them in their businesses, which in turn help the enterprise.

So this giant automobile company opened up its inventory to its distributors, and distributors could place orders for spare part based on inventory they saw. Soon the company realised that some distributors were misusing the facility to hoard critical spare parts when inventory was going low, and making extra buck by selling those parts to other distributors for a premium.

Company stopped this facility. To company's dismay some clever distributor found another way around. He started placing orders for ridiculously large number of parts, system started returning error response with a suggestion for maximum number he could order. The maximum number being level in inventory. This was worse than earlier situation. Not only distributor was getting the information he wanted, he was loading the central system unnecessarily - by continuously running this service for different parts and forcing error response.
Then because of some unrelated change, company stopped giving correct level of inventory in error response. So this distributor started making a lot of orders starting with a high number and gradually coming down to correct level, while doing a binary search. This was worse than earlier situation. It has started creating a lot of orders into system, which launched associated work-flows and then cancelling them - which launched even more work flows.

Till the last situation arose, the problem was handled as IT capacity problem and mis-deeds of distributors were not caught. The last hack tried by distributor nearly broke the back of central systems. Which launched massive investigation to uncover these mal-practices.

What has this got to do with SOA?
Well, one vision for SOA is that SOA can make enabling services available to consumers. Once consumers have enabling services available, consumers can compose the applications they need. Even if we keep aside the doubts about how does one define these enabling services, the issue of consumer intent is a big issue. It need not be always a malafide intent. Some consumer running an innocuous service, multiple time to get the data set he wants in order to do analysis he wants, can break the back of transactional systems. This has nothing to do with services policy. The consumer is willing to abide by policies set for the service, but his intent is not the one envisaged by service provider. And in this era of 2.0 this is bound to happen. SOA needs to take cognizance of this issue and handle it. No, CAPTCHAs are not a solution when services are meant for consumption by machines rather than humans.

Moral of this story is, in a true SOA, the architecture must

1. have a mechanism to diagnose violation of normal intent by consumers
2. provide alternate service implementations for genuine exceptional intent
3. provide a seamless switchover from normal intent to exceptional intent
4. provide incentives to promote normal intent and disincentives to reduce exceptional intent - when it makes sense to do so.

People or process?

This is an interesting debate going on, that of people versus process in enterprise architecture function. Now that we are on subject let me bring in my perspective.

Legend has it that there were weavers in Dhaka region of Bangladesh, who could weave cotton cloth so fine that a nine yard piece would weigh less than 50 grams. Well that art is lost, because those weavers would never codify that process of weaving. So that knowledge passed only between generations thru word of mouth. When pitted against cheap cloth from Manchester, their better quality cloth lost market share to cheaper but not so great cloth. Eventually the whole craft died. It need not have been so, have they codified the process. At least craft would have survived and could have been revived in these days of green trade/fair trade.

Moral of the story,
1. Not codifying process is no guarantee against obsolescence.
2. Someone who can employ a repeatable process wins in a mass market over someone without process. (And enterprise IT is by no means a niche market).

Having said that I do believe there are job functions which cannot be fully codified by processes. I believe enterprise architect’s is one such job function. But this job can still be divided into pieces that are more defined and pieces which need bit of experience and expertise. The defined parts can then be codified and handled with slightly lesser skill levels. With this approach a full fledged enterprise architect, with some help can do job of many enterprise architects.

Nobody would have been interested in this model, if there was supply of good enterprise architects. Problem is there are not enough good people going around. This is a way to make do with what you have got. And yes it does work in enterprise architecture function too.

EA and structuring IT change portfolio

There is no steady state for EA function, as EA has unenviable job akin to converting a propellar driven aircraft into a jet aircraft, while flying. And it does not stop there, by the time EA managed to turn into a jet aircraft, new scramjet is already available and waiting for being adopted.

To cope with this constant churn, the usage of EA frameworks is widespread. But, as I had pointed in my earlier post that results on ground are only thing appreciated by end-users. This post by Tom re-emphasised the point about operationalising the Enterprise Architecture as had this post by Sam. Operationalisation of EA is what is capable of producing the results, no matter what framework was used to structure thinking and what artefacts were built. Unfortunately after spending lot of bandwidth in think and build activities, there is little spare bandwidth available for operationlising the EA.

In a large enterprise, structuring the business IT change portfolio is a great opportunity for EA function to make sure EA is operationalised. Its where the lack of bandwidth affects the EA function. Somehow this important activity uses arkane practices similar to waterfall model followed in SDLC. It is no better than business folks placing their bets on initiatives, based on gut feel of a few individuals.

It need not be so. If you look at large scale picture of enterprise IT, it is a fractal. So what works for structuring changes for a single application can work for enterprise IT too. For an application change, one carries out impact analysis, based on functional and non-functional requirements to figure out the changes required. Similar approach can work for enetrprise IT too. The functional requirements coming from business and non-funcitonal requirements coming from EA group. There are two critical differences though. Firstly requirements for an application are far more crystalised than business requirements meant for enterprise IT. Secondly the understanding of single application is much more rigorous than entire landscape of enterprise IT. Any approach used to structure the IT change portfolio must bear these facts and evolve a strategy to handle it. Any investment made in this area will go long way in establishing EA credibility within organisation.