After 5 years of designing and building award winning service oriented architectures, I thought I’d share my top 5 SOA gotcha’s and some general hints on how you can avoid them in your SOA programme.
1. Failure to recognise that Service-Orientation is about design (and not about technology).
Service-orientation is to web services what object orientation is to Java, C# and C++. Service-orientation is a design paradigm and not a specific technology.
Service-orientation is achieved by applying the principals of service-oriented design during the service design process. A Service-Oriented Architecture (aka SOA) is a suite of well designed and reusable services that follow these design principals. A service-oriented architecture cant be built by simply using the technologies associated with web services (such as SOAP or REST).
Still confused? Consider this real world example of design vs technology taken from the construction industry…
Even if Concrete (the technology) is used to construct a new office building, this doesn’t automatically mean that the building exhibits the design features of Modernist buildings (the architectural style). Concrete can be used equally well to realise any architectural style from Classical and Gothic to Modernist and International. Modernism is an architectural style whereas Concrete is simply one of a number of technologies that can be used to realise it.
So just because you have SOAP (or REST) web-services within your technical architecture, this doesn’t mean that your architecture is automatically service-oriented. It’s possible to create web services that are not service-oriented just like its possible to write Java or C# code that isn’t object oriented.
2. Failing to align SOA with the business.
SOA is much more powerful if the services that you deliver have recognisable business alignment and reuse potential. By delivering services that mirror business activities, it becomes easier to evolve and re-configure those activities when the business changes.
When talking to clients, I often describe SOA services as an ‘Organisation API’. Services should reflect the capabilities of the organisation, not the technologies within it.
The simplest way I know to enable business alignment is to bring architects and analysts together into one group with a shared vision and shared working practices (such as utilising BPMN for both business and service analysis).
3. Failure to share SOA ownership with the business.
There is little point creating flexible, malleable and evolve-able technical services if the business is not committed to leveraging this capability on an ongoing basis. Equally, services designed to be readily reusable are pointless if the business can’t discover, interpret and reuse this API to exploit new opportunities.
The business should therefore share the responsibility for designing and managing its technical services. In addition, the process of finding and reusing services should be straightforward and accessible, not shrouded in mystery and technical complexity.
Basic SOA Governance processes and simple service repositories can help to overcome these issues and can be as simple or as complex as required to fit your organisation’s culture.
4. Investing in the wrong tools and technologies.
There are a great many expensive tools and technologies available for SOA, so it’s easy to make big mistakes from a very early stage in most SOA programmes. To keep it simple here are my top 2 technologies to take extra care with…
Business Process Management (BPM).
BPM systems are often sold as a mechanism to enable service reuse via continuous business re-engineering but beware of getting sucked in by salesman waffle. BPM systems can be complex and are not always the answer. Chucking a BPM system into your shopping cart is unlikely to make a difference unless you have the required ‘culture of change’ within your organisation. I’ve seen people waste millions on BPM systems that only get used once because of poor cultural fit and ingrained application silos. When evaluating BPM, always ask yourself two simple questions; Do we need it? Will we use it? If the answer to both is a strong ‘yes’ then by all means go ahead.
Enterprise Service Bus (ESB).
ESB systems are often sold as ‘instant service enablers’ or ‘SOA out of the box’ but the smart IT manager should be asking “what kind of services would be exposed to service consumers if I did this?” Would these instant ESB services be well designed and business aligned or would they just expose existing legacy or proprietary application API’s using new protocols? Would these new ESB services be inherently interoperable and reusable or would I be exposing proprietary data models to service clients?
Take great care with technology selection and make sure you fully understand the pro’s and con’s before you sign on the dotted line.
5. Failing to create a cohesive architectural strategy.
Mixing and matching architectural strategies is rarely a winning formula. Different technical strategies have different technical outcomes and these outcomes will often conflict with each other. For example, stating that the corporate strategy is service-orientation whilst also stating that you’re standardising on one vendors integrated applications suite will certainly bring technical conflict. How can you create a vendor neutral SOA in a vendor mandated environment? Which takes precedent in terms of allocating budget? Which best reflects the way you do business? Which provides the best flexibility and best differentiates you from your competitors?
In my book it’s better to choose one strategy and one set of goals and benefits and then stick with them. Keep it simple and make it clear.
Avoiding SOA mistakes is easy: Use (or create) capable Service Technologists.
SOA is powerful stuff, but it’s a big and highly specialised topic. That’s not to say it can’t be simple, it’s just that there’s a lot of conflicting advice out there and it’s usually a mistake to think that you can simply move from EAI or OO straight into SOA in one step without having specialists who can help you to correctly design and build your SOA.
I always advise that IT managers seek the advice of an independent SOA consultant from a very early stage in any new SOA programme. Ideally someone accredited with relevant qualification from a professional body that delivers vendor-neutral SOA training and certification. Taking this kind of pro-active approach can save you millions in avoidable expenses and protect your whole change programme from many of the inherent pitfalls. Professional advice can help guarantee a decent return on the investment you’re making and will also help ensure that you deliver the strategic benefits that you’re after.
That’s my top 5, but what about yours?
Reference: Top 5: SOA gotcha’s and how to avoid them. from our JCG partner Ben Wilcock at the SOA, BPM, Agile & Java blog.
