GRC
HR
SCM
CRM
BI


Article

 

Building an Agile Enterprise Architecture

by Sven Feurer

August 11, 2009

Your enterprise architecture is your plan for how to build IT for your enterprise. It focuses mainly on the quality of a company’s products, services, and business processes, and on how agile the business is in implementing changing business, IT, and organizational strategies. Learn the frameworks and layers involved in implementing an enterprise architecture.
 

What is an enterprise architecture? It is the plan for how to build IT for an enterprise. It focuses mainly on the quality of a company’s products, services, and business processes, and on the agility of the enterprise in implementing changing business, IT, and organizational strategies.

Enterprise architecture does not exist in a vacuum. As a strategic planning discipline, it is a powerful foundation on which to align technology and IT strategies, achieve real synergies, and maximize business value. Although each company’s enterprise architecture will be unique, certain underlying concepts are common to most.

The Foundation for Execution

The purpose of enterprise architecture has evolved because of the strong effects of globalization and increasingly complex and elaborate business processes. Globally interconnected systems make new forms of collaboration possible among employees, teams, and organizations: for example, ecosystems composed of customers, partners, suppliers, and other interest groups or stakeholders. Customers increase their bargaining power in such an ecosystem. For one thing, they can compare the offerings of international companies easily and pick the products or services most favorable to them. Companies in virtually every industry have recognized this power shift and become more demand-driven. They have adjusted their business processes to focus on their customers’ requirements, achieving high, sustainable, customer satisfaction — a major goal.

Enterprise architecture enables an organization to achieve and sustain its strategic goals. For example, if you imagine enterprise architecture to be comparable to city planning, you create a new “building” that works harmoniously with existing structures and provide for its impact on traffic, electricity, and so on. Enterprise architecture provides the foundation for business execution by ensuring that all the money spent in information, technology, and process improvement leads to new opportunities and rapid responses in an ever-changing market. Therefore, an enterprise architecture presents a process that describes the steps, standards, and guidelines to get to the desired future state.

Using an EAF as a Master Plan

A rigorously defined enterprise architecture framework (EAF) provides the structure on which to organize your business’s technology. It helps you to understand the future architecture, clearly identifies the state of the current architecture, and provides a way to close the gap between the two. Implementing enterprise architecture can be complex, so the framework must align different aspects of it from various points of view, such as the business, application, data, and technology.

You can also consider the framework to be a master plan for coordinating and aligning strategic enterprise-planning activities, business operations, and the technological infrastructure. Such integrative efforts need strong governance principles to avoid contention among the services of different business units (BUs). Today’s EAFs fall into four major categories:

  • Government frameworks: Public agencies develop and use government frameworks primarily in the defense arena, where multinational military operations require standard architectural approaches. A prescribed plan helps agencies develop a documented, harmonized architecture to deal with complex integration challenges.

  • Authoritative frameworks: Frameworks such as The Open Group Architecture Framework (TOGAF) and Zachman are authoritative and elaborate. Both provide highly structured ways of defining an enterprise by illuminating the complete dimensions and depth of enterprise operation and development. Many other frameworks are built as specific refinements and add-ons to these.

  • Vendor frameworks: Software vendors and consulting firms are the primary developers of these frameworks. They provide experience and best practices, obtained from past architectural projects, in the form of frameworks. These frameworks are sometimes more suitable and applicable for particular companies and industries: for instance, SAP Enterprise Architecture Framework (SAP EAF) is described briefly in “Apply the SAP EAF for Enterprise SOA,” below.


    Apply the SAP EAF for Enterprise SOA

    The SAP EAF is an open, standards-based architecture framework. It is an extension of TOGAF designed to support the effective adoption of packages and packaged-services solutions. SAP EAF provides detailed guidance and checklists showing how to integrate the framework within an organization’s existing processes and to accurately scope architecture engagements. It identifies the stakeholders and their typical architectural interest and provides techniques for tailoring the output to the stakeholders’ needs. SAP EAF also focuses on the definition and governance of IT solutions and performance measures that are traceable back to the business’s needs. Today, pilot activities around SAP EAF have been completed successfully, and projects are up and running with SAP customers. SAP Education classes for SAP EAF are also available.

  • Miscellaneous frameworks: These frameworks focus on special industries, such as the National Institutes of Health (NIH) framework (shown in the table “Enterprise Architecture Frameworks,” below), or provide other features and functions.


    Enterprise Architecture Frameworks
    Category Known as Description
    Government frameworks DoDAF (U.S. Department of Defense Architecture Framework) Developed by the U.S. Department of Defense, DoDAF focuses primarily on the architecture of military systems, but public, private, and voluntary sectors also use it.
    MoDAF (U.K. Ministry of Defence Architecture Framework) Created by the U.K. Ministry of Defence, MoDAF has an integrated and coherent approach to acquire, manage, and operate military capabilities.
    Authoritative frameworks TOGAF (The Open Group Architecture Framework) As an increasingly popular framework, TOGAF provides robust advice on architecture governance and is well aligned with contemporary enterprise architecture concepts.
    Zachman (Zachman‘s Framework for Information Systems Architecture) Zachman is one of the frameworks richest in generic detail.
    Gartner EAF (Gartner Enterprise Architecture Framework) Gartner EAF explicitly derives architecture from business strategy and supports governance within both the framework and the process.
    Vendor frameworks E2AF (Extended Enterprise Architecture Framework) Created by the Institute for Enterprise Architecture Development, E2AF was influenced by several other frameworks (e.g., the Zachman framework).
    SAP EAF (SAP Enterprise Architecture Framework) SAP EAF is an extension of TOGAF designed to support the effective adoption of packaged solutions in a service-oriented enterprise.
    Miscellaneous frameworks NIH Framework (National Institutes of Health Enterprise Architecture Framework) NIH Framework supports the mission and goals of IT and the NIH.
    Others Various other frameworks exist.

In a survey that the author conducted in February, TOGAF, Zachman, and Gartner were found to be the most common EAFs among companies from the consumer products, high tech, retail, and chemical industries. Companies may need to adapt and reassess their frameworks from time to time to remain in sync with changing architectural requirements.

Groups, vendors, and governments responsible for EAFs typically provide downloadable, updated documentation. However, you may need specific add-ons that a particular framework doesn’t provide, such as a scorecard add-on that allows the definition of performance networks or a reporting services add-on that creates custom reports. You may need to evaluate several frameworks and combine different approaches. For example, SAP EAF extends TOGAF and is well structured and well defined.

Define Enterprise Architecture Building Blocks

Every enterprise is different, so a one-size-fits-all approach to enterprise architecture doesn’t really exist. The model in “Enterprise Architecture Viewpoints,” below, shows a general approach and identifies four fundamental viewpoints:

You can approach enterprise architecture from four different viewpoints: business, application, data, and technology. The solution viewpoint is typically the final outcome of loosely coupled architectural descriptions.

1] Business: The business architecture deals with the enterprise in its business environment. It epitomizes the business architect’s process and organizational concerns. It is the dominant architectural discipline because it aligns business processes with the company’s overall objectives and uses various metrics to measure them. You can even use the business architecture as a management tool to improve enterprise performance. It shows the business value of the other architectures.

The business architecture receives its initial input from wider enterprise-planning activities, which define the business’s mission, vision, strategy, and goals. Then, it must translate these high-level business goals into relevant business requirements.

Analyzing enterprise architecture from a business perspective is complex. A comprehensive approach defines end-to-end business processes — including “core processes” — and their relationships to an organization’s internal and external users. Furthermore, the business architecture creates an architectural blueprint that meets or exceeds the customer’s requirements, competing and sustainably operating in the market, as well as interacting with suppliers, partners, and employees.

Core processes are customer-centric and could span multiple functional departments. They should deliver effective and efficient results in functional organizations. You can evaluate their performance by linking them to the previously defined, measurable results of a long-term business goal.

Defining a business architecture raises the question of how well it relates to business-process management (BPM). In the end, business architecture creates optimized business-process models aligned with business strategy. Currently, BPM uses these models, tries to automate them, and creates end-to-end business processes. In the future, business architecture and BPM are expected to converge.

2] Application: The application architecture represents the set of application components that together form deployable systems and is typically specified as business requirements. It considers the interaction between application packages, databases, and middleware components in terms of functional coverage. Application architecture also identifies integration efforts and is often a predecessor to data architecture. That said, the application architecture domain maps the business services and business functions defined in the business-architecture phase onto a set of application components, which create the link between the business service and data and the technology components. They are, therefore, critical to a package or packaged-services environment acting as the keystone between business requirements and technology implementation.

3] Information/data: The information architecture provides an effective use of data, both logical and physical, to best manage the information structure, assets, and flow. Information is the fundamental driver for successfully operating a business. This viewpoint represents the data that enables an organization to comprehend the scope, scale, and interdependency of the information it collects and maintains. It helps the organization understand how it uses its data, and enables the enhancement and governance of data as a strategic asset.

Businesses need accurate and timely data to determine profitability and efficiency, monitor quality, manage people, and communicate with suppliers, customers, and business partners. It is valuable in decision-making at operational, tactical, and strategic levels.

Dr. Peter F. Drucker, writer and business guru, stated: “Information is data endowed with relevance and purpose.” In any business, information comes from both structured and unstructured data — the fundamental “bricks” of information architecture. Structured data is typically stored in tables, consisting of multiple entries characterized by various criteria. You need to interpret these entries to make sense of them. Structured data includes business data and metadata (information about business data). It is often stored in databases, spreadsheets, and word-processing tables.

Compared to structured data, unstructured data is difficult to interpret. It is mostly in word-processing documents, presentations, and similar incoherent documents (image, audio, and video formats). To understand unstructured data you need to know its context. Therefore, metadata is describing the context of the data that is essential.

4] Technology: The technology architecture specifies the technological elements: the network, hardware, and software of the basic infrastructure. It depicts the application components within the infrastructure as a set of technology components available on the market or configured into technology platforms within the organization. In a package-centric or packaged-services-centric environment, the majority of technology components are commercial, off-the-shelf products available as a suite of services and products residing on a unified technology platform.

As the technology defines the physical fulfillment of the architectural solution, it has strong links to implementation- and migration-planning. This viewpoint defines current and future state views of the technology portfolio, detailing a roadmap toward the future state architecture, and identifying key work packages. It completes the architectural information and supports cost-assessment for particular migration scenarios.

Translate Strategy by Abstraction

You can describe each viewpoint in three informal abstraction layers to divide it’s conceptual design into a detailed, implementation plan (see “Abstraction Layers Within Each Viewpoint,” below):

The abstraction layers for all four viewpoints are identical in type, but the individual data within each is specific to that viewpoint.
  • Conceptual: Executives made the strategic decisions that senior managers must now conceptualize. Senior managers have the “big picture” in mind. They ensure that the enterprise architecture reflects the organization’s long-term business plans and addresses its issues and opportunities. For example, from a business perspective, executives want a specific, seamlessly integrated, order-to-cash process — from order entry to fulfillment to collections.

  • Logical: Operational management has a logical view of enterprise architecture. Here, senior managers consider the conceptual requirements and create a business-process model that reflects them. Therefore, senior managers must understand the business logic included in the steps of the process.

  • Implementation: Change agents need to be able to go into detail when they are implementing systems and improving processes. This layer forms the scope of projects about standards, guidelines, and specifications. For example, the business logic might differ, depending on whether the company is building or adapting workflows, enterprise services, or business-process rules.

Abstractions help to effectively communicate layer-specific issues to different stakeholders such as corporate, business, or IT management. You can describe each abstraction layer in each of the viewpoints as architectural requirements, principles, and models, although the actual information will vary.

Deliver Value with Solution Architecture

Although business has special demands, such as real-time enterprise transactions, BPM, and BI, IT has appropriate solutions such as enterprise service-oriented architecture (enterprise SOA) and model-driven architecture. Solution architecture describes the combination and unification of all loosely coupled — and often contradictory — enterprise viewpoints: business, application, data, and technology architectures. Solution architecture is a meta-architecture because it combines the others, creating an aggregate for a specific enterprise solution. It helps to structure solutions that deliver value, use the appropriate systems, and identify risks and complexity. Many EAFs either don’t have this solution viewpoint or implement it insufficiently.

This viewpoint (see “The Enterprise Solution Viewpoint” below) combines loosely coupled architectural descriptions to provide a unified, holistic, and non-conflicting foundation for creating enterprise solutions. Typically, these solutions are the final outcome of your architectural efforts. The more agile and mature this architecture is, the more quickly you can develop enterprise solutions in an efficient, qualitative way. A holistic view of solution architecture enables you to build a complete set of architectural descriptions to form an enterprise solution portfolio.

The enterprise solution architecture incorporates all the viewpoints and abstraction layers.

The results of an enterprise solution architecture are called “enterprise solutions,” or “business solutions.” However, the application architecture designs and engineers the applications and builds the technical and logical back-end that reconcile all architectural viewpoints. For example:

  • SAP ERP is an enterprise application that describes the software that handles business processes and information.

  • SAP ERP Financials, SAP ERP Human Capital Management, and so on are comprehensive enterprise solutions that primarily aim to solve business problems. They typically smooth over information flows, automate business processes, and involve people when human intervention is necessary.

Traditionally, the boundaries of enterprise applications have been closed and highly inflexible. Enterprise solutions were either developed by internal company groups or bought from external software vendors. These solutions work fine as long as the requirements remain constant and you don’t need to expand or adapt anything. They tend to focus on set user groups that use predefined user interfaces (UIs).

Inflexible enterprise applications make it impossible to create or change enterprise solutions efficiently. Some developers have tried to consolidate expensive custom code into cost-effective standard applications, but differing technology platforms have made it a difficult task while using packaged applications.

Service-Based Solution Architecture

Enterprise applications need to be more open and standardized to create an interoperable solution architecture. This is where service-enabled, packaged applications come in and expose business functionality in the form of reusable, modular components — the enterprise services — which are based on open standards.

In addition to buying applications and building or changing your own custom applications, compiling composite applications represents a third alternative for creating flexible, customer-specific solutions at an affordable cost.

Over time, a core of standardized services will become available, and new services will appear on the market. Companies may directly use these services or extend them in ways that differentiate the companies from their competitors.

These new solutions may consume not only the functionality exposed by service-enabled, packaged applications, but also the functionality that custom-developed applications provide. It’s important to have a robust solution life cycle so you can effectively resolve business demands and transform your solution landscape as a whole.

Service-based enterprise applications allow you to have end-to-end business processes that span multiple silos. This represents a new era of interoperability not only within the IT department, but also in the business.

Sven Feurer is an SAP NetWeaver industry advisor at SAP Deutschland AG & Co. KG. This article was taken, in part, from Feurer’s Diploma Thesis in Business Information Systems at the University of Applied Science, Karlsrühe, Germany. You can reach him at sven.feurer@sap.com.

 

An email has been sent to:






More from SAPinsider



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!


SAPinsider
FAQ