A Streamlined Enterprise Architecture for BPM and SOA
Every industry creates plans to address new markets, customers, or products. Similarly, such a business plan is required for an IT-enabled industry to identify potential evolutions and targeted domain boundaries. Such planning is essential to define which of the components will be tightly coupled as well as where and to what extent flexibility is necessary.
Merging the business strategy, implementation, information, and infrastructure aspects in a single enterprise architecture map is a common pitfall. Good architecture involves separation of concerns. Wikipedia provides a good definition of enterprise architecture that clearly separates the concerns:
- The architecture process addresses documenting and understanding the discrete enterprise structural components, typically within the following four categories: Business, Applications, Information, and Technology.1
In a dynamic enterprise approach using BPM and SOA, each domain requires a specific mapping and domain decomposition leading to a four-layer view of the enterprise with a simple mean to remember them.
There are recognized enterprise architecture frameworks or metamodels in the industry, such as The Open Group Architecture Framework (TOGAF)2 and the Zachman Framework.3 TOGAF is a method that addresses reification of the enterprise architecture (A to H) and the "why" (requirements), but does not separate as clearly as the Zachman Framework the "what," "how," "where," "who," and "when." The business information domain is covered by the "what," the business logic and functions performed are described by the "how," the various locations and topologies where the enterprise performs business are analyzed in the "where," the enterprise organization and the various actors are formalized in the "who," the events and dynamics of the business flows are modeled in the "when," and finally, the enterprise goals and requirement are captured in the "why."
However, a fully fledged enterprise architecture with an exhaustive approach for each of the preceding layers is perceived as a costly and lengthy process that does not always provide quick wins and pragmatic results. Applying these methods and frameworks to their full extent for an enterprise can be important; however, in a dynamic BPM and SOA approach, we need to apply a streamlined approach that is affordable and still has the necessary architectural models and work products.
The four domains—Business, Applications, Information, and Technology—are particularly important to an SOA and BPM approach as business processes consume business services exposed from applications or other business process modules. These business services apply functions on core business entities and information that allow their flexible integration at the enterprise level. The applications also consume technical services from the infrastructure layer. Technical services refer to services that do not pertain to a particular business domain but are common technical functions made available by the IT to the application layer. Examples of these technical services are "send eMail," "audit interaction," and so on. Each of these four domains has policies that define the rules and regulations that apply to a particular domain.
Figure 1-1 shows these four domain layers creating a mnemonic structure (a capital "E"). The top layer addresses business, the middle layer the applications (including the service components that they package), the bottom layer the infrastructure, and all are connected vertically by information, or in other words, the business logic.
Figure 1-1 Mnemonic for the "E"nterprise architecture layers
In Chapter 2, "Streamlining the Enterprise Architecture for Dynamic BPM and SOA," we address techniques to achieve an efficient approach including horizon based enterprise architecture, enterprise architecture staged zooming, and accelerated implementations using template business and technical architectures.
But first, let's take a high-level view of the four enterprise architecture layers by looking at the business aspects.
Mapping the Enterprise Business
The use of an enterprise map in a dynamic BPM approach allows you to identify the boundaries of process modules that will have value for the enterprise. The detailed practice is discussed in subsequent chapters of this book. In this chapter, we look at bridging the enterprise architecture with this business modularization.
It is essential to identify the business components that deliver business capabilities and act as service centers in the enterprise that have the potential to operate independently. These components deliver value to the enterprise through their ability to deliver a unique set of business capabilities.
The need to operate independently necessitates that a business component be at the intersection of several axes, which could potentially include
- A business area or a decomposition of a business area
- An organizational structure operating within a business area
- An accountability level
- Business life cycle phases
Based on these different views, there are several approaches for defining a business map, the business components, and the business model. However, they all provide a decomposition of the business of an enterprise. A business process map is the static landscape on which business processes and business events provide dynamic behavior. A few standards are available, and in the next sections, we walk through some public examples of such enterprise maps and decompositions.
NGOSS Business Process Framework (eTOM)4
The enhanced Telecom Operations Map (eTOM) from the New Generation Operations Systems and Software (NGOSS) standard provides a business process functional decomposition framework for telecommunication service providers and serves as a neutral reference point and blueprint for decomposing processes to a level 3 of a functional decomposition tree. In Figure 1-2, you have a first level of decomposition with the verticals such as Fulfillment and an orthogonal first level of decomposition, Customer Relationship Management. At their intersection, there will be further decomposition in level 2 process catalogs such as Order Handling, which itself contains a further decomposition into a level 3 modularization.
Figure 1-2 The Enhanced Telecom Operations Map (eTOM)
This top-level map is complemented with a level 3 functional decomposition in the 300+ paged GB921D document, "The Business Process Framework (eTOM)."
Even though the standard says in business process decomposition no workflows are standardized, only a static functional decomposition of the business operations is provided. This is a good starting point, but the telecommunications business is highly dynamic, and static workflows are necessary for the modularization but insufficient for real business operations.
APQC Process Classification Framework5
The APQC (American Productivity and Quality Center, although now worldwide) is a standards body developed a classification of enterprise most common processes and captured that classification as a common language and open standard.
Particularly the classification looks at decomposition of the enterprise into finer grained elements and creating a tree of four levels, where each level addresses a particular semantic of the enterprise business (see Figure 1-3).
Figure 1-3 The PCF organizes processes into 12 enterprise-level categories.
The Process Classification Framework (PCF) includes process groups and more than 1,500 processes and associated activities down to a level 4 of decomposition.
An essential aspect of the PCF is that it provides a standard for naming the different levels, which interestingly enough can be matched with the three eTOM levels. Similarly, even though the level 4 activities are usually sequential, there is no workflow standardization in the PCF.
These four levels are
- Categories—Classifying business competency domains of the enterprise
- Process Group—Grouping processes in business components that apply to similar business entities
- Process—Formalized list of tasks and activities required to achieve a specific aspect of a business component
- Activity—The granular business definition of an element that is chained by a higher level process.
This classification serves as the basis for further discussions in this book, particularly in the business service granularity discussion.
IBM®'s Component Business Modeling6
This approach from IBM is a new way of looking at an enterprise business. The Component Business Modeling (CBM) methodology identifies the basic building blocks of an enterprise business, as shown in Figure 1-4, to help address the future challenges of the enterprise.
Figure 1-4 CBM map showing basic business building blocks
This map is a mean to identify business components and create a business strategy for the enterprise. These business components have functionality that occurs once within the enterprise, and they act as business service centers that have the potential to operate independently. This enables the replacement of one business component by another implementation. For example, the product fulfillment can be delivered by many factories around the world, but the enterprise expects the same services from all product fulfillment instantiations around the globe. In one country or for one given product, the enterprise can own the factory while in another country, it can be a contractor. However, each business component delivers value to the enterprise through its ability to deliver a unique set of common services per business component function.
The implication is that explicit processes operate within the boundaries of a business component and use other business components' services to chain into the realization of processes that span the enterprise.
The granularity of business components is, however, often too high. In a dynamic process approach, these maps serve as the basis for further functional decomposition, and they can be considered as level 1 and level 2 of the APQC Process Classification Framework.
SCOR—The Supply-Chain Council
The Supply-Chain Council is a nonprofit global independent organization, composed of many companies around the world, which has produced the Supply-Chain Operations Reference (SCOR) model. This model is a process reference model that integrates the best practices for supply-chain operations business process reengineering.
SCOR addresses five distinct business domains called management processes, which are plan, source, make, deliver, and return.
In addition, the Council defines four levels of decomposition but only addresses the first three levels in the standard. The fourth level is the business differentiator of each company.
These four levels are
- Process Type—This level 1 or top level provides a balanced cross business domains and cross process categorization. It defines the scope and content of the previously mentioned management processes.
- Process Category—This level 2 or configuration level provides a reconfigurable level that companies will adjust to their own business plans.
- Process Element—This level 3 or process element level contains the process modules that operate within a business component and can be reconfigured to achieve the higher level processes.
- Activities—This level 4 or implementation level contains the necessary tasks and granular business services. SCOR standard considers this level to be specific to each and every enterprise and does not standardize this level.
Process model decomposition appears as a common practice among the publicly available models and standards. They do not all use the exact same terminology, but they all tend to modularize the representation of the business as a hierarchy and sequences of lower sets of business tasks.
As a confirmation that tree decompositions can be applied to process decomposition let me quote "A Coordination-Theoretic Approach to Understanding Process Differences" from MIT Sloan School of Management to show that derivation trees are common ways of designing processes for modularity and reusability:
- By applying top-down coordination-theoretic modeling, supported by a handbook of generic coordination mechanisms and exceptions handlers, we were able to create derivation trees for all three processes that made the source of their similarities and differences much easier to identify.7
Usually significant variations appear below the third level of decomposition in being consistent with APQC at the task level defined by its categorization.
Defining Service Granularity from Business Maps
My customers frequently ask, "What is a good service granularity?" Business maps and decompositions are a particularly powerful tool to identify a service granularity and, thus, answer this question. I regularly use them in customer meetings and receive excellent feedback.
However, to answer this question, first we need to precisely define a service. In the following discussion and throughout this book, we use these definitions:
- Business service—The grouping of repeatable business tasks that address the same functional domain, for example, Process Customer Order. Business policies are defined at this business service level, such as policies to handle various business services for corporate customers or individuals. The term we use is specifically looking at software components that deliver business logic and not business activities at the level of "sell cars" or "provide mobile telephone services."
- Web Service—A technical representation of the elements of a business service, grouping discrete business tasks together for technical management such as versioning in a technical descriptor using either Web Services Description Language (WSDL) or in a more abstract fashion Service Component Architecture (SCA) as technical standards. Looking at the Process Customer Order business service, the included Web Services might be Customer Order Life Cycle Management and Customer Order Information Management. There can be one or more Web Services per business service, but in many cases there will be only one.
Service operation—A repeatable business task. In the previous case, a service operation might be Perform Order Feasibility Check, Submit Customer Order, or Receive Order Status Update. These are usually qualified as operations in the WSDLs or SCA descriptors. The number of operations range from one to ten or more. Given these definitions, let's do a simple computation. At a level 2, an enterprise usually has between 50 to 100 business components or process groups. Down one level, there are between 300 and 1,000 processes in the enterprise. For example, the eTOM telecommunication business process decomposition gives around 400 processes at level 3.
At level 4, the number of tasks will be between 1,000 and 10,000. APQC has 1,500 activities defined at level 4, and if we pushed eTOM to a further decomposition, at a level 4 we have around five to seven times 400, or 2,500 tasks.
We see that this is already a very large number of tasks, and a large portion of these tasks can potentially become business services. If we compute the number of operations, this gives us a potential of 5,000 to 20,000 service operations for the enterprise, a huge effort to manage. However, only a fraction of the enterprise has value to be exposed as business services and processes, and from our experience between 1% and 5% of the potential services operation has reusability value at the enterprise line of business levels.
The conclusions on granularity are
- A good business service granularity, to maintain value and manageability, is between level 3 and level 4 of the enterprise functional decomposition. This usually corresponds to the APQC level 4, Activities.
- Without a functional decomposition, there is no way to know the granularity level of a given service.
- Processes should be modularized using a functional decomposition to make the modules reusable as business services at level 3. At level 4 or under, the business services are exposed from applications as detailed in the section, "Mapping the Enterprise Applications," later in the chapter.
- Any too fine-grained Application Programming Interface (API) at level 5 or below should be aggregated into a coarser grained service by applying variability on the interfaces and resolving the variability between the façade and the API.
Mapping the Enterprise Applications
There is a difference between the business components and the implementation of the services that they require. Let' look at a concrete example.
At level 3 eTOM defines a Track and Manage Order Handling process, part of the Order Handling group. However this process requires accessing services from a Customer Information Management, a Product Catalog Management, a Billing Management, and a Customer Order Life Cycle Management application, which is implementing the services.
If the intention is to look at a future state architecture, the ideal application map must be defined. This is the map that an enterprise would create if there were no financial, time, or technology restrictions. These maps are often delivered by IT consulting companies and often referred to as "city planning." This application map is the superstructure of interfaces that will be exposed as the reusable business services layer.
Defining these maps in a top-down approach is essential to isolate the business processes that consume services from the real implementations in the existing applications. This top-down approach needs to be complemented by a bottom-up approach that defines how existing or new applications and packages will be adapted to expose these interfaces in a flexible and consistent manner. The best practices for delivering such adaptations are discussed in later chapters of this book.
One standards body standardizes this application map, and it's no surprise the TeleManagement Forum (TmForum) is the most advanced in that space, as telecommunication operators are faced with exponential growth and dynamic market evolutions, requiring higher levels of standardization for lowering costs.
TmForum Telecom Applications Map8
The Telecom Applications Map provides the bridge between the NGOSS standardized business process and information framework building blocks (eTOM and the SID, Shared Information and Data model) and real, deployable, potentially procurable applications by grouping together process functions and information data into recognized operation support and business support applications or services.
Even though no standard can ever represent a perfect systems infrastructure for an operator, the map provided in Figure 1-5 presents a functional and information guideline for implementing a layer of reusable business services exposed by application.
Figure 1-5 The TmForum Telecommunication Application Map GB929 R2.1
Mapping the Enterprise IT Infrastructure
The business processes and applications require an IT and middleware infrastructure to operate. It is important that this infrastructure also provides support for variability and flexibility at a core technical level. Even though some standards like the Open Grid Services Infrastructure (OGSI)9 are looking at standardizing services exposed from infrastructure components, there are no commonly accepted standards for middleware and operating systems services.
One approach to a product-agnostic map is the SOA Reference Model that IBM provides. This model, shown in Figure 1-6, serves as a reference point to position both middleware and functionality within a service-oriented architecture. For further details, see "IBM SOA Foundation: An Architectural Introduction and Overview."10
Figure 1-6 The IBM SOA Foundation Reference Model
Mapping the Enterprise Information
Information is the essential "logical" asset that links together all layers of the enterprise. As processes do not run in vacuum but carry, transform, and refer to information, the structure of that information reflects the way the enterprise wants to operate. Figure 1-7 shows how telecommunication operators relate business domains to core entity domains.
Figure 1-7 TeleManagement Forum eTOM and SID relationships
The business information model, domain maps, and core entities represent the business view of the information as opposed to data models, which address the technical implementation of managed objects data (see IETF RFC 344411).
As an example of the influence of business on the information model, let's look at a retailer that used to sell single products and now wants to sell bundles. Should the bundle business object be considered a product with its own pricing superseding included products, or should it be another type of business entity with a global pricing deduced by applying discounts to the products included in the bundle? This is typically a business question that relies on the business model and needs to be reflected in the information model.
The Unified Modeling Language (UML) diagram in Figure 1-8 shows inheritance on the left or none on the right, a consequence of the way the enterprise intends to address markets.
Figure 1-8 Business model affecting the information model
A question arises: Can we make the model flexible enough to address both cases and allow variations of the business model in the future? We address approaches to a realization of this variability in Chapter 3, "Implementing Dynamic Enterprise Information."