SOA is the new buzzword of the industry in the whole world. It promises much on the table by getting the integration of several application level entities. The age old problem of the legacy systems are eradicated by ensuring an ROI of the investment. My question is: Is the SOA industry mature enough to handle any of the pitfalls?
According to me there are many pitfalls of the SOA structure. The SOA Pitfall Matrix for an SOA failure in all the levels is given below:
Let us take a turn to introduce the pitfalls in the Matrix.
A pitfall may arise from three kinds of sources- namely business, technology and/or the people. In the business aspect, the management and the governance are the two issues, the difference between the two being management is concerned with the pre-implementation and transition, while governance is post implementation.
SOA is just a technology- SOA is not a technology that one can buy to produce an over night result. SOA is a set of principles that guide how organizations design their architectures, and how technology can facilitate reuse. Focusing on reuse gives integration.
SOA can replace other applications-Undervaluing the existing assets will prove detrimental to SOA. Most organizations might have the notion of replacing the old stack with this new “technology”, which is again negative to the wanted output.
Out of range- Not keeping in touch with the market place can prove detrimental to a customer using the SOA. The new SOA space is volatile, competitive and interesting. Alignment of the multi vendors along the lines of WS* specifications will be an added advantage for the customers to choose from various multi vendors.
Departments work in isolation- It is not a matter of sole discretion for the IT people to strategize the SOA framework. The analysis and planning has to be done in isolation or the results will have greater variation.
Overall Management- SOA governance will impose a major challenge which will effect the allocation of resources, the roles of the IT professionals, internal standards, ownership, processes, and project delivery lifecycle.
Vendors lock-in- Selecting a proprietary vendor even for the small projects may create a lock-in that is enormous and expensive mistake.
Non-Iterative governance- SOA embracing customers should empower a governance body to maintain the entire service life cycle. It should be one that evolves with time based on the decision patterns and iteration.
Lack of service versioning- SOA transition should be iterative in nature. A service life-cycle management should possess the capability to maintain the multiple versions of the service.
Building SOA as a traditional distributed architecture- SOA is neither CORBA & XML, nor ASP.NET & WSE. Service Orientation in not an object orientation. SOA is a distinct architecture.
Creation of other hub- Many SOA implementations requires centralized services. Instead of working on ROI of different application entities, if it requires space of implementation, then the thought of replacing a huge monolithic systems fall short.
Locking into a single messaging system- Different applications require different messaging schemes – maybe XML or binary. Locking into a single messaging scheme will limit growth to success.
Not standardizing SOA- SOA promotes a development environment that abstracts back-end processing so that it can execute and evolve with the other applications. However, standardization of services for interaction encapsulates this back-logic.
Creating tightly coupled services- Tightly coupled services are rarely used beyond the initial application level services that require a specific language, protocol, or platform. However, its creation during the design phase will allow the loss of efficiency.
Using a BIG BANG approach- For complex SOA solutions, a BIG BANG approach to the finish lines is detrimental to success.
Lack of scalability- At the end of the day, SOA adoption needs functionality, and they do not want to run their application at a slow speed. As a result, the deployed system will have to scale to meet the load required by the intended no of application users.
Not creating a transition plan- The chances of successful migration will be severely diminished without the use of the transition plan. Transition plan allows a coordinated control of phasing of service orientation, so that the migration can be planned on technical or organizational level.
Not starting with an XML foundation architecture- More attention is given to the data that needs to be transported between services. The manner in which the data is structured or serviced is often neglected. This will lead to an improper implementation of persistent data representation layer.
Forgetting security aspects- While scaling up, more services begin to take on a greater amount of processing, the need of the message level security measures is often needed. The WS-Security framework establishes an accepted security model supported by a family of specifications.
Lack of skilled labor- There is always a lack of skilled labor for the implementation and design level of the SOA.
CXO s and the people not on the same page- If not communicated properly, the people working under the CXO level will not understand the long term benefits of the SOA.
Not understanding the SOA performance requirements- When loose coupling is implemented within the web-services, SOA introduces layers of data processing as well as associated performance overhead imposed by the layers. As scope increases, the level of message based communications predictably grows, and there might be significant process latency.
Thus, we see that at all levels of the SOA implementation, there are pitfalls which the SOA clients need to manage at different levels. Given this flaws, I wonder if the industry is growing fast enough to embrace maturity in SOA.