In a recent Peter Woodhull - Information Management article, I was happy to see "Despite any declarations made to the contrary, SOA isn’t dead." In this article, Peter notes and I completely agree that SOA is not a technology but an architectural paradigm and it is on the move again.

Speaking with friends in the industry, since the economic downturn, there was a drop in development of these types of solutions – but they are back and will be here to stay.

The reason that they are returning is that business can only forego re-investing in technology for so long before they become stagnant and fall behind the curve relative to their competitors. SOA is the way the industry have chosen to move for its business agility, scalability and return on investment. Once a corporation makes the choice to invest in SOA, they are making a short-term investment that pays off in the long term – and keeps paying and paying due to its very high reuse. Corporations may not be trying to boil the ocean, but no-one is. SOA projects are best accomplished as an iterative development towards a long term goal (that I have mentioned previously should be implemented using a blueprint or roadmap that captures the current state, determines future state and develops a plan to get there).

The reason that SOA and similar architectural paradigms are here to stay (like Event Driven Architectures (EDA), Complex Event Processing Architectures (CEP) and even Web Services Architectures (WSA or WS x depending upon who you listen to)), is that they offer the business something that they cannot purchase – a technology foundation to build their business upon. In order to build an SOA or any other of these high-tech architectural paradigms, one must consider many different areas (for some of you, you can consider this a SOA implementation planning step or roadmap phase of SOA):

Vision or strategy for the implementation (Business need)

  • Collect corporate artifacts
  • Interview key stakeholders

Determine key projects requiring SOA, EDA, …

Business Architecture Evaluation

  • Business Process/Function/Data Modeling (Who, what, where, …)
  • Business Objectives Correlation
  • Current Skills Assessment
  • Future State Definition

Technology Architecture Evaluation

  • Frameworks, Packages & Tools in use today
  • Legacy/Application Code
  • Enterprise Integration Components (MOM, ESB, …)
  • Data & Infrastructure Architecture
  • Skills Requirements Analysis

Implementation Planning

  • Business Strategy Alignment
  • Gap Analysis (current state to future state)
  • Definition of the Critical Success Factors
  • Key Skills Identification and Organizational Alignment
  • Implementation Planning (initial project planning/budget)

Impact Analysis & Risk Mitigation

  • Impact Analysis (IT and Business)
  • Organization Impact Analysis
  • Operational Impact Analysis
  • COE/Reuse Planning

Transition Planning

  • Pilot Project Identification(s)/Plan For Iterative Implementation
  • Organization Transition Plan & Division of Labor
  • Governance Model Development
  • Quality/Testing Plan
  • Technology Plan
  • High-Level Work Plans (project plans for implementation & cost model)

In order to implement this from scratch, I would suggest a Business Architecture phase followed by an Information Architecture phase, then an Application Architecture phase. These can start staggered and the next can begin before the previous one ends. If you have an existing enterprise, consider wrapping of legacy systems – allowing them to support services interfaces.

An SOA pilot project should be able to be implemented in no more than six (6) months. If it takes much longer, you are not planning nor implementing according to industry best-practices (small, iterative projects that build upon each other).

Some would note that Point-to-Point integration should occur before loosely-coupled services and then reliable, discoverable service ending with composable, re-useable services – I am not against this but think that you have to plan for re-usability in advance and reliability should be part of your prototype or pilot.

In my next blog, I will discuss the need for identification of patterns in the development of one of these types of solutions.