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.
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,
- SOA Manager – web services
- SAP Gateway – REST Services
- ADL – Community alternative to SAP Gateway
- Duet Enterprise
- SAP Unwired platform (SUP) – Sybase
- HANA Development tools
- Business Objects Reporting tool
- BO – Data Services
- 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.
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,
- Discovery of Services
- Loose Coupling
- Agility to respond to changes
- 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?
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.
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.
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)