The fundamental premise of Enterprise Service oriented Architecture is the encapsulation and abstraction of various business activities, modeled as enterprise services, from the underlying functionality of enterprise applications. It is NOT an IT thing. More and more one get into it, the more one gets convinced about a world where the installation of a core ECC would become as simple as a Microsoft office implementation, with updates being installed as service packs as with Microsoft. The more it seems like it will become a UI-less world. ERP will get pushed down under the carpet, business packages will come in the form of Enterprise service bundles, developed outside-in to drive an enterprise wide services meta-model that will be driven by standards Organizations, along with SAP. And these services will find their logical place in the ESR, which, Incidentally moves into a stand-alone mode, like the other registry/repositories of the world. And this move becomes significantly important from the future perspective, a world in which SAP & Oracle will be battling Google.
The Market movement:
Customers are now moving to SOA for Business process flexibility (not just TCO reduction), IT integration and creation of Shared services platforms by optimization of IT infrastructure & Applications. Therefore, it becomes more important for
customers to derive SOA models that are driven from one end-point, a world of Software as a Service (SaaS) or a world of an Application as a service, reminiscent of the past B2b era gone by, the more focusssed customers would become in looking at the Enterprise Service bundles as business processes that start from process modeling in any BPM tool, being rendered “SOA-ble” through BPEL, the need for a UI will diminish. This, in my mind, will have a significant impact on the development
efforts around the Composition Environment (CE 7.1 & above), where the process design tools will determine the way enterprise services would need to be modeled in order for the same to be orchestrated. And of course, created “Outside-In” by the
ecosystem to be loaded onto a repository that would form multiple uses.
Customization in ABAP must die:
“Inside-out” development would be good, for SAP. And maybe the same model will be adopted by Oracle. SAP is anyways transforming its suite to a standards based SOA services to offer BPM flexibility & interoperability with other applications. If we keep aside SAP’s rendition of SOA as ESOA, it is good, but only, if customers decide to continue to code in ABAP. No doubt, this will ruffle the feathers of die-hard ABAPers, but the very essence of a service-based architecture is to take distributed computing to a level where it starts defining Monetization of SOA. By that I mean, if customers had the choice of a vanilla SAP ECC installation pushed under the carpet, with all these automatic updates as in Microsoft, with all key SAP objects like IDOCs, BAPIs and RFC-enabled function modules as standard, all this would mean is to help the BPX focus on the white and blind spaces from a process perspective for ERP and compose them with services. By composition, I would also mean that the service composition be rendered in a UI of choice for a customer with a bunch of these objects becoming callable objects that can be composed as applications for a mobile divide, have a .jsp and .asp as callable objects, have it generated as an iFrame or a Portlet for the IBM and the Microsoft world. Bottom line, ABAP customization should and would evolve to a level where the service consumption would be driven by the chosen technology platform of the customer.
Only Multi-platform landscapes would persist :
Business dictates technology. And so is the case with M&A. If an SAP centric-IT landscape driven Organization would acquire a company of a reasonable size, then obviously, the decisions around the platform domination would be of least importance. BPXs drive business. In order to realize a multi-layered and a Long-sustaining SOA strategy, any organization embarking on such growth parameters would need to carve out IT strategies that would consider these practicalities as reality. Therefore, any sane SOA Roadmap needs to ensure that it addresses a multi-platform environment, enforces governance and compliance – not just from a process perspective, but from a services perspective and create a SOA strategy that brings google in the loop as well. I mean, why should an Enterprise Search not be driven by Google? Why should not the searching for accurate services across repositories be a prerogative for Google that could search through a taxonomy defined enterprise wide to scan through ESR or a Systinet or a WSRR? IBM is slowly moving towards the WSRR (not that I have seen the actual working of the same but through a series of trainings around the same). The population of services being defined industry-wise that would ultimately lie in WSRR for all non-SAP related services and all SAP-related services in the ESR, the chances of customers adopting a strategy that straddles both these repositories (and probably more) ultimately would define the new market for service governance from a design-time perspective. Identifying rogue services or services that could have the potential to become rogue and other such key parameters would span of a completely different breed of PBNW and CFNW solutions. Else, the ESR and CE from SAP needs to be scaling up more from a rational perspective – speaking of which, why should customers be investing in IDS Sheer products? Would the costs come down significantly if the Composition Environment had a process modeling tool as ARIS embedded in the same? Or should the Solution Composer be evolved to this state? Food for thought. Composition Environment alone cannot be the sole composing tool, I mean, one could have the composition environment from IBM that digns into the ESR for services that could be needed to compose a true composite.
SaaS and BPO:
If the game becomes more driven by the registry/repositories, the bundles or the services that would be today created and populated into a standalone repository will lead to the ultimate world of Shared Services and BPO. For all the services created for a particular process, they need not have a UI, instead, SIs and ISVs and Customers should have a world which would enable them to create new service lines with key processes, hosted as a third-party and creating this business as “Core”, which would ultimately make one pause and think before creating an xApp. Or more importantly, buying one. So, while SAP should continue with its “Inside-Out” Approach, the “Outside-In” approach would be the place for the Ecosystem to play. And may the one with maximum foresight and process knowledge, win. Salesforce.com is a great example towards this model.
System Integrators and their Obsession with xApps: One radical school of thought is – these would not sustain in the long run. Too expensive in terms of licenses, too vendor-centric (especially SAP), this approach of creating Composites needs to be revaluated by SIs, ISVs and Customers alike. SAP should be more focussed with the SOA strategy as IBM is today. The very fact that IBM, despite not having the Application muscle power. Rather, the focus should be more on UI-less objects that could leave the choice to the customer. Choices in many ways.
This means the transformation of ERP business into an application landscape where the customization can be taken out of packaged applications and be rendered as packaged business processes. This is a tectonic shift that may truly alter
the way we look at distributed computing – but the IT centricity comes down and the business process expertise rises from the core ERP. Therefore, we need to look at this approach as the anti-thesis of our existing way of doing business today. SIs have to become “Trusted Advisors” for customers. And the SAP folks need to start creating this large pool of SAP NetWeaver Consultants and not look at SAP Trainings as a revenue stream. Else, IT decisions will always have a large “Cost” factor associated with them.