While talking about the SAP Netweaver - BPM & SOA Enabler in my previous blog, as everyone expected, the much talked about CE 7.1 and PI 7.1 usage and implementation scenarios were discussed. The question that suddenly cropped up was - Do CE 7.1 and PI 7.1 actually cover all the objectives of SOA? Or Are the functionalities available with these NetWeaver tools the only ambition of bringing SOA to organization? In my opinion, the answer was "Not exactly"!!
The intention of SOA was to bridge the gap between the Business and IT providing a layer of technology where both of these groups could cooperate in sync. However, are they really happy with all which is provided to them? At many places, the advantages of SOA could turn out to be a drawback. Therefore there is a need to evaluate each option before actually implementing the SOA rules. I have discussed a few situations here:
Note: Services here refers to the Services developed based on SOA architecture.
While SOA talk about the enterprise service and business process, there was some ingredient something missing which Business users always want to shield and IT group always afraid of handling and yet it could drive an organizational behavior. This entity is well-known as the Unstructured Data. According to an estimate by Merrill Lynch, about 85% percent of all business information exists as unstructured data. SAP CE 7.1 or SAP PI 7.1 nowhere dedicatedly deals with maintenance of this unstructured data. This is a major pain area wherein the improper handling of data could hurdle the Business Information agility. Not only an information warehouse is required but an intelligent repository would be the need of the day. So now, are we stuck at something which we haven't thought about? Fortunately, SAP has thought about it and incorporated in the NetWeaver stack. Data management capabilities are well accumulated in SAP Master Data Management (MDM) and SAP BI (Business Intelligence). Thus while focusing on SOA, we couldn't actually leave alone other aspects of NetWeaver.
The basic architecture of SOA concentrates on service based design enabling loose coupling of the systems involved. For an organization with huge number of communicating systems and applications, this very loose coupling could complicate the Business Process further. (Making life of a Business Process Expert difficult :))
If in case, the system or application used by an organization are not much reused or modified, then its corresponding service when used as a part of entire Business Process would definitely deliver performance overhead as compared to the traditional but faster Object Request Broker (ORB) models. Therefore a Business Process Expert shouldn't always be stubborn about implementing services to the deepest core of an organization. There ought to be some place for relaxations on the SOA rules.
Technically, the Business Process could transmit the data on real-time basis, posting a request and expecting a response from the services (Synchronous). Or it could be a fire-and-forget behavior (Asynchronous). For a Synchronous design, the services would be the best choice to be exploited. The requesting service always knows which service should be sending the response. But what about the Asynchronous scenarios? There could be lot of Business cases where a response is not expected back. In that case, do we really find the SOA architecture the best choice? How about an Event Driven Architecture (EDA) which could make the sender loosely coupled from the receivers? EDA is not about replacing SOA, its about keeping in mind the capabilities of other Architectures while presenting an optimal solution to clients.
I have seen some people writing about SOA mentioning Platform independence as one of the key benefits. Do SOA really provide Platform independence? SOA helps to create a service based organizational structure. But actually it doesn't really make it independent of technologies. The legacy underlying technologies are not completely washed away; rather a way to leverage their capabilities has been evolved.
I wouldn't really like to term these points as limitations of SOA. However, these points could be helpful in a BPX's perspective while designing SOA based organizational architecture.
