Home > Articles > Web Services > SOA

This chapter is from the book

This chapter is from the book

Dynamic SOA and BPM: Best Practices for Business Process Management and SOA AgilityDynamic SOA and BPM: Best Practices for Business Process Management and SOA Agility

Learn More Buy

This chapter is from the book

This chapter is from the book

Dynamic SOA and BPM: Best Practices for Business Process Management and SOA AgilityDynamic SOA and BPM: Best Practices for Business Process Management and SOA Agility

Learn More Buy

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

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

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

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

  1. Categories—Classifying business competency domains of the enterprise
  2. Process Group—Grouping processes in business components that apply to similar business entities
  3. Process—Formalized list of tasks and activities required to achieve a specific aspect of a business component
  4. 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

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

  1. 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.
  2. Process Category—This level 2 or configuration level provides a reconfigurable level that companies will adjust to their own business plans.
  3. 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.
  4. 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

  1. 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.
  2. Without a functional decomposition, there is no way to know the granularity level of a given service.
  3. 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.
  4. 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

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

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

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

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."

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020