Semantic Integration is key:
The total spend of Org.A’s IT bugdet on maintenance and support of existing systems accounts for close to 80% of their annual budget. This leaves no room for esoteric or sublime applications being conceptualized by some with the advent of CAF. The opportunity with CAF is for IT departments to get real and not get swayed by the hype and hoopla. xApps hold a lot of promise – as long as the idea is right. I completely agree with the statement made by Gunther Piller @ TechEd ’05, “Value chains are being modularized across industries and recomposition is taking place – companies focus on their core competence and focus on more and more partners.” The time to execute a business process is less but the time to change a business process is still fairly large. What is needed is an architecture that enables organizations to adapt to new processes in a shorter time span. Enterprise services and process components will need to be knot together to provide a semantic integration. These sub-processes which change very frequently over a period of time and needs to be custom built to an organization’s requirement is what needs to be driven by the reusability concept. When business process changes, all it should need would be recomposition and re-orchestration. This concept of CAF should help customers support flexibilty for new processes, which it does. As mySAP ERP itself can be looked upon as a composite now, the white spaces are being opened up to the partner ecosystem to build composites to drive new business processes with the existing landscape in a customer site. Therefore, Org.A, looks at its value chain and finds one candidate application satisfying a strategic, yet not mission critical area, that of indirect procurement to be the candidate for its initiatives with ESA. The target is to do away with Ariba Buyer 7.x application, along with the need of its underlying TIBCO EAI and to do away with the need of an upgrade to Ariba Buyer 8.x. This also means doing away with the usage of the Ariba Supplier Network, Ariba Sourcing in the future and other applications as part of the Ariba Spend Management Suite.
This also means that Org.A is planning to do away with its on-going discussions around mySAP SRM/EBP and the usage of the newly founded SSN (SAP Supplier NetWork with cchubwoo and Perfect Commerce). For Org.A, the comparison long ended between Ariba Buyer and Commerce One (Ariba vrs. EBP), Ariba Commerce Services NetWork and its usage for SRM (ASN vrs. SSN now), the lookout for the perfect Cataloguing tool (Requisite vrs. BugsEye vrs. MDM vrs CCM vrs…..so on and so forth). The decision is not to go after a best-of-breed application chaser from SAP, rather, to build a composite around the same that forms part of the overall IT strategy and aligns with the ESA roadmap that Org.A has with SAP NetWeaver. The business need is reduce costs by 3/4th and have a barebones application that performs the operational aspects of the procurement cycle instead of being overly strategic about the matter through applications. Given the current commotion around catalog tools within SAP today, Org.A decides to move forward with MDM 5.5 as part of an overall catalog strategy internally. Whether SAP follows the same agenda or not – would not be of great significance to Org.A later addressing the buy-side and probably, taking on the sell-side with CRM in the future, again as a composite extending xPRO. Still, perfectly in harmony with SAP’s vision.
Why should Org.A be driven by Architecture to consider xPRO as a composite?
The focus is being built on user-centric and collaborative processes based on roles that needs to be adopted. Like purchasing, finance, marketing, projects and receiving. Changes in market conditions would be addressed by this approach by providing a rich user experience unlike the R/3 of the past. This componentization of sub-processes still being held by boundaries of silo applications, yet addressing a seamless semantic integration of business processes. A task driven approach that clearly defines ownership of processes is to be built on xPRO. Speed, Cost and Value, of course become drivers for this new paradigm of application development. Composites are based on services from the underlying systems through loose coupling with xPRO being built on top to drive speed of changing processes within xPRO that defines faster time-to-market. The aim is to do away with best-of-breed applications in the e-procurement space from an operational standpoint. Currently being built only on services to ensure a semantic integration of information from across applications in the existing landscape that is driven by a consistent object model and business language that would be customized to an organization’s need undefined in the back-end application systems. Such different composite business process objects that would need to be built and knit semantically will lead to a process integration built on application logic that shields the top process layer from operational details to keep them constant. The action layer should be defined to keep the business user agnostic of the technical details to orchestrate these processes. Of course, a step in the business process could go directly to a back-end system to call services from there without having to build in a additional business logic layer – primarily to support existing applications. So, there could be two ways to build xPRO. The goal is to provide maximum flexibility and so the option that is being driven is the first one – that does not call application services directly from underlying back-end systems.
xPRO Technical build approach with CAF 7.0:
Additional services can be composed in the CAF layer and orchestrated through guided procedures in the CAF layer. A rich intuitive user interface to create collaborative and dynamic workspaces that bring together multiple functional areas. This creates the base xPRO application or – a base process framework that can now be enhanced and customized to accommodate organization-specific customizations or enhancements seamlessly. The UI layer driven by UI patterns to align with the overall SAP AG agenda provides additional conformance to the SAP NetWeaver initiatives within Org.A towards ESA. Definitely, CAF is not a new concept, it is the information percolation across the customer and SI community that seems to be happening now – with the SAP NetWeaver landscape more of less being accepted by organizations across the globe.
The UI layer of xPRO would cater to the Import of external services like RFCs or Web Services at design or configuration time and use EJB proxies for external services if needed to be called. Mapping of external services to entity and application services for Composition of application services using entity and external services being programmed to define the xPRO application logic at the CAF layer towards composition. Concepts of application, entity and external services become the driving factors in building a composite application. Integration with KMC and TREX, and integrated with BI using entity and application services would leave the BI initiatives intact to only further the functionality of xPRO in the future. Following standard WebDynpro patterns and controls, it should lead the path for a unified user interface elements with a rich user experience that could find easy adoption and support of the business users driven by UI consistency across applications and take on direct competition with a best-of-breed application while doing a feature-by-feature comparison. The same approach would be the baseline for xPRO. Document management and TREX features in composite applications like xPRO would become mandatory similar to the composite applications across the board driving reusability in terms of standard services from SAP. This drives the agility for Org.A to extend business objects through custom fields being introduced in xPRO as part of custom adoption and what would just be required is the mapping to the back-end application systems. This is the concept that xPRO needs to leverage to drive the new concept of application definitions as an open platform to program additional logic. Since the user interface needs to leverage only meta-data, changes to the same would become a lot easier. The persistency, CRUD operations, queries along with authorizations, exception handling with the help of the CAS perspective in the IDE would make the build of xPRO a logical one driven by frameworks.
Service Orchestration in a process by modeling, executing and managing them by managing user centric processes across multiple backend systems for invoking various types of applications and services, e.g. WebDynpro, RFCs, R/3 transactions, BEx queries, and ADS if need be to embed application service functionality as the background steps to enable ease of use for process definitions by a business user. Mapping of parameters between process steps would drive the semantic integration of process steps with the GPs rendering the ability to map the input and output processes to persistency from one step as an input to the next step of the procurement operations based on roles. For example, browsing catalogs and selecting an item would trigger form the input of creating of a purchase requisition for the selected item within the PR Webdynpro. Driven by process monitoring across activities as a whole – as driven in Ariba Buyer – One would certainly feel the need to pass on the credit to them to spawn the entire GP concept. Defining the same in CAf would be a challenge. Ad-hoc initiation of optional steps during each process execution for capturing additional information as needed based on “B-Forms” for ad-hoc items would provide for an almost code-free modification of process flows using reusable process components within xPRO.
Enter CAF 7.0 for ready-to-use run-time framework with configurable user interface and a gallery with custom specific, re-usable process components for phases and steps. xPRO specific process parameters and role consolidation at configuration time would need to render predefined implementations like data input & display, approval rules and status, activity monitoring, email notifications, so on and so forth. The mapping of the same to the defined process steps would form the core set of guidelines for development of xPRO. By attaching callable objects to actions being called from a block as a part of the Guided procedures for process, the orchestration of the actions by a business process expert to define the flow based on semantic flow agnostic of the underlying technical implementation of these objects. These callable objects would call the services as required by the processes as a web dynpro or a web page or an R/3 transaction as the casr may be. Once the process flow within xPRo is done, the consolidation of activities based on roles will give birth to the business packages that would drive demarcation of process responsibilities. The drive with EFP for xPRO needs to have light-weight components, that would mean the exclusion of web dynpros and business packages today till SAP comes up with support for the same for EFP for suppliers and external partners be included as part of the process.
Then, with all the processes built on as part of mySAP ERP, the world of composites open to the partner ecosystem would be totally niche, bordering on esoteric, or the defined “white-spaces” as a non-value-added effort for SAP. This opportunity can be converted by customers to define composites that find a place with their legacy application replacement, instead of looking at a host of best-of-breed applications under the garb of SAP NetWeaver. Or a wolf in sheep’s clothing, as one would call it in the Architect’s world.