SOA is heralded as the 'must have' for business agility. I agree to a point. SOA is necessary but not sufficient to achieve the highest degree of business agility. Let me explain, why I think so.
In service oriented world, information systems try to be congruent with business world, providing information services in support of business services. The business organisations provide business services in order to carry out the business activities. These business services are steps within business activities and they use information services provided by underlying IT infrastructure.
However underlying IT infrastructure is not amenable to this business service oriented paradigm, fully. At implementation level, IT infrastructure has to deal with non-functional properties, such as responsiveness, scale, availability, latency, cost, skills availability etc. That imposes certain restrictions on implementations.
E.g. For scale reason we normally separate behaviour and data. Behaviour (as represented in business logic and business rules) scales differently than data (and data stores - databases, file systems). That’s why in a typical distributed information system, there are more database servers than servers dedicated for executing business logic. In service oriented world, information service provided by information systems need to mask such implementation issues. The idea that SOA will provide business agility will hold true, iff information services enable business services, use disparate information systems seamlessly. In SOA world, business services should lend themselves to rapid re-organisation and redeployment, in terms of business activity volumes, business responsiveness, speed of new product/service introduction etc.
The current thinking seems to be that a set of open standards, enabling integration between disparate information systems is all that is needed. With such integration mechanism, one can create a facade of a business service, using underlying disparate information systems. Hence the emphasis is on XML schemas, in-situ transformations, service choreography and to extent mediation [between required business service and provided information service(s)].
To me this is part of solution. It is the necessary condition but not sufficient.
As I had posted in
past, one really does not know what should be granularity of information services. If you provide too granular information services, you would be better at reorganising but will be hard pressed to meet non-functional parameters. If you provide good enough services for current usage, satisfying non-functional parameters, you will have tough time reorganising. So for all practical purposes, for any business service change, there are possible information service related changes, rather than just reorganisation of information services.
That would mean, the agility of business service reorgnisation comes down to the change management in information systems. If you make pragmatic decisions in favour of speed of change, it leads to duplication and redundancy. If you try to keep your information systems pure and without redundancy, you sacrifice the speed of change.
So the key appears to be
getting your information services granularity just right for all possible reorganisation that would be needed by business. You cannot really know all possible business changes, but you can know up to a certain time horizon. So that you are just re-organising your information services rather than redeveloping.
if this is not possible or considered risky, you can take a re-factoring oriented approach. And incrementally build the service definitions.
and whenever you change information systems (because despite your best efforts business came up with a change that is not possible with current information service definition), use MDA or Software factories (or any other conceptual to implementation mapping technology) to effect the change from conceptual business services onto its IT implementation. This would bring down the time to make changes. And also would enable you to make pragmatic decisions, because even if there are duplications and redundancies at implementation level, the conceptual field is clean and pure.
That would be complete SOA for me.
