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.
1 comment:
I received a comment thru private channel about this post. The commenter asked
For some time I am experimenting with the idea of how to build flexibility in IT systems. Traditional approach taken by ERP systems looks like understand variations and then build system with common core and multiple variations which can be switched on or off.
But have you considered model which Lego Blocks provide. For example Lego Bricks are standard set of bricks but practically infinite number of combinations can be made out of different combinations of bricks.
Is it possible to look at SOA as services (bricks) and service bus (Lego canvas) ? For example organization can have several bricks such as Payment Service, Authentication Service, Registration Service and one can make infinite combinations out of that.
What do you think?
I do think its possible to build such a composition of services.
That is indeed the promise of SOA.
My concern is the SOA artifacts such as WS-* standards, XML-RPC/SOAP are just enablers.
They will not gurantee composition. One has to design composible services in the context they are supposed to be used.
In your example, whether Payment services itself is a composible service or its constituent (Payment thru debit card, thru credit card, bank account, other payment services such as ECS/direct debit) form composible service is a question.
In my opinion this definition keeps changing based on requirements. Thats why I suggest use of MDA to define conceptual services to lowest possible granularity, but what you deploy may be a higher order composition (assembly) of these granular services. The deployed composition may keep changing over period of time.
Post a Comment