SOA, being looked upon being enabled by SAP NetWeaver requires a much greater depth of understanding of the current situation. Not just from a business perspective, but in terms of the clear overarching vision that SAP is putting forth in terms of driving a business context driven world, going beyond developers who believe that XML can solve all issues around interoperability. The sun will continue to rise in the east, irrespective of whether SOA is a success or not. Blogs on whether SOA is dead or alive are irrelevant and only meant to create “tabloid-like news”. More importantly, for businesses who are eagerly embracing SAP NetWeaver as the platform of choice, albelit slowly and cautiously, interections with SAP Customers only give one single conclusion.
There is life after upgrade (Technical, functional or Business), we see so many of them taking place now. The point is – why are SAP asking customers to do so – beyond just licensing and de-supporting of lower versions after a stipulated deadline? The answer lies in the fact that in order to drive an organization and cross-business services meta-model, it is a means to enable true interoperability in terms of A2A and B2B at the backend of SAP Customers, who will then have a true opportunity to head towards a Cloud-based environment of allications (Read “ASP++ Model”) I’ll jump ten steps ahead and presume that the enterprise services have been created in an SAP Installation/Customer landscape – outside-in or inside out and it is all hunky dory with the standards and now the myth about interoperability is a reality.And fast forward life to get transported to a world of only enterprise services in bundles, a hosted environment, ASP model of application hosting in an Obama era, with all Customers near-shoring and focussing more on Best of Breed Application services providers with a niche set of Software vendors and the world of Offshoring large transformational engagements to Indian Partners is a thing of the past.
Consipracy theory: Year 2011
Every single SAP object which is “SOA-ble” becomes a web or an enterprise service meshed together in terms Business Services in a mash-up of Web 2.0 tookset on the Cloud. Data is securely outsourced near-shore. These get logically clumped up to define a small business logic like a “cancel order”. Really, that’s old hat. What now becomes of es-bundles is – every module and related entities within, say, the SDO module now starts making a different sense to me. The SD Module is now an enterprise service bundle. With specific sub-bundles (for lack of a better name) like pricing, shipping, transportation and others comprising the same. Back in the ’90s, I had to resort to customization and user-exits and other z-objects to extend these applications, and relying heavily on ABAP. Now, to come up with say, a pricing procedure, which I start treating as a sub-bundle, extending the same to make it a custom pricing procedure, pull up the condition types, access sequences, condition records, do the SPRO configuration in a different way. And now, I will not be using user-exist, instead, one could look at creating these as web/enterprise services and creating my composite to include this additional step for any validation. And a developer now chooses to decline the option of customizing anything in ABAP, rather treating an ECC installation as the organization’s BPP Motherboard that wires up together to form a matrix of motherboards with the mothership as the central computing engine on the Web, the true essence of “AcrNet”. And refuse to do any customization (that too in a module like SD!). New processes, defined as composites with new services built out-side in and populated in a hosted ESR – somewhere in the world. You get your updates to your ECC installation not as service or hot packs, but as online updates as in Microsoft, the same applies to a set of desktop tools – which is more like a Facebook that runs rich UI interfaces and provides me my space of social and business computing. SAP Logon pad be hanged. Muse is the next Lotus Notes. Now, with the ECC installation in place without customization and swept under th carpet, the installation of it all was as simple as that of a Microsoft office Implementation. No more downtime, no more SP installs. And yes, it is 2015 and Microsoft and SAP are still two different organizations! Wait a second, why need an installation at all if you can run a utility meter for services to be used on a pay-per use channel in a Cloud-based environment? Does it really make financial and business sense?
Grapes & Wine:
One would be foolish to presume that any customer would be only working his business with SAP and SAP applications alone. A dangerous proposition even if considered as a hypothetical situation. To make service orchestration a reality, let’s forget SAP for a while, but rather looking at it from a technology perspective, the underlying systems have to support communication based on the Web Services standards stack which could be web based or custom. From a business application perspective, the underlying systems would have to be in a position to provide meaningful services to existing and new custom composite applications based on XML. And from a Business perspective, the initiatives have to make business and financial sense, else why contemplate SOA at all. Of course, a single source of truth for Master data has to exist – not that it is a mandatory proposition as many would like us all to believe, with MDM being the silver bullet. A single source of truth for master data may be beneficial; it will go a long way in defining enterprise-wide services meta-model from SAP & non-SAP applications. That’s for the master data. But the true essence of Enterprise SOA lies in the fact that there has to be Organization-wide services meta-model that brings about the true interoperability that is driven by business semantics operating in a context-free world. Services meta-data has to exist – Enterprise wide.
More often than not, the grapevines are abuzz with some key points that often get discussed post my ESOA workshops in informal discussions are follows:
- Why and how do we approach enterprise wide services meta-model? SOA is not a buzzword, the aim is to deliver what CORBA could not – Interoperability.
- What should be our target future SOA Platform?
- Are we geared up sufficiently in terms of our current state on SOA readiness?
- How do we create a SOA governance model that will work?
- How much are the standards & methodologies being built-in?
- And how do we ensure that we are in a position to create a set of standards-based application in the future, whether we build it on ABAP or on Java?
- How do we influence the vendor to do our bidding? Is the ecosystem really so powerful?
- How are the market dynamics influencing our reality? What about the speculations that Analysts so profusely propagate in terms of vendor direction?
9. How do we go forward with a heterogeneous environment?
- What is our SAP footprint today? What’s our plan? Is it 40% today moving to 60%? Or what?
- How much influence do the processes covered in SAP yield in the overall scheme of business users who control the IT budgets and Purchase Orders?
- What is it that we want to outsource? How do the existing and traditional execution models of engagement change with the course taken with Enterprise SOA?
- What is our mindshare around composition versus customization? Is SAP killing ABAP?
- Is there an Application Retirement strategy in place with SOA? For reverse & forward engineering?ow can a Systsem Integrator help an SAP Customer with enterprise Architecture starting with SOA Initiatives
- Are we moving toward a Cloud environment with a more loosely coupled architecture that is driven by a common Business Arhcitecture across the organization?
The next steps become to work the Business Architecture across the board, in a financially viable model as follows:
- Create innovative Business Relevant IT Strategies
- Enable Solutions delivery through standard technologies and designs
- Build future state definitions for each business function in advance of business needs throughout the entire IT Framework with SAP’s EAF (Enterprise Architecture Framework)
- Establish Application Portfolio Rationalization Plans for the enterprise and business segments
- Record the results in an enterprise architecture model
- Present the model and promote its use in the enterprise
- Make sure money is well spent by analyzing key considerations as follows:
–>Ensuring consistency between applications, to maximize reuse
–>Ensuring continuity from one development to the next
–> Preventing silo developments specific to certain divisions
What’s the System Integrator’s role in all this?
- Help SAP Customer approach an enterprise wide services meta model
- Drive Interoperability, not SOA
- Create a SOA strategy on multi-platform environment with SAP Net weaver
3. Help establish a SOA governance model that will work
- Help set up standards & methodologies being built-in in SAP and Non-SAP Application portfolio?
- Help influence SAP shape product direction per requirements
- Help design IT strategies to go forward with a heterogeneous environment?
- Help establish an Application retirement strategy with Reverse Engineered xApps as a starting point with ESOA
- Ensure strict Governance models through the use of TOGAF or other Architectural frameworks
- Help establish linkages with SAP through Wipro as a fulcrum in key SAP initiatives like Project Galaxy, Project Plexus and COIL
- Keep the financial records clean, avoid PWC like plague when it comes to getting the financials audited.
The power of the ecosystem that SAP has been creating around with BPX, SDN, iCOD, RIG etc., which have been more or been shaped up in the conventional sense of the marketing hype and buzz certainly has got SDN and BPX to a level, which more or less is at a stage of stagnation. Whats next? More people? No, it certainly cannot work that way. More evangelists, more marketing buzz will probably add a few more thousands to the endless list of the users (who taper out as well over a period of time), the time is ripe for a quantum innovation around the same. Let me share a few thoughts around the SAP Ecosystem 2.0 (If I may). Of all the customers that I get to meet, thanks to the ESOA Workshops, most of them are looking for a private business network that helps them define an entire value-scenario in terms of various business processes, being addressed as a heterogenous solution of multiple product vendors, with SAP being one one the key process drivers. The ask seems to be more of Private business networks for collaboration in terms of vertical processes, the need for privately run ecosystems of system integrators, customers, specific themes of discussions and addressing the solutions around the same.
Ecosystem 2.0: What is our role as Netizens in all this? Gone are the days where any network can claim the growth of the same by adding sheer numbers of people, it certainly calls for a new line of thinking, some innovation. Some of the key points that will come by in defining Ecostystem 2.0 will be as follows:
a. Formulation of Private Business Networks: With Project Plexus in the offing to extend the collaborative network for geeks and dorks, sdn and bpx cannot remain a facebook for geeks. The value of an ever expanding ecosystem will need different handling. A network which is more exclusive and private, more specific and collaborative with very specific objectives that goes much beyond the conventional norms of the definition of ecosystem. Ecosystem 2.0 will be more value-scanrio drive, focussed on short-term objectives like the CDG initiatives, driven by customers, system integrators, SAP and even competing products. And such initiatives cannot be run by SAP alone, but such networks, private and specific will need to leverage Web 2.0 tools, be driven by an extended ecosystem, and owned by System Integrators. And SAP needs to be at the epicenter of such hubs and needs to function as a business exchange based on the suggestions of such networks. Imagine SDN/BPX becoming more like a mutual fund of such exchanges run and networked by other networks. The Other vertical networks could also be newly spawned, formulated by large system integrators, or the formulation of such networks within existing social (yet corporate) networks formed by LinkedIn, Facebook, Twitter, Digg, Bebo and Xing.
b. A Web 2.0 plaform that makes a seamless integration possible for the networks of tomorrow: These go hand in hand. The ability to transform system dumps or key SLA triggers will need to go beyong uwl integration with portals. It has to take the shape of being automated into a blog or a wiki, integrated with chat engines, have the ability to be shaped into web-widgets (blidgets) or desktop widgets and give a BPX the power to work more on a maganement by exceptions.
c. Twitter can be made more corporate and could be used more than a mobile application for such matters. SLAs in business processes, and their respective triggers will need to become more integrated into applications (Galaxy being the first logical move in that direction with the composition environment driven by BPMN. PI would need to evolve more into an ESB (the direction is just right) and focus more on B2B Integrations. Cordys becomes a BPM engine to watch out for. Let’s just say, one needs an intelligent WSDL generator.
c. A vertical, business process driven focus that fosters the use of such networks that could help spawn the creation of agile applications: No doubt, the world of composites opens up an entirely new thought process of addressing customization in a new paradigm, this loose coupling of business logic from the stable core of best practices as part of the core ECC solution needs to be addressed more as a strategy for large SAP shops, than being looked upon as a piecemeal approach of a bunch of best-of-breed solutions that might end up becoming more a newer way of clutterring up an existing landscape with best-of-breed solutions coming into the IT landscape of powered by netweaver solutions, certified for SAP Netweaver solutions, xApps or what-have-you. A sound strategy around customizations needs a closer and a harder look during the upgrade process itself, where key chunks of ABAP development need to be identified to be snuffed out as part of a medium-term strategy. The need for upgrades can only be justified as something beyond a technical upgrade, and a functional upgrade takes a long time to fruition. Identification of Customizations that can be turned into services, es-bundles and composites is something that customers are really interested in. The world lives beyond SPAU and SPDD. IPs matter. (Read the return of “Best-of-Breed” Solution vendors)
d. Faceless applications that could be treated in different ways in a heterogenous environment of multiple platforms: ES-Bundles created using PI 7.1 as Outside-In bundles being consumed as RIA outside of the SAP Business Suite.
e. Second life is serious stuff: Walking the talk can be best demonstrated live. Not that this is really a place to do business today, SL can be best used to demonstrate the viability of walking the talk with SOA. Why invest heavy in Solution Labs and COILs when one can create a Perfect Plant, a Bank, a Stock Market, or just about anything at practically no cost and make it available world-wide? 24/7? With Bots to boot? Second Life needs to be taken a bit more seriously
g. RIA is what the BPX Community will need
h. Composite Applications are a farce/IPs matter, Bundles matter: Is there an xApp that really makes a true difference today? The best ones are Ported Applications (PBNW), like MII – Lighthammer.
i. An SAP driven-xApps strategy may not be a wise move
j. ES-Bundles are a better bet than composites. Anyday.
k. Building stuff will always be better than buying stuff
l. TOGAF will become more important and relevant
m. BYD is not what customers really want, but will need to move to the same.
In order to help customers maximize ROI, its the steps that will be taken now in a stricter economic scenario that will make the difference in terms of survival. A lot of buzz is being generated in the market around Web 2.0 and Enterprise 2.0. Enterprise SOA, AJAX and ESOA seem to be coming in more closer together. Starting with social computing, a lot of SAP customers are now taking a serious look at these tools and making them more enterprise worthy in terms of bringig about business applicability. More and more loosely coupled services seem to be proliferating the marketplace with new business models being thought through for such young-startups. A trend that one was once fuelled the b2b boom, the new-age of the web now seems to be turning more real. Largely, the consolidation of the market also seems to be fuelling the growth of this thought more. SAP’s ESR – standalone and PI-Linked, the evolution of the Integration builder into the Eanterprise SOA builder – the architecture of the underlying ERPs when you note the evolution of Oracle and SAp is bottom-up. IBM and Microsoft seems to be coming top down. There will certainly be newer business models for hosted applications trying to get a chunk of the pie with SaaS as a model. Definitely, the Cloud. In order to do so, a lot of evangelism must be around the following in terms of IT projects.
- The approach to harmonize master data
- The approach to a services meta-model
- The approach to tapping transactional data
- The approach to standardize processes
- The approach to enhance processes
- The approach to standardize interfaces
- The approach to application consolidation
- The ability to define core & non-core processes
- The ability to define processes to be automated
- The ability to define standardize IT support processes
- The defined KPI implementation
- The approach to futuren ABAP Customizations
In a nutshell, licence sales are in, service revenues are out. Utility revenues are in, Transformational deals will be played safe. Ecosystems are in, single-vendor strategies are out. Knowledge is in, hollow sales/weatherman talk is out. Innovation is in, transformational deals are like pyramids. (Pyramids depict tombs. Avoid pyramid structures in your presentations and blogs :-))