Lack of available expertise is now being highlighted as a major blocker to SOA adoption in 2007. What organisations need is expertise around how they can plan, create and deploy SOA successfully. This requires individuals such as architects and programme managers with the ability to develop and deliver a programme as potentially complex and all encompassing as SOA can be. However, it also requires expertise in the organization specific processes and data models – many of which are in fact not so much organization specific as specific to the industry segment it operates in. Therefore it is perhaps surprising that we haven’t heard more about industry specific frameworks for SOA: templates or “Solution Maps” as SAP calls them which provide a fast track by providing the industry expertise pre-canned.

In the past (pre-SOA), I have been sceptical about industry specific frameworks and in particular wondered whether they were actually clever ways of packaging up consultants with expensive industry specific knowledge. A scepticism I brought up with a senior manager in a European retail bank who is an early adopter of SOA of about 4 years standing. His view was that leveraging the industry based patterns that he is now using (provided by IBM in his case) earlier on would have been a significant benefit in reducing the effort and risk associated with his programme. As such a framework was not available when he started, he had to create his own framework: Using somebody else’s even if it had to be adapted would have been a major benefit in terms of time, cost and risk.

Of course whether it will work for you will depend very much on the industry you operate in, whether its processes are sufficiently standardised and whether it has attracted the attention of one of the firms creating the frameworks. However for industries where it does suit the benefit for users will be significant and the opportunity for vendors will also be big. In fact, I believe that for these “framework-friendly” segments the competitive landscape may be considerably different: The vendors with the greatest knowledge of providing industry specific solutions will be in a very strong position. In particular IBM and SAP should dominate as they have the customer base and expertise and are already investing heavily on creating the frameworks.

As such it may well provide SAP will an excellent opportunity to break out of its ERP-centric SOA niche (selling to customers who see SOA as an ERP extension) and get some return on the investment in their Cinderella-like SOA strategy: just like Cinderella, it does all the right things but still gets ignored by all the Prince Charmings!

Ronan

Posted by rbradley in Market trends • SOA Predictions | Permalink | Comments (0) | TrackBacks (0)

Reading Joe McKendriks’s blog piece on “Is EDA the ‘new’ SOA” got me thinking again about how EDA and SOA fit together. Event Driven Architectures (EDA) is sometimes held up as an alternative to SOA. While this may be theoretically the case, I think EDA-style capabilities are most likely to build on top of SOA to take advantage of the higher degree of integration provided by a SOA deployment.

Rather than going into detail on what EDA is, I will quote some definitions from Jason Bloomberg of ZapThink back in 2004 and suggest that anybody who wants to know more goes to Brenda Michelson’s excellent primer on the world of events and EDA in her elemental links blog.

Jason’s definitions are:

EDA is an approach where events trigger asynchronous messages that are then sent between independent software components that are completely unaware of each other.

While

SOA, on the other hand, is an architectural approach where software functionality is exposed as loosely coupled, location independent services on the network.

Therefore the primary difference between SOA and EDA is the level of decoupling between the software components. The total decoupling of source of the event and the eventual destinations in EDA means that the message fully defines the interaction between components – a very different situation from SOA where the server and client interaction is ruled by the service definition. In fact, EDA is not a new pattern – it is a form of “publish and subscribe” which has been around for a long while and effectively used to solve certain classes of problems.

The question from Joe was “Is EDA the new SOA?” – I would say no for two reasons:
• The level of enforced decoupling in EDA can make it awkward to shoehorn the range of problems that an enterprise architecture has to solve into a pure EDA form.
• For those problem types that EDA is well-suited for, SOA can be extended with a bit of EDA and therefore do the job.

Rather, I see EDA being used ‘on top’ of SOA – to allow identification and processing of unusual events or combinations of events that should generate alerts or recovery processes. SAP for one is already providing some of this type of capability within its NetWeaver product set where BPEL-defined processes can be fired off in response to specified events. This type of functionality will be crucial in terms of delivering control across the SOA-based network of integrated components exchanging more information and information of greater business value.

Ronan

Posted by rbradley in SOA Predictions • SOA concepts | Permalink | Comments (0) | TrackBacks (0)

I struggle to keep up with the number of industry organizations that claim association with SOA these days. Unfortunately, they seem to be either focused on generating yet more technical standards (just what we need!) or to be vendor-dominated organizations interested primarily in business development for their backers.

Therefore, I noticed with some initial dismay the appearance of the SOA consortium . However after finding out a little more about it, I believe that the SOA consortium has the potential to be a useful addition to the world of industry groups for a number of reasons:

- It is focused on advocacy and not becoming yet another standards body: SOA needs effective supporters, not more technical complexity right now!

- It recognises not only the importance of engaging with the business but also the need for both business and IT management to change in order to benefit from SOA.

- Its founders include not only major vendors (IBM, HP, BEA, Cisco and SAP) but also major end-users (Bank of America and Avis). This balance between vendor and buyer is essential if it is to become credible as an advocacy group.

- Finally, it also has the involvement of two industry organizations who know how to engage both end-users and vendors in a constructive way. In particular, the OMG has a long track record in doing this successfully. (The Integration Consortium is a mere baby in comparison, but set-up with the same concept of end-user engagement).

My only caveat is that the claim to target the Global 1000 seems undermined by the consortium’s decision to hold only three meetings to formulate its charter – in the obvious locations of New York, Dallas and San Francisco. While there must be limits to consultation, this choice does seem a little short-sighted if the consortium intends to be truly global.

Ronan

Posted by rbradley in Market trends | Permalink | Comments (1) | TrackBacks (0)