Let’s drive down the ESA Road(map) with Org.A, who start off on the ESA journey on bumpy roads (read Bangalore), with SAP NetWeaver. Having recently upgraded to ECC 5.0 and attended a spate of business and technical workshops, the business and IT users feel that they are finally “there”. What now begins is a saga of ideas, confused agenda, and tectonic shifts leading to formation of new power-pockets and to add to it all – the SI becomes the punching bag. The system is slow? The data is inconsistent? The reports are taking too long to run? Missing authorizations? The faucet’s leaking? – get the SI’s throat. And of course, the “Delta Force” or the power consultants who sold the Promised Land to corporate IT of It is long gone. Post an ESA Workshop that brings in fresh perspectives and a pinch of sanity, a time when the rubber hits the road, the next 6 months within Org.A are a roller coaster that creates ideological upheavals. These can be viewed as different phases to stability and the dawning of an intelligent system landscape that actually holds the promise of reducing TCO. And the journey begins…Let’chronicle that reading the mind of a Corporate IT manager within Org.A. And what unfolds is a simple truth – that SAP’s new agenda of metamorphosizing into a platform vendor is a double edge sword.
The “Feelgood” Phase:
TCO Discovery Initiative: A Solution retention approach: The idea is to find answers for Org.A surrounding migrations of J2ee applications onto the SAP NetWeaver platform. An option all the best pf breed applications are sure to take to confuse the market even further. Legacy applications, worth their weight in gold, need not be done away with and giving way to esoteric new dimension custom apps with the platform for an entire new generation of ISVs, here is an option for customers to find a middle path for lowering TCo. Org.A has many such j2ee applications (or another platform) running in the landscape that takes care of spare parts, TPM applications, time-sheet logging for local contractors, so on and so forth. These may be classified as long-term legacy applications that may not warrant retirement in the near future. The objective is to ensure Successful migrations of such applications. So, does it mean that this is the custom development’s new paradigm? What started off innocuously as custom development to the core ERP base to extend and personalize functionality now extends to a completely new spectrum of custom xAPPs? Ideas galore, this phase is when the focus is on getting the best of ECC 5.0 and exploring ESA underneath.
The “Dr. Feelgood” Phase: (Extract from the IT Manager’s Log)
A Platform migration approach: Why migrate? This is not about the application itself in question, but the landscape itself. The IT infrastructure will continue to run many SAP and J2ee systems on platforms by different vendors. A single platform vendor approach with SAP NetWeaver is what is now being looked at by Org.A. The aim is t simplify the landscape and also doing away with the need of procuring custom applications that are now soon to be storming the market in the garb of xAPPs. The number of application servers in terms of hardware is another possibility that Org.A is looking at. The other aspect is to improve integrations between the Java and SAP applications to improve data transfer, one security layer on top and the other reason will be to considering scalability, availability and other factors that form part of the ESA roadmap for Org.A. The approach would also allow Org.A to migrate these applications over the next few years to be provided with a single face with the SAP NetWeaver Portal and do away with the need for any other portals – both for internal and external needs. Hold on, how about having two layers of portals? With EP on top with a plumtree below or the other way round? The same with sharepoint? Or is that what Mendocino is leading towards as an xAPP? Or is it to provide xAPPs using Mendocino as the base to create enriched custom Apps riding on top of the core ERP engine? Hang on, this is a conspiracy theory.
The “Need a Shrink!” Phase: (Extract from the IT Manager’s Log)
xAPPs and composites: Now, I could be wrong on this – but there is practically no place where I could get a clear enough answer that could clearly differentiate the two. Stalwarts may take me to task on this by considering the simple definitions of an xAPP being a clear deployment approach leading to integrations and migrations onto the SAP NetWeaver development platform, thereby defining an xAPP, whereas applications purely made by the knitting together of services and components from the SAP Landscape could be defined as composites. Then again, there would be no clear cut definitions of applications that would be built as xAPPs as j2ee applications deployed on the SAP NetWeaver platforms and extended with enriched functionality with various SAP application components to define a composite as well. What does one call these? A composite xAPP? Whatever, but the idea that would hold true for organizations and make most sense for them would be to have these defined as composites. Semantically, my definitions can be grossly wrong, but architecturally and conceptually, it would make sense for Org.A. If Org.A is to port a Spare part management system, which is an existing j2ee application deployed on an IBM platform and given the platform consolidation exercise currently underway within Org.A. and extending the same with Guided Procedures and CAF to define a business process orchestration and execution, and tying up the same with standard t-codes from R/3, custom webdynpros and other callable objects that extends the spare part management system to provide a supply chain solution in a purely integrated fashion, this would be blurring out of semantic definitions. (Who cares about them anyways?). But – How do I ever get to know which are the T-Codes from TSTC that are now services enabled? Maybe, I need a shrink!
The “Wanna-be-a-doctor” Phase: (Extract from the IT Manager’s Log)
If you can’t convince ’em, confuse ’em!: A mantra clearly adopted by business & technical consultants, analysts and PMO members across the globe, the landscape seems all poised to further fuel this. Sample this – If Ariba Spend Management Suite is to go for SAP NetWeaver Platform adoption and certification, it would be done so by SAP AG. Despite it directly locking horns with mySAP SRM (erstwhile Commerce One, erstwhile Requisite user, erstwhile ASN user, now thoroughly confusing customers across the globe with ccHubwoo and a seemingly logical tilt with MDM) – what does the choice become? Damned if you do, damned if you dont. Instead, a sensible approach that would avoid the confusion caused by the devil and the deep sea – Org.A has an option to adopt a single platform architecture and wishes to retain its existing applications. having upgraded to ECC 5.0 recently, clearly there is no drive internally to adopt evolving technologies, but rather the need exists for exploration of ESA and its early adoption. Today, thoughts abound within Org.A as to which are the key T-Codes from TSTC that are service enabled. How can such t-codes be brought into the fold of its developing composites with such service enabled t-codes within the relevant modules that can lead to the exploration of migrating existing java applications from the existing platform.
The “Medication” Phase:
Ten steps to ESA Adoption: Consider this as the adoption of best practices with high-end consulting. VMI has always been a The Ten Commandments for ESA Adoption: Much needed option for organizations to lower ICC and make use of the JIT concepts to keep costs low. Leveraging all this to manage demand and supply fluctuations.
1. Study your Value chain: The objective of the adoption program now becomes to study various processes across the value chain – Order-to-cash, procure-to-pay, demand-to-fulfill, acquire-to-deplete so on and so forth.
2. Identify your collaboration needs
3. Identify your value-chain pain points
4. Grasp the vision
5. Prioritize your challenges in terms of cost, speed and value
6. Superimpose your IT initiatives on the Prioritized challenges
7. Apply the NetWeaver component approach on your existing landscape
8. Arrive at the most-efficient scaleable landscape
9. Prioritize IT initiatives around System landscape
10. Lay down the ESA Roadmap for the next 3-5 years
Clearly, there is value in an ESA Workshop.
Outro: The “New Reality Show” Phase:
Definitely, turning Platform vendor from a best-of-breed ERP vendor approach has its flip side. Areas of strength get bundled onto the ECC x route, still leaving the market gaping for the proverbial “white-spaces”. Why proverbial? Simple. If it makes direct sense to customers and is fit for mass production, it has to be there as part of SAP’s roadmap. If the “white-spaces” are not rampant and becomes too niche, it is fit for an ISV. Hold on, isn’t this want the market dictated 10 years ago? Will this be the dawn of a new era of best-of-breed? Composites and xAPPs have the potential of enabling customers to now choose alternates. If a solution from SAP is a soft-spot and does warrant a relook, there are now options for potential co-existence in the same space. This, by no means, is a sweet spot for a vendor to be in. For example, In the Architect’s World, in the next blog, lets see how we can lock horns with SRM and take this to a newer dimension with composites and xApps.