Skip to Content

SOA Limitations? Points to Ponder

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.

  1. 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.
  2. 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 :))
  3. 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.
  4. 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.
  5. 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.

You must be Logged on to comment or reply to a post.
  • Hello There,

    SOA is a strategy and often times customers thing SOA can be achieved by buying a product. This also sounds like the message I get reading your blog.

    SOA is a reality and for customers we have to first understand how it relates to our business and what are our short term and long term goals.

    Using the many tools in the arsenal of SAP there are many customers in North America and Europe that I personally know about from pier groups and various partner councils are very successful in translating SOA into various business enabling initiatives. 

    if you are more interested I would encourage you to look into the ASUG EA chapter that includes eSOA.

    Best Regards,

    Best Regards,

    • Hello Naveen,

      Thanks for your comments.
      I completely agree with you about SOA turned up into a reality these days. However, in my opinion, SOA methodology, at many places, is still viewed by top management of an organization as a series of Products which when
      implemented will provide them their most important objective - ROI. In such cases BPX plays an important role to enlighten SOA's longterm benefites and this blog could provide some points for BPX to keep in mind while modelling the landscape.
      I am not very much aware about the ASUG EA chapter. It would be really helpful if you could guide me with your inputs.

      Thanks and Regards,

      • There was a similiar question posed regarding the ASUG EA chapter here. I suggested contacting community member Rao Subba who is the EA ASUG chair.  Another good conversation partner around SOA methodology from a non-technology approach is Ann Rosenberg of SAP.
        I think you and she would share a good many views.  Thanks for this interesting content.
  • One of the major reasons of failure in SOA initiatives is the ambition to go big bang, forgetting alternate architectural possibilities.
    As with every other paradigm, the "aim small, miss small" part of it should not be forgotten.

    I like your comment on platform independence - you are right, this doesnot replace legacy backends, but provides a nice abstraction on an additional layer. And of course, it has the potential to increase cost unless used wisely.

    As a developer, I love abstraction - but one could create a monster out of it just as easily. I have noticed this in especially in standard code for CRM - there are so many layers between the database and the webclient, that I think SAP internally has created several silos of developers who specialize in each layer. This might work well for SAP since they are a product company, but I wonder if this is manageable for a client organization.

    • Thanks for your comments Vijay!!
      I share a similar view about the silos in which SAP has categorized its developers. In client's perspective, it would be a real pain to bring out the best of each domain and at that point the role of Business Process Experts gets evolved. One of the major intention of this blog was therefore to create a small checklist for Analyst or BPX before going for (as you well said) "Big Bang".
      Thanks & Regards,
  • As Naveen had mentioned earlier understanding how to use SAP's arsenal of tools and where SOA fits best in an organization is key.

    The Enterprise Architects can be key individuals in helping to balance SOA programs as per your previous Blog, however it is also a challenge...

    If the Enterprise Architects are engaged at a level where they are collaboratively defining technology strategies to support the business strategy, they can be a key resource in the enabling of SOA properly within the organization.  The whole motherhod statements come into play like "Think Big, Start Small", "Think Global, Act Local", ... Inserting a properly identified SOA PoC (to go live with) in a existing project is one scenario of "Getting Started"...

    I see SAP and ASUG doing a wonderful job in helping Enterprise Architects engage themselves confidently into the role described above.  I am currently working with the ASUG EA group right now to build local EA focus groups to collaborate best practices and learnings.  The Blog is ASUG Enterprise Architecture Day.