As the Web expands and services take hold, your business processes have the potential to extend further across your system landscape than ever before. So how do you get a handle on the architecture as it expands to support new and extended business processes?
Technology Transforms Architecture
The number of functional products and possibilities for your SAP systems is growing. As of this writing, there are 470 possible published SAP scenario and process components according to SAP Service Marketplace’s Scenario and Process Component list, which identifies the application components needed to realize a business scenario or process. The reality now is that SAP NetWeaver-based solutions come easy, but the enterprise architecture becomes the challenge.
Every process, function, or extension you add to SAP systems can considerably affect application architecture. Consider expanding procurement needs: Add supplier self-services, and you change your architecture. Add new components — such as SAP Supplier Relationship Management, SAP NetWeaver Master Data Management, and SAP NetWeaver Portal — and you change your information architecture at the vendor and material master level.
What’s more, your technical architecture requires new infrastructure and tools, such as SAP NetWeaver Developer Studio, and programming standards like Java. With all this afoot, how do you appropriately manage and plan for process change within your architecture?
Follow a Disciplined Approach
In my practice, I have been advising clients to embrace Enterprise Architecture Framework (EAF) — not only to document and rationalize their underlying architecture, but as a catalyst to more strategically define and standardize business process planning and delivery.
EAF has been a long-standing discipline within the technical community, and many frameworks exist, such as Zachman, Integrated Architecture Framework (IAF), The Open Group Architecture Framework (TOGAF), and IBM EA. SAP has announced it will be leveraging TOGAF and will soon publish the methodology within SAP Solution Manager as part of the SAP implementation roadmap.
Simply put, EAF is a layered approach that adheres to a company’s definition of technology standards. For example, it may start with a defined business architecture (e.g., e-sourcing for contractors). This approach is transacted by an application architecture (e.g., SAP Extended Sourcing or SAP Contract Lifecycle Management), which is powered by a technical architecture that includes a database and operating systems (e.g., IBM DB2 on Linux SUSE). Information architecture rounds out the stack and also frames what master and transactional data the solution needs. Breaking down an enterprise business model into the enabling architectures is the purpose — and benefit — of following the EAF approach.
SAP NetWeaver-based application projects need a flexible, scalable, tested, and dependable IT infrastructure. With EAF, the desired end result is to have your own tailored reference architecture — an architecture that accommodates future applications — to simplify the planning and design of applications and provide the enterprise with a defined standard it can follow.
I have designed these architectures for clients based on the degree of standardization (e.g., financial processes) and integration (e.g., new product development processes) they require. Now, each company can both identify and justify the current technology and any changes needed to support new processes.
The Importance of Standards
A standard can be defined as something with a pre-described specification that is measurable, authoritative, and fundamental for good practice. All EAFs need architectural standards that are technology- and product-specific for enterprise SOA. They also need corporate-policy standards that are enterprise-wide and technology independent as they relate to enterprise SOA. The enterprise architecture team is responsible for measuring businesses’ adherence and compliance to company standards.
The technical standards for your organization — the products of your EAF process — provide general policy-level statements that are oriented toward implementation. They also provide an auditable exception process for anything that touches your systems landscape. These sets of rules may specifically mention technologies, methodologies, implementation procedures, and other policy details.
In addition to documenting the current and proposed architecture needed, the EAF concept exists for two other reasons: to carry design responsibility upward in the organization and to ensure the organization exercises design authority throughout any deployment.
Design responsibility lies with the people who control your projects or organization (IT management) and need assurance that the solution will work and that the right architectures are in place. In my experience, most businesses will have both SAP and non-SAP components in their reference architectures, so every enterprise architecture must be capable of handling a multi-vendor approach.
The challenge now is educating organizations and convincing them to embrace EAF and define, migrate to, and govern their reference architectures. In the process, you need to answer questions like: Who will sponsor and deploy this design authority? Who will maintain and govern it? What staffing, skills, and career paths are needed to support it? What tools are needed to define and maintain it? This now becomes the new reality on the road to extended applications and technology-enabled process transformations.
As you define the enterprise architecture, you need to consider technical accountability in two distinct directions:
- The business sponsor and program management, who are focused on delivery goals, are interested in the costs and benefits of acquisition, and are asking the question, “Will it work for me now?”
- The IT strategy team members, who are focused on strategic goals, are interested in the total costs and benefits of ownership, and are asking the question, “Will it work for the enterprise in the longer term?”
Where to Start?
I see the journey to EAF starting within your organization now, with new emphasis on business process definition and organizational support. As a first step, consider plotting your own company on an IT maturity model. This will give you a baseline to gauge your enterprise’s starting point and a first step on the path toward rationalizing your technical landscape and ensuring the flexibility required for future expansion.
|Adolf Allesch is the global SAP NetWeaver lead partner at IBM Global Business Services. A pioneer with the Web, he is now the SAP NetWeaver evangelist for IBM. He specializes in technology-enabled business transformation using SAP and is a frequent presenter at SAP events worldwide. You can reach him at firstname.lastname@example.org.