Planning_and_Impleme.. - didier beck weblog

Planning and Implementing SOA
www.butlergroup.com
The move to SOA will take many years for the majority of
organisations.
It is all very well establishing a roadmap, but a question that is often asked is how long will SOA take to
be a normal business/IT paradigm? As with any other forecast of the future, this is a challenging question.
Certainly, some large organisations are starting to understand that things are unlikely to stay as they are,
and the benefits of service orientation imply that it will be a good model to follow.
The four phases that we discussed are likely to take a number of years for any organisation, even the most
flexible and agile out there. Some organisations are already starting to work on phase one – educating
themselves about SOA; in fact this has already been underway for two or three years now in early adopters.
Where SOA is likely to gain limited uptake for a number of years to come is in the mid-market – here, we
are still seeing a continual shift away from standalone applications that only cover a small part of the
business, enhanced by a ‘sticky tape and string’ collection of applications, spreadsheets, and e-mail,
towards more integrated ERP systems. For these organisations to then be told they need to break up these
applications into services seems like a backward step. Mid-market companies and other medium-sized
organisations (for example, in the Public Sector) are far less likely to be even thinking about what SOA might
mean for some time yet – and when they do they will not appreciate being pushed into making decisions
by the vendors. Not all organisations will either want or be ready for SOA.
Careful strategy can help to future-proof SOA developments.
As with any new technology idea, the suspicion is that hype is rather more than the content, and it will
soon be replaced by ‘the next big idea’. Butler Group believes that the terminology, SOA, might be
superseded, but that the concept of a service-oriented organisation is very much the model of the future.
Having said that, there are steps that organisations can take to ensure that any work they do on SOA
projects will still be relevant as technologies and business challenges change in the future.
Process Discovery and Modelling
The way that organisations have evolved has frequently been very hit-and-miss, as management structures
grew to cope with the changing business environment. Developing a thorough understanding of what the
business processes are within an organisation will be valuable, whatever happens in the future.
Adoption of Technical Standards
Standards are often seen as an invention by vendors that can lag a number of years behind what the vendors
themselves are offering – witness the number of vendors that add ‘extensions’ to standards in order to
provide specific capabilities. What is probably as important as understanding the wider technical standards
is at least picking what works for the organisation, and promoting the use of those within the organisation.
De facto standards can be as relevant in the real world as those that are formally ratified by the various
standards bodies, as this indicates widespread adoption. Participation on standards bodies may be a major
commitment but will at least provide end-user perspectives directly to the standards process, and should
be considered by organisations that can afford such commitment.
Maximising the Level of Abstraction
Whenever business-relevant information is buried within technology and tools, it becomes harder to change,
requiring the relevant skills and knowledge to do so. Wherever possible, this needs to be abstracted to the
highest level possible to make it much easier to change, and reduce the skills required to make that change.
This approach is highly consistent with SOA.
A Solid Architectural Framework
There is a myriad of tools and technologies on the market for SOA-enablement, and organisations need to
take care to understand the underlying architectures within them to avoid lock-in wherever possible.
Creating a solid architectural framework for the organisation, based on its own needs, skills, and future
plans, will help to ensure that work done for SOA projects is relevant to these internal requirements.
12 Section 1: SOA Deployment
December 2006