Skip to Content

Introduction:

I recently attended a Mastering of technology conference in Sydney. I really liked what I saw & heard. (Well done organisers). I was very happy to see SAP mentors and SAP talking about using open technologies available to encourage mobile application development (REST, Mobile Apps etc). I also liked the way SAP is innovating with their HANA product development. I also heard people say – SOA bubble is burst now –really? I did not think so – here are my thoughts on that.

Integration Tools:

With rapid adoption of mobility, SAP and its partners now provide many tools for directly integrating mobile application & web applications with SAP data. Let me try to list the tools available for getting SAP data out,

  1. SOA Manager – web services
  2. SAP Gateway – REST Services
  3. ADL – Community alternative to SAP Gateway
  4. Duet Enterprise
  5. SAP Unwired platform (SUP) – Sybase
  6. HANA Development tools
  7. Business Objects Reporting tool
  8. BO – Data Services
  9. SAP PI

I listed SAP PI as the last item because you may not need a middleware tools like SAP PI anymore for SAP Integration anymore. SAP is not a closed system anymore (old message for many).If you are not familiar with any of the above technology, there are lot of articles in SCN.

By now, you are thinking that these tools are developed for specific use case. Some people even say that I am mixing lot of things together. Yes – I agree with both.

To me, if you use any of the above features, you are actually performing some kind of integration activity and you need to think about governance, reuse of the integration and worry about managing & supporting the future growth/changes without duplicating effort.

Benefits:

I think that benefits of SOA are too good for any medium to large organisation to ignore. Lets role back the clock few years and look at the benefits of the SOA,

  1. Reusability
  2. Modularity
  3. Interoperability
  4. Discovery of Services
  5. Loose Coupling
  6. Agility to respond to changes
  7. Value of Integration Patterns

Do you think that any of the above benefits can be ignored by your organisation? I do not think so. I do not think that in the current financial situation, any organisation wants to spend their profit on duplicating systems, services etc. So is SOA really dead?

Conclusion:

In my opinion, one of the major problem faced by IT teams is their inability to stop their business process owners (read people with $’s) from purchasing a new piece of software (now the buzzword cloud software) while the same business process can be accomplished with existing tools with little or no custom development for half the cost of new software. This situation arises due to the lack of visibility of existing features.

Another major problem is Agility – Without proper tools for governing services available, it would be difficult for organisations to respond to changes i.e., acquisitions, mergers and vision changes etc. Actually many of the organisations are not still mature in terms of SOA governance & maturity.

I agree that architects are not be using the SOA/ESB buzzwords frequently any more –This may be because it is too hard to implement – Architects have not found a way to implement SOA as a product or come up with large scale implementation for customers.

While everyone is trying to adapt to the mobility needs, it is vitally important to keep the importance of the proven benefits of SOA governance and using correct integration patterns.

While SOA governance is important, it is also important to let developers innovate with new technologies. In my opinion, it is very important to establish integration pattern best practises which clearly describe the correct usage of each integration pattern and also review the integration patterns every year and we could consider all the software

I liked Martijn Linssen’s blog & subsequent discussion between Matthias & Martijn about the enterprise Integration. They talked about one middleware system facilitating integration between various devices, systems and partners. While I agree with that in concept, we may not have one product currently which can do everything for us.

http://1.bp.blogspot.com/-iCNf1BOYy-g/TtPHL7zHmaI/AAAAAAAAAso/tVlHrNkAf0I/s320/AIE+physics.jpg


One could consider SAP Gateway, Duet Enterprise, SUP and HANA development tools being part of the virtual ESB system and concentrate on using appropriate integration pattern and continue to innovate while software vendors worry about consolidating these various middleware tools.

Notes

Technically, I would like to see the industry come up with a way to describe REST services and publish them for other people in the organisation to discover them & use them. I am sure may will disagree with this idea but there is nothing preventing us from describing the REST service just by publishing the URL of REST services (and not worry about describing the payload of the service)

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Martijn Linssen

    Hi Arul, good post.

    SOA is dead in the sense that companies have stopped throwing money at shoving XML through every application’s throat and handscribbling complicated bilateral SOAP constructs to address those. Add to that the dumb notion of composite services and you have a mission impossible, and most certainly an ROI impossible

    ESB is dead in the same sense. If you use an ESB to make point-to-point connections, guess what?

    So, the integration issue not only remains, but has gotten a whole lot bigger: not only was the last decade a waste of time, with XML and the web causing script kiddies to flood the integration space, but there’s also a lot of mess to clean up

    UDDI? Useless – maybe in a hundred years from now. Why do you need to automatically locate and subscribe to services? The business will decide whether you use them, meaning people. Discovery and subsequent subscription is a little nerd’s wet dream, and of no business value at all

    I’ve read Roy Fielding’s dissertation, as well as the Wikipedia definition of it – they don’t match at all. However, Roy wrote it because he was worried the web couldn’t scale. Well, 12 years later, we don’t worry do we?

    But please just answer this question: way is the business value of REST?

    (0) 
    1. Arul Raja Adaikkalam Post author

      Thanks for your comments Martijn.

      I agree with you that implementing SOA / ESB as a project from scratch is impossible  and ROI impossible. If some one uses ESB to build a point-point , it is pointless as well.

      The point i wanted to make here is that benefits introduced by SOA and use of correct integration pattern is still critical to every organization for the reasons mentioned in the blog and it is important to keep the issues around Agility and Re-usability in mind while allowing your developers to come up with innovative solutions using mobility, REST based services, etc.

      (0) 
  2. Prateek Raj Srivastava

    I slightly disagree with you and Martjin here on some points.

    >>Architects have not found a way to implement SOA as a product

    SOA cannot be a product in my opinion. It is an architectural concept and moulding it into a single product would be a piece of cake even for biggest integration service providedrs.

    You made a very valid point about establishing best practices for integration patterns. In my opinion, these best practices will be very specific to companies and individual companies should have dedicated knowledge base for their custom requirements.

    Logically, it wouldn’t make sense to incorporate all the integration capabilities in a single product and then sell the same giant product variant for each integration requirements. The effort to combine all wouldn’t be worth and by the time this combined product reaches maturity, there will already be new integration technologies knocking the door.

    SOA is not dead, I would say it is more feared now. After some big companies loosing big bucks on the big implementations, the companies are now hesitant to go for implementation. However, I have seen companies who initially started slowly and methodologically are still firm on their implementation path. I have still seen architects interested in SOA implementation, however they don’t want to run it as a project (with fixed start and end date). It is a methodology which the organizations will slowly adopt.

    I agree that there has been a lot of mess because the maturity of integration products were much slower than the pace with which integration needs have evolved. However, there wasn’t any better options at that time. ESBs for me are towards end of their teenage. There is scope for a lot and there will be a lot coming in.

    Prateek Raj Srivastava

    (0) 
    1. Arul Raja Adaikkalam Post author

      Thanks for your comments Prateek. Yes. I do not think that any one is going to come up with a product to facilitate the implementation of SOA and even if some one attempt to do so, the industry will move on to something else by the time the product is available for customers.

      I think use of appropriate integration pattern is very important irrespective of the underlying product used. I do think that there are some use cases for point-to-point integration as well.

      My aim for the blog is not to trigger a conversation about SOA is dead or not. But to highlight the importance of the principals introduced by SOA and highlight that they are still relevant and developers who are innovating with Mobile / Hana / Gateway based applications should still consider using appropriate integration pattern based on the use case .

      (0) 

Leave a Reply