BPR to ESA: Part II Application Architecture
Business-process renovation requires the abstraction of business activities or events, modeled as enterprise services, from the actual functionality of the application. Gathering these functions as Web services into business-level enterprise services supplies more meaningful, less expensive building blocks. As a guide, the renovation equation has gained wide acceptance with customers. In it, a deep understanding of SAP NetWeaver capabilities, plus application architecture, plus holistic governance, equals business-process renovation. The SAP NetWeaver capabilities come from extending SAP modules (e.g., Sales and Distribution --> Customer Relationship Management, Materials Management --> Supplier Relationship Management) and the technology innovation provided by the Internet.
The first movement to renovation occurs when you have mastery of “core + extensions”; the second comes when your business realizes that processes once desktop-centric (due to network and security constraints) can now be focused around the user, thanks to network devices that can connect wherever you are. The final element is the creative use of task management (e.g., alerts, collaboration, ad hoc workflow).
Today, standard business-process modeling is passé. New innovative technologies enable us to renovate, and disruptive technologies like RFID are standard in many supply chains. High-volume events such as vendor-managed inventory, preventive maintenance, and advance-ship notifications will never be the same, due to the data that is broadcast from a $0.30 tag on a package or pallet. Business-process renovation is a reality.
A Natural Migration
Many view application architecture as a technical challenge best left to technology specialists, when in reality it is a natural migration that functional team members and business-process consultants need to master. In yesterday’s client/server SAP R/3 (ERP) world, it was simple to navigate the SAP product suite using pairs of consonants, three vowels, and a “/.” The world as we knew it was called R/3 and was made up of modules such as SAP Materials Management (MM), SAP Sales and Distribution (SD), SAP Financials (FI), and SAP Human Resources (HR), powered by a Basis-driven engine and coded in ABAP. Application architecture was a non-issue due to the level of simplicity. It was primarily a closed world, and integration within the ERP domain was automatic. In most companies the package was contained on a few servers.
Now, application architecture is a serious element in any implementation and garners a larger portion of the budget for planning and operations. As a result, it is the second element in the renovation equation.
In today’s enterprise services architecture (ESA) world, application architecture is not as straightforward as it was yesterday. SAP has moved toward business-process scenarios on the functional side and IT scenarios on the technical side. We’ve had a taste of the compatibility issues in core R/3 with specific industry solutions and the initial introduction of SAP NetWeaver. Each component was on a different release, and installations had dependencies known only by specialists.
Before ESA, we mapped business processes to components and sized servers. In the SAP NetWeaver world, our systems are cross-component-based because new (key) capabilities requiring multiple components have been developed. For example, enterprise reporting no longer just uses SAP Business Information Warehouse (SAP BW). In the renovated world I can have reports delivered to my phone, alerted to me in my universal workflow inbox, broadcast to my portal, or delivered in email messages. Given the changes in renovated business processes, the simple one-to-one mapping of business process to module to server is over.
What can you expect going forward? In addition to the core modules, three new elements have been added to the mix: software components (self-service, catalog content management), system-wide components (SAP Solution Manager, SAP NetWeaver Developer Studio), and standalone engines (liveCache, TREX). SAP commonly illustrates SAP NetWeaver components in a diagram reminiscent of food boxes neatly stacked in a refrigerator — hence, the term “refrigerator diagram.” Now, in full-blown ESA (SAP NetWeaver 2004s or ERP Central Component [ECC] 6.0 and beyond), nearly every business-process scenario requires every SAP NetWeaver component, so the diagram is obsolete.
New capabilities and tools (plug-ins, adapters, SAP NetWeaver Visual Composer, SAP Systems Landscape Directory) that defy direct mapping within the diagram are being introduced. These components become the building blocks (think Lego blocks) that define your application architecture. In true ESA fashion, you can now “have it your way.” But to get the application architecture you want, you need strong business and technical vision to define business scenarios. The potential combinations are endless.
To simplify this task, the term “usage types” has surfaced. Think of them as groupings of common Lego blocks you can build upon. Definition and understanding are critical because you can expect all SAP documentation (implementation guides, master guides, release notes) and support to be defined by usage types and categorized around IT scenarios.
Let’s look at the enterprise reporting example above to understand why this is happening. When you take all the components of SAP NetWeaver and the capabilities of the Web and SAP module extensions, you find that renovation techniques span the entire spectrum. Business and IT need to collaborate to create this solution. Broadcasting is a common technique for pushing reports to users and can now be applied to reports. In designing the process, questions may include: What information (query, workbook, report)? What format (.pdf, .xls, .doc)? Who to broadcast to (user or role-specific)? What channel (email, workflow inbox, collaboration room)? What timing (event-driven, ad hoc, exception)?
Defining Your Application Architecture
Cross-team collaboration is a must! Numerous combinations of software components, system-wide components, and standalone engines are possible. In defining your application architecture, your choices rival differential calculus. Predefined usage types simplify this challenge. Adding transaction volumes will lead to system-sizing and physical-server definitions, further leading to the real question: “How many servers do I need?”
Your application architects should have the skills of both business-process analysts (those who define the business scenarios and usage) and systems engineers (those who define, size, and determine the technology and potential server farm). It’s no wonder that the Enterprise Architect Community (see “Meet the Enterprise Architects,” SAP NetWeaver Magazine, Spring 2006) is the fastest growing group in ASUG. ESA is an n-tier platform, and your hardware provider will become your new value-added partner.
In the next issue, I’ll discuss the third element of the renovation equation — holistic governance — and examine the approaches for designing and managing renovated business processes.
Adolf Allesch is the vice president of SAP NetWeaver Solutions at Capgemini. A pioneer with the Web and an early adopter of mySAP.com, he is now the SAP NetWeaver evangelist at Capgemini. He specializes in technology-enabled business transformation using SAP and is a frequent presenter at SAP events worldwide. You may contact him at firstname.lastname@example.org.