The Architect’s World – Episode 42

Intro:

I wanted to share my learning from an ESA Workshop in this blog. Org.A is on 4.7 today and the landscape that is clearly identified is a move to ECC5.0 and the upgrades of their SRM, CRM and BI systems. Today, they run over 800+ registered legacy/3rd party/custom-built in-house applications to support various process needs within their business boundaries. After doing an ABC analysis of their non-SAP applications, Type A applications (which are very much going to remain in existence at least for the next five years, these applications do not fall into the “SAP Core build” category and they would like to retain these applications (primarily java) in their landscape, but look at ways for making them “NetWeaver compliant”. The objective of this exercise was to study the high-level details of the systems, the areas that they address within their value chain, and to arrive at a set options available to make this transition a smooth one. This means that now, as an ESA Architect, we are faced with primarily one question – how to make xApps out of them. This sets you down the path of the definitions of the various types of xApps and the way each application area may need to be treated. Since the functionality of the applications are retained in these 4 custom applications (we shall cover only 4 of them), the need is now two-fold:

A. How does one go about building xApps – right from a business case definition to execution?

B. If these are to be converted into x-Apps, how does one classify them into the various categories of xApps to arrive at? the process model for the execution?

A: “Projectize” the initiatives :

From a strategic perspective of moving towards ESA adoption, to the tactical activities of identifying and prioritizing the key initiatives as part of the workshop, the operational intent is to now work these identified systems be brought onto the SAP NetWeaver platform to help Org.A move these as xApps. For the same, let us now design a methodology for the execution of this activity.

For the Identified initiative:

Step #1: Evaluate ESA:

Build the business case: Easier said than done. But it can be done in a logical way by a BPX. There are many questions that would come up for evaluation, the key ones driven towards cost, as that is to be our mantra for designing a business case. A sample set of the questions could be as follows, but this could very well be a starting point for any discussion for a BPX or an ESA Architect for this activity, consider the following factors to come up with the business case:

– What is the annual maintenance/support cost of this application?

– How much FTE time goes into enhancements and troubleshooting?

– Which is the business unit within Org.A does it address?

– Are they to fund the new initiatives on SAP NetWeaver?

– How many users, roles and what is the revenue impact on the operations with this application?

– Is it a mission critical application that involves the line or the support function?

– Why should the activities be considered a “white-space” for SAP – is it factual or license-cost driven?

– Does the sub-process that the functionality of the application addresses have a huge revenue impact if the enhancements are done?

– Is it an application for the intranet or the extranet as well that brings in business partners?

– What was the total cost right from hardware, software, build, implementation & FTE cost associated with this application?

– What has been the annual costs of maintaining, upgrading, training users on this application?

– What is the cost of Integrating this application with the SAP Landscape?

– How many interfaces? How many simple/medium/complex interfaces?

– How is the Integration done today? With another middleware application? What are the running costs around the same?

– What is the YTD keep-it-running cost?

– If the same functionality is carried forward but driven as intuitive processes, will it address the business need?

– What is the Integration & UI enhancement costs for the application that is planned for this year?

– How much interaction with the underlying R/3, BI and other SAP systems does it have for validations, custom tables for calculations, reporting etc.?

– Which are the validations that happen outside the said application for which the custom interfaces have been/are being built?

Step#2: Analyze the business case with the current:

While identifying the costs with the current setup, analyze the business case with the spend break-up that goes into making the custom application tick. The trick here is to break down the overall costs into fairly large buckets of costs that could help one arrive at statistical buckets that could be understood by techo-geeks as well. Again driven by costs. A sample set of the questions could be as follows, but this could very well be a starting point for any discussion for a BPX or an ESA Architect.

– Of the Total spend in the existing application, what was the YTD value of the Implementation costs?

– What was the FTE requirement and how much was the effort in bringing this application up?

– What is the associated $ value associated with this application on a year-on-year basis as a measure of productivity Improvement, process compliance, process adherence or process support?

– How long has the application been in existence and how much is being spent on licenses for the applications and the surrounding applications’ customization and interfaces?

– How many interfaces run between your identified application the core R/3? Is R/3 the source of truth for processing?

– How much of this cost can be attributed to IT maintenance vis-à-vis actual benefit value?

Step #3: Address the TCO through Current process:

In this step, it makes sense to approach the application landscape with a mapping towards the Organization’s SAP roadmap. The idea is to seed the thought of moving applications towards an SAP landscape when the overall activities define the same.

– How many legacy/custom built applications exist in the landscape today? How many were acquired because of M&A?

– How many 3rd party applications are in the landscape today? Who are the vendors for the same? What is the vendor strategy around the same?

– Has an A,B,C classification of these applications been done to determine the expected life of these applications?

– What are the parameters of defining and classifying these applications?

– Which is the platform of tilt with these applications that fall in your “A” category of applications?

– What are the gaps in the core R/3 that warrant these applications to exist?

– What is the openness around migrating these applications into the core build approach of SAP and retired?

– Which are the applications that can be mapped onto different SAP applications in the landscape and be brought together through common processes/best practices?

Step #4: Identify your TCO reduction through the ESA Model:

In this step, one would typically determine the doing away of certain non-SAP components to bring in ESA when and where it makes sense. An example could be the removal of an interface for valid account combinations that take place by importing into a legacy application today that can be taken out with ESA.

– If a third party middleware pulls in data from SAP that is used for validation within the non-SAP application, why not contemplate ESA?

– If the dependence is heavy on ABAP Workflow and the application thrives on pre-defined approval rules, is there an Openness for another option?

– If the application relies on Integrations with other applications as well, and warrants the use of middleware to pull in the data for validations internally, why not consider the ESA route?

– What are the roles that access this application? Which other A,B,C applications are using this sub-set of roles?

– What is the planned direction towards upgrades? Core and surrounding?

Step #5: Define the Concept:

Many of the ESA Architects I come across have the nasty habit of having the solution ready before the problem and its magnitude is fully understood and assessed. Not every solution that is technically sound would carry a business buy-in. For the same, it is absolutely essential to lay down the big-picture before coming to the actual solution.

– What is the end objective with the A,B, and C class applications?

– Where do the points of convergence within the value chain come in?

– Which are the same roles that run across multiple applications?

– How can applications be merged and be made to address a business process?

– How is the development of the solution that is being planned today going to address the overall scenario?

– How does this reduce TCO and how does one show the dollar equivalents of the same?

Step #6: Define the Process:

Now comes the actual work of designing the application. This should first lay down the process that is in existence or the needed one. Keep the components aside, ensure that the process is mapped first. Rest will follow.

– What does the overall process flow look like?

– What does the detailed process flow look like?

– What are the roles that execute each action in the block diagram?

– What do the decision trees dictate as the end result?

– Has the process/sub-process been mapped to a level of detail that it can be modeled as an application?

– Is it good practice? What should/could be changed?

– Does it have interactions outside the Organization?

– Are the execution steps approved by Quality?

Step #7: Define the Architectural Components:

Now that the process diagram is there asking to be modeled into an application, the next step is to map the application components onto it. Do it on paper first.

– Figure out the components which can be used straight up without any additional effort

– See what can and should be handled in R/3 without customization and how to separate out the business process layer that needs to be built

– Are the tools stable enough and out of ramp-up to be used for a live case?

– How does the user access and reporting match up to create reusable components?

– what should be the information flow and where all does ESA make sense?

– How do you get rid of unnecessary interfaces that are built solely for validations that can be leveraged via services to be called within the application?

– If you are planning to suggest alternate applications in favor of existing ones, does it justify the business need?

Step #8: Define the Features:

The devil is in the details. This is the activity in which the ESA Architect must cover the must-haves along with the bells and whistles. what needs to be built as core should be built now, what doesn’t, needs to go into a parking lot.

– Have the broad level of features been laid down as functions?

– Have the features within each function been covered? Forget the timelines for now

– Is the business need mapped down in terms of functions to ensure logical execution?

– What are the features that require R/3 customization to ensure it works? How big is this list?

– What would be the impact of a certain feature on performance?

– What would be the impact of a certain function be on the security front?

– How much maintenance would a function warrant? What is the base minimum requirement for the same?

Step #9: Define Areas for ESA:

Now comes the part of proving ESA and being prudent about it. It is very important to identify only those areas for ESA that you know would make sense and not have them do anything that would remotely have a bearing on Performance. This is the proof point for the entire landscape.

– Which are the interfaces that can be done away with that import data and validate a value?

– Which are the services from an external agency that can be used to ensure that ESA adds value?

– Which are the bunch of services that could be defined to rid the landscape of problematic areas within the existing landscape?

– Which are the highly visible, low processing areas within the flow of the application that could be built/reused to bring about a proof point?

– Which are the areas where ESA does not make sense? Highlight these.

Step #10: Define ESA Model:

This is the step where you merge all the components and the identified services and superimpose on top of the business solution and see how it can fit in with CAF. The UI design with Visual Composer, the usage of web dynpros, the drive at a later stage (of not now) with analytics, and the monitoring mechanism within WAS.

– 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?

Step #n: Repeat the model toward ESA Roadmap:

This is to ensure that the model that you lay down today with one application would be reusable across the landscape as what the classification you started with. Roughly put, the steps to create a composite application:

Step 1: Identify the custom R/3 objects to be made along with services from external agencies to be called as external Services within the composite

Step 2: Identify the major roles involved, maintain at the portal level with R/3 as the source of truth to see what can be reused already available or what can be created to reuse. Subsequently decide on the standard business content available for reporting, if any.

Step 3: Identify the major Processes in CAF parlance.

Step 4: Identify the blocks as defined within CAF.

Step 5: Identify the actions for the blocks that will help you set up the guided procedures and rule execution.

Step 6: Categorize the type of Callable Objects as Custom Web Dynpro or existing Callable object type within CAF.

Step 7: Identify the Entity Services that would be required.

Step 8: Identify the External Services that you did in Step 1 to be called and measure its performance.

Step 9: Identify the Application Service based on the block and the callable objects it has to see that you created a sound architecture for the A.B and C type applications to be used by.

Step 11: identify the Interfaces to be done away with.

Step 10: Integrate with Portal with custom webdynpro screens to bring about similarity to existing application look and feel

B: The conversion of varous types of application:

I will cover this in my next blog.

Conclusion:

These are the steps which I found useful in terms of engaging in meaningful discussions with the customers as part of the ESA Workshop in formulating solutions. No doubt, there could be better approaches, but I have seen these trigger off discussions towards forming a solution. In the end, this is only one sub-set of what one could do when the interest is on composites, the other aspects of the workshop certainly trigger off other thoughts that may render some of the statements above incorrect. But as a BPX or an ESA Architect, that is a situational turn one has to take to keep tje interest levels high. And CAF helps do just that.