Service Orientated Architecture (SOA) Migration Case Studies and Lessons Learned – A Critical Review

Service Orientated Architecture (SOA) is a framework that allows business processes to be highlighted to deliver interoperability and rapid delivery of functionality. The benefits of SOA include reuse of generalized services, reduce costs and better business and IT alignment. If done correctly, it helps an organization respondent to ever-changing business needs efficiently. If done incorrectly, it can create bureaucracy and silos. This article evaluates the decisions, assumptions, and conclusions made by the research paper, SOA Migration Case Studies and Lessons Learned.

In the research paper, two research and evaluation methods are used to assess different cases for SOA. The first method is the Case Study Method where the researchers develop a theory and based on that theory they develop criterions to select the case studies that will be assessed. This Case Study Method is shown below:

The second method uses a customized version of the Evolution Process Framework (EPF) to evaluate SOA. This customized version is called EPF4SOA and the phases involved in the evaluation are shown below:

With the research and evaluation methods in place, the research paper goes on to assess three multibillion-dollar organizations that have been around for at least 50 years. These organizations have legacy systems that have become archaic and thus they are unable to respond to rapidly changing business needs. Keeping these limitations in mind, these organizations go on the path to extract as much functionality from these legacy systems as possible by creating SOA services that could be used in the organization. Based on the EPF4SOA, the research paper goes on to claim that for effective SOA migration, organizations need to have a strong business case, services design, technology selection, SOA governance, and education and training.

As we read this report, it seems obvious that the researchers have done a good job of evaluating these large organizations from the finance and telecommunications sectors and in highlighting the lessons learned on SOA migrations. However, this research has made some decisions and assumptions that need to be understood. Firstly, in the Case Study Method, there seems to be an element of confirmation bias when the cases being selected are based on an initial theory. This confirmation bias can lead to selecting cases that fit what the researchers are looking for rather than selecting cases and then determining what theories can be derived from those cases. Secondly, the research looks at organizations that have been around for a long time and by their very nature are most likely to have legacy system issues and make the assumption that other organizations would have the same issues. Lastly, the research report alludes to that SOA can help in business and technology alignment but does not take into account strong leadership and organizational change management capabilities that are needed for SOA migrations.

Keeping the above in mind and carefully reading the case descriptions, we can extrapolate that there might be some potential challenges in the cases being presented in this report. These potential challenges are explained below:

1. SOA is not only an IT concern: One of the lessons learned in this report indicates the need for a strong business case for SOA developed by IT in order to get management support. The fundamental problem with these lessons learned is that it automatically puts the burden of implementing SOA across the entire organization on IT and takes it away from the business side’s responsibility and involvement with SOA. While IT is responsible for creating SOA services but the business has to work collaboratively with IT. Business has to understand how the organization came to a point where it became difficult for quick system changes and how to avoid situations like this in the future. Thus, SOA is not only an IT issue but an organizational endeavor that involves all parts of the organization as well.
2. Organizational processes need to be reevaluated: One of the cases mentions the presence of too many point-to-point integrations that are reducing the ability of the organization to be more agile. While this might be the case but there is a bigger perspective here that is missing. This perspective revolves around organizational processes in place that led to this in the first place. These organizational processes not only entail IT but also the business side. It seems like in this case IT would do what businesses ask them to but there has to be some mutual understanding that the requests have to be understood holistically. Even after a SOA migration, if these organizational processes are not optimized they might still result in ad-hoc requests from the business leading back to point-to-point integrations.
3. A long-term view on legacy systems is needed: The cases in the report indicate that replacing the legacy systems was not an option since it would be costly to do this. While in the short-term this seems like a good idea but in the long-term, there are issues with this approach. These issues entail the constant “patching” to upgrade underlying hardware and software in addition to overburdening legacy systems where new services are being added on top of systems that should be replaced rather than being continued to extend their end of life. While for some organizations it might not be possible to replace legacy systems altogether but there should be a plan to retire these systems with new systems eventually.
4. No measurements mean no ROI exists: While some organizations in the research report did measure SOA migration ROI but that was done after the fact. So, if the organizations were not measuring pre-SOA how would they know if what SOA migrations promised is what the organization was able to achieve. Herein lies the problem where quantification and justification are made to show SOA being a success without doing the due diligence before embarking on the SOA journey.

In addition to the above-identified problems, the research report does not put enough emphasis on the importance of governance that is needed for SOA. Let’s explore what is governance and why it could be one of the differentiating factors in SOA migrations.

Governance: Governance is the policy of how things should be done and provides a framework in which business processes can operate under regulatory, time and other constraints. Thus, governance is an organizational responsibility even for SOA and not only an IT one. In order to accomplish this, a governance board should be set up that consists of a cross-functional team from both IT and business. Additionally, governance should not only include the overall organization and management of SOA activities but also the creation of success and failure measurements. These measurements should be used to actually determine the state of SOA within the organization instead of people doing vaporware measurements that have no grounds in reality.

In conclusion, while the research report is interesting in its own right but it should not be taken as the only lessons learned for successful SOA migrations. Based on a few cases these lessons learned cannot be applied across various organizations such as smaller organizations, governments, and nonprofits but should be taken with a grain of salt. The lessons learned should be a start but not the bible for successful SOA implementations. A successful SOA implementation will depend upon context, processes, technologies, and people since broadly speaking SOA is an organizational change management journey.

References:

1. SOA migration case studies and lessons learned