The Objective of xApps is to help organizations fill the white-spaces/partner opportunities or whatever one decided to call them – bottomline, they are areas which are of lesser strategic importance to SAP/someone else knows the job better/or the gap is better known to the customer community. A brilliant stance taken. If this stance is construed as taking one approach within an organization that forms a clear strategy around xApps – far beyond esoteric versions of best-of-breed applications, CXOs stand to gain immensely. Organizations typically get saddled with the on-the-ground projects of highest priority, and it is this systemic myopia that makes the landscape inflexible and totally cluttered up with all sorts of vendors and SIs slicing a piece off the budget pie. Add to this the M&A syndrome, varied cross-geo operations, with myriad pockets of power, it calls for an external agency to help de-clutter the system landscape. A few techEds and Sapphires down the line, the awareness is built, but the action is slow to follow.
Now, the optimistic scenario for the above case is equally predictive. Take the corporate direction of SAP and start the rollouts and implementations across geos and well-paying Business Units with enough decibel power, and you have a strategy on the CXO’s table that talks about upgrades, implementations, roll-outs and extended maintenance. The mantra being – the best way to snuff out best-of-breed solutions is by bringing on the standard functionality route. Very true and logical, but mostly works well on paper. Custom apps that address niche processes cannot be wished away. The question is not _ “WHY” should the legacies be removed (reinstated by Shai in TechEd as well), the question is “HOW” to do the same. And where a BPX/ESA Architect fits the bill and acts as the bridge in bringing both the worlds together.
What organizations look for is a strategic/realistic approach that would address industry-specific business processes that need enhancement to suit value-chains by providing a safe passage for their legacy/3rd party/custom applications with SAP certified solutions. For a BPX, it is the accelerated adoption of the Composition Platform which in turn would facilitate faster ESA Adoption with CAF. As long as there is commercial meaning to identified solutions that would be built to snuff out non-SAP applications from the landscape and a value obtained, such a strategy will only help lower TCO. A strategy that will underline the need for Reverse Engineered xApps.
Defining the “Reverse-Engineering” Approach for xApps:
To understand what I mean by reverse-engineered xApps, let us consider the following ready-to-offer standard recipe for creating any strategy document. Organizations would benefit most from a strategy that would provide options of building and implementing Composite Applications or xAPPs at minimal cost, lesser that that of implementing a new business solution and assist in replacing existing best-of-breed applications as “customer-owned” Industry solution incorporating best-practices. The Objective of such a strategy should be to fill the white-spaces in organizational value-chains and provide a safe passage with the composition platform. As long as there are IT systems, there are business cases existing. Abstracting out the approaches to the highest level, below are the options that are consistently doled out to CXOs. And then the lesser mortals follow.
As a BPX/ESA Architect, one would put a few ideas as part of the strategy being defined. The more the options, the better the thought process one can facilitate.
Thought #1: Take the core build with Ecc6.0. Upgrade and solve a host of issues, including extended maintenance.
Thought #2: Snuffing out in-house custom java/.NET applications with the CFN/PBNW Approach.
Thought #3: Building process efficiencies with Guided Procedures and the Composition platform (CAF+GP+VC).
Thought #4: The “Select-and-compose” approach for light-weight composites with ESR.
Thought #5: De-clutter UI and compose with services a process that you consider is oft used.
Thought #6: Bring paper forms on UI to live with the old-world charm.
Thought #7: Getting creative with Business content that can be created and uses PI to leverage ESR.
Thought #8: Using Business Content/Ready Adapters approach – the ‘leave-it-to-the-experts” approach.
Thought #9: Buy off light-weight xApps from “xTunes” connected to your ECC core (The side-car approach)
Thought #10: using the hybrid approach to scale CFN/PBNW with the Composition Platform for creating meaningful, heavyweight xApps that lower TCO and do the job right. (The “Reverse Engineering” Approach).
Given an Organizational landscape of a large SAP footprint, 800+ legacy applications, the last thought is what make it worth the time and money being spent. In the last blog, we discussed the approach for retirals of such applications, here, the objective is to help create a strategy highlighting the need for the SAP Composition Platform that would form an essential part of an organization’s 5-year ESA roadmap to help create Ultra-light, Light, medium and heavy-weight composites that would need to be built to do away with the dinosaur-applications that address processes that is best outside of SAP. And the objective of “Reverse engineered xApps” should not be to merely replace legacy/custom applications, but encompass cross-applications in a way that would address the larger piece of the process.
How could an Organization go about the process:
To better understand the idea, take the example of an application that has been built as a budgeting and purchase order application used by the Marketing & Sales group of an organization, addressing multiple business units, that helps in tracking actual spend against planned commitments. Maintaining the synchronization with divisional Cost, Spent & Committed allows up-to-date business decisions regarding budgets, commitments, and spending Spent & Committed is also extensively used as an reporting tool to generate reports for the high level management. Our mission – To Kill the legacy app.
Sample Budgeting legacy Application retiral by “reverse-engineering”:
Interfaces: The budgeting Application pulls the master data (maintained in R/3), using an Interface with a 3rd party EAI tool, run on a daily basis as a feed to the budgeting application on Projects, WBS Elements, GL Accounting combinations, Vendor, Customer, Market, Currency, Region etc. SAP and the budgeting application take master feeds from another custom application real-time. The Payment Request Interface processes real-time validations of valid & existing Account combinations using the EAI tool for Invoice generation. Combinations that are valid and non-existent are created, combinations that are valid and existing are used, combinations that are invalid are rejected. Invoices are then sent back to R/3 and the various stages of the Invoice are pulled back into the budgeting application from R/3. Again a redundant interface. Another interface that runs every weekend to bring in the invoices that have been generated using some legacy systems and are not a part of the budgeting application. So, here is a budgeting application that is simplistic and is existing in the landscape of Org.A as a java application, uses a 3rd party middleware application as well, provides reporting and also provides some additional functionality over and above than what is mentioned above. So, here is the deal. Presuming that the complexity of the application being discussed above is slightly more complicated and justifies a separate existence as an xApp.
Now, take a sub-process, super-impose the same on the architecture defined in your previous step. Does CAF make sense? here? Which are the existing components that you want to port onto the platform to ensure that you call them as services? How do you lay down the set of actions as procedures and who does what? Freeze on the information that must be made available on a retro-active and a proactive basis for reporting Does the entire scenario with in with CAF and guided procedures? Can the UI be modeled by a BPX? Can Analytics be used to make the application more jazzy?
Based on our approach, the xApp could:
a. Be built using CAF 7.0 SPSx & VC 7.0
b. Provide a rich user experience serving also new user groups through SAP NetWeaver Portal
c. Make functional and system boundaries invisible
d. Provide process context and overall process visibility
e. Enable enterprise-wide collaboration
f. Should be installed and adapted in a very short time
g. Could be a PBNW solution scalable with CAF/GP to address the budgeting process
h. Lower TCO by doing away with the 2 legacy applications and unwanted interfaces so as to reduce the dependence on 3rd party EAI
i. Leverage the SAP NetWeaver platform in tune with the 5-year ESA roadmap
j. Provide a bunch of reusable components as services for reuse
Some of the systemic changes per individual module, the xApp could:
Budgeting Module: Budgeting Application
Use ESA: Budgeting a particular project based on the project and the account element combinations
Use ESA: Maintenance of actual, estimated and spent amount maintained here
Interfaces/ESA: Project brought into the Budgeting Application, entry generated for valid accounting combinations for project
Guided Procedures: Users enter estimated budget for each combination within initial estimated and actual budget as the same, UI using VC, reporting leveraging Analytics
Reporting: Spent details filled up for invoice generation for project available to executives
Approval Module: Budgeting Application
CAF: List of approvers and workflow generation
CAF: Approval Limit for approvers
CAF: Final Approver to approve before Invoice generation
UI: List of features as Pending for approval/watcher
Purchase Orders: Budgeting Application
ESA: Validate PO against account combination based on rules (No budget declared, already used amount, deny creation of PO)
ESA: Validate vendor/alternate vendor against PO to generate Invoice
CAF: Generate approval list based on Account element/value of PO
CAF: Add or delete approvers except last approver and mail notifications
ESA: PO Revision process (PO approved or not? PO used for a different account combination? Increase amount in line item?)
ESA: PO Reversal: Validate amount used and free up unutilized amounts
Payment Request: Budgeting Application
ESA: Invoice with PO details with validations (PO Line item value more than Invoiced value for a certain limit)
ESA: Invoice without PO with validations (Validate against a certain limit)
Interface: Sent via EAI for validations against account combination (ESA again or no middleware?) and send Invoice to SAP
ESA: Invoice created in SAP & send status back to SAP
Send check to vendor as amount Spent in the budgeting Application and use for reporting
Cost Load: Budgeting Application
Import of Invoices into Budgeting Application where invoices have not been generated by the Budgeting Application running once a week
Reports: Budgeting Application
Budgeting Application report, Vendor, budget, PO, PR reports etc. based on which some critical decisions are made at the high level management
Budgeting Application report is the most important one, since this gives the exact figures for each project, account and element the amount budgeted, committed and spent
The Alternative Approach with a “reverse engineered xApp” is an xApp approach like iPRO, helps Org.A do away with unnecessary interfaces and leverages ESA, uses standard SAP Objects, Uses EP/CAF/BI/VC and Analytics for the Budgeting Application build with base R/3, completely web enabled, and aligns with SAP NetWeaver and ESA roadmap of Org.A as part of the 5 year plan. And this is one reason why organizations may benefit with such an approach and a zone where a BPX can add value.