Planning_and_Impleme.. - didier beck weblog

www.butlergroup.com
Planning and Implementing SOA
By the SOA maturity phase, the real dynamism that SOA can offer should start to become feasible, with an
autonomic service infrastructure allowing services to be identified and accessed on-the-fly. Forecasting how
infrastructure is likely to change so far into the future is like gazing into a crystal ball, but a policy-based
solution is likely to support this model the best.
Development Methods
One of the key needs of the investigation and discovery phase will be to acquire service-oriented expertise. This
may be easier said than done, since it requires a move from functionality and application-oriented thought and
design processes to a service-oriented one. It will also be vital to have a broad understanding of current systems
and technologies; it is unlikely to be wise to buy external SOA skills at the expense of upgrading internal skillsets.
This change of emphasis will need a significant human change management effort.
During the development and deployment phase, we would expect organisations to be moving on from pilot
projects towards a reasonable degree of service development and reuse; this is where it will be apparent
that the different domains are inter-related, since without the other horizontal areas keeping up, it would
be all too easy to develop runaway services that do not suit business needs. Essentially, a service serves;
the questions to be resolved at this phase are how, where, why, when, to whom, and if it is needed at all?
Although a few composite applications exist today (for example SAP, together with some of its partners, have
created what they refer to as X-APPS, which link together several services both from within SAP’s
application and external to it), Butler Group does not see a significant move to this paradigm until
organisations are ready to move to the SOA transformation phase. Here, it is anticipated that composite
application development will become much more commonplace, and large, single-purpose applications will
gradually reduce.
In the SOA maturity phase we will start to see rapid application assembly, where composite applications
are the norm – in fact they are created and then overtaken by new ones from the underlying services which
become available. This will need service creation to be fully understood throughout the organisation. The
IT function will need to support the composition paradigm fully, with graphical composition tools in the
hands of business-facing experts.
SOA may not be the appropriate architectural model for all systems.
Whilst SOA holds the promise of flexibility, agility, and potential for future cost savings, it may not be the
most appropriate architectural model for all systems. Where complex transactions are involved that need
tightly coupled links between the various phases of the transactions, a SOA is unlikely to be a suitable
model, particularly if very high volumes of transactions are involved with high performance requirements.
Stateful, long-running, orchestrated business conversations are not well-suited to a SOA approach, as the
management of such complexity is beyond SOA, certainly at the moment.
Where an application is very self-contained and structured, and components have been designed to be
tightly coupled, there is little advantage in breaking it down into services that are insulated from each other.
Additionally, where an organisation has recently implemented a new enterprise application, such as an ERP
system, which is in widespread use throughout the organisation and is starting to meet its transactional and
informational needs, there is little relevance in even considering SOA. However, the vendors of most of the
major enterprise applications are certainly paying serious attention to SOA – they are facing many of the
problems, such as rigid processes, that SOA can address. It is therefore likely that future versions of such
applications will be service-enabled, and permit choice in how the individual services are assembled in the
future.
Where only one or two applications are in use in a homogeneous IT environment, and they are not likely to
change, imposing a SOA would add unnecessary overhead at this stage. Organisations may want to start
investigating SOA within the next year or two, to establish if it is likely to have any benefits for them – and
even so, there may be no apparent need to change for the foreseeable future. In cases such as this, service
orientation might be an appropriate model for new functionality, particularly when external partners and
collaborations may be relevant. The book ‘Mashup Corporations’ has some examples illustrating this usage
of SOA for new projects.
December 2006 Section 1: SOA Deployment 11