Develop Agile Enterprise leveraging sustainable IT architecture using micro service, integration, SOA, business rules engine and artificial intelligence services. Jerome Boyer - Cloud integration and AI architect.
Disclaimer: All views expressed on this blog are mine only, and do not represent the views of my current and past employers and customers.

Friday, November 21, 2008

53% of person contacted are using SOA in some part of their organizations

25 % were not using it but had plans to do so in the next 12 months

16 % no plan to use it

20 % are building Event Driven Architecture

20 % are planning to do EDA in the next 12 months

Since the beginning of 2008, there has been a dramatic fall in the number of organizations that are planning to adopt SOA for the first time. down to 25 percent from 53 percent in 2007

Many organizations have evaluated SOA and have chosen not to spend time and effort on it

The highest concentrations of organizations not pursuing SOA and having no plans to do so are in process manufacturing and agriculture and mining

SOA adoption in Europe is nearly universal, moderate in North America and lagging in Asia

Main reasons listed are:

No clear business case – but there is a great deal of confusion about how to construct a business case for SOA

Lack of skill and no plan to acquire necessary skill

Use of modern programming environments is closely associated with SOA

Legacy skill + SOA are scared

In my recent work on the book "Resilient Information System" as co-author, I have to study what are the pains and use cases our BRMS customers have in term of SOA. I'm still doing interviews on that matter but basically there are four main subjects to address when migrating to SOA :

Data: work on the definition of domain data model, or put in place some transformation layer to present the different view of the data to the applications

Business rule: be able to understand, to externalize and to easily change the business rule outside of the applications.

Expose functions as business services: once reusable points have be identified, the services can be designed and documented (WSDL) for reuse.

Re-engineer the business processes to support automation using reusable services.

The successful deployments among our customers are done in that order. If CIO buys upfront the full SOA suite, he will most likely not get the bang for the money, as the migration to an Extended SOA is long. So the business case has to be built by increment with the first goal of deploying tools that empower the business user to change his business policies. When you are successful on this matter, the other business cases are easier to articulate, because business users are seeing the value. As explained in the Agility Chain Management System the core technologies to support the implementation are MDM, BRMS and BPM. Deploying SOA without BRMS and MDM does bring to the red path of the SOA maturity matrix. BPM, as BPEL orchestration engine, is not the solution to buy upfront, it will arrive later in the SOA maturity when we have reusable services that we can orchestrate.

SOA is a viable architecture design and approach as was OOD in programming, so please do not kill it. Now it has to be decided as a corporate initiative and implemented by increment, project after project.

About Me

I'm Technical Director working in the business rule management system market and I currently working on Complex Event Processing offering. During my consulting career I had deployed a lot of business applications using Rule Engine, and I'm very interested by BPM, SOA, and BRMS. I created a methodology based on Agile Manifesto to develop business application using BRMS technology. For the ones I know from the past who googled my name, yes it also the same jerome who was sailing for the French national team in my younger age.