Appendix A: Core Concepts and Standards

At the core of this work is the concept of an enterprise. According to [7]:

An enterprise is a complex, socio-technical system that comprises inter-dependent resources of people, information, and technology that must interact with each other and their environment in support of a common mission.

In the Case Study, the enterprise is ArchiMetal, a fictitious manufacturer of metal products. The Case Study describes the baseline and target states of the ArchiMetal enterprise within each of the four TOGAF Enterprise Architecture domains. Each domain has different areas of concern [2].

Table 1: TOGAF Enterprise Architecture Domains and their Concerns

The TOGAF standard specifies an Architecture Development Method (ADM) for developing Enterprise Architectures, turning them into actionable plans, and managing them as business and technical circumstances evolve over time (Figure 33). There is a direct correspondence between the Enterprise Architecture domains defined by the TOGAF standard and the three ADM phases. Phase B (Business Architecture) and Phase D (Technology Architecture) guide the development of the Business and Technology domains, respectively, while Phase C (Information Systems Architectures) guides the development of the Data and Application domains.

Figure 33: TOGAF Architecture Development Method

The ArchiMate language [1] is closely aligned with the TOGAF standard (Figure 34). It supports the ADM Phases B through D by modeling its three aspects of Passive Structure, Behavior, and Active Structure at each of its three core layers: Business, Application, and Technology. In addition, it includes two extensions. The Strategy and the Motivation elements support the Preliminary, Requirements Management, Phase A, and Phase H with such concepts as capabilities, resources, stakeholders, drivers, assessments, goals, and requirements. The Implementation and Migration elements address the ADM Phase E (Opportunities and Solutions), Phase F (Migration Planning), and Phase G (Implementation Governance), with concepts such as work packages, gaps, deliverables, and plateaus, which are stable system states.

Figure 34: Alignment between the TOGAF Standard and the ArchiMate Language

Entities modeled with the Implementation and Migration elements realize core elements such as business processes, application components, and server hardware. These core elements in turn can be shown to realize Motivation elements such as requirements and goals. Figure 35 provides a generic example of relationships between ArchiMate core and other elements. It models business transformation and IT projects as ArchiMate work packages that realize business and application services, respectively. Those services in turn realize business and IT goals. The business service is realized (provided) by a business process. A server (hardware device) realizes (hosts) an application component, which in turn realizes (provides) the application service used by the business process.

Figure 35: Generic Example of ArchiMate Core Layers and Extensions

In Figure 35, Business layer elements are yellow, Application layer elements are blue, and the Technology layer element is green. Motivation extension concepts are purple, and Implementation and Migration extension concepts are pink.

The combination of the TOGAF standard and the ArchiMate language yields a versatile Enterprise Architecture approach applicable to a broad range of business transformation challenges. This Case Study complements these compatible paradigms with ISA-95 [3], which is a standard for integrating systems used in manufacturing enterprises. ISA-95 governs the exchange of information between enterprise^[1] systems such as those that support sales, finance, and logistics with control systems for production, maintenance, and quality.

ISA-95 has broad industry support. It is managed by the International Society for Automation [8], which is a professional organization that claims over 30,000 members. ISA-95 is supported in products from major IT suppliers, such as IBM [9], SAP [10], and Oracle [11], and is also the basis for IEC 62241.^[2] The Business to Manufacturing Markup Language (B2MML) [12] implements ISA-95 in XML, and is also the basis for IEC 62264. ^[3]

Table 2: Structure of the ISA-95 Standard for Enterprise-Control System Integration

The ISA-95 standard has five parts (Table 2). This Case Study uses ISA-95 Part 1 to provide an overall functional model of the enterprise-control system interface, Part 3 to model workflow management interactions across that interface, and the higher-level information in Part 5 to identify transactions; i.e., message sequences that flow across the interface. The information in Parts 2 and 4, as well as the field-level message elements and detailed transaction specifications in Part 5, are too detailed for Enterprise Architecture.

The general-purpose ArchiMate language readily adapts to the manufacturing domain. Figure 36 below is a summary ArchiMate functional enterprise-control model based on ISA-95. In this figure, the arrows show the usage relationships between business and application functions, services, and interfaces. Figure 37 and Figure 38, respectively, show the ISA-95 enterprise and control business functions. ISA-95 uses a five-level functional model of manufacturing. Level 4 comprises the enterprise functions for business planning and logistics; Level 3 comprises the manufacturing operations and control (often shortened to just “control”) functions; and Levels 2, 1, and 0 define functions for manufacturing cell or line supervision, operations, and process control. ISA-95 is concerned with the interface between Levels 3 and 4; i.e., the enterprise-control interface.

Figure 36: Summary Layered View of a Functional Enterprise-Control Model Based on ISA-95

Figure 36 uses three colors to denote different types of enterprise business functions. The yellow symbols represent the Level 4 enterprise business planning and logistics functions described in the ISA-95 standard. The orange symbols represent additional functions described by the standard that interact with the Level 4 functions. The green symbol represents an enterprise function – Customer Service – which is inserted in the functional model for the Case Study.

Figure 37: ISA-95 Level 4 Enterprise Business Functions

Figure 38: ISA-95 Level 3 Control Business Functions

Figure 38 illustrates the relationship between the ISA-95 enterprise and control functions and the physical manufacturing environment. The uppermost grouping in this figure shows that a site is used by an enterprise, and a site is composed of areas. Level 4, (enterprise) business functions, applies here. The next lower grouping shows the components that make up a manufacturing area, and their controllers, which are modeled as ArchiMate nodes. Level 3, (control) business functions, applies to this grouping. Level 0, 1, and 2 basic manufacturing activities nested in this grouping are assigned to components within manufacturing areas.

Figure 39: Equipment Hierarchy showing the Physical Footprints of the Functional Levels Defined in ISA-95

Part 5 of the ISA-95 standard defines business-to-manufacturing transactions. The standard defines transactions, messages, and verbs [3: Part 5, p.18]. There are three transaction models, each of which uses different verbs. There is a PUBLISH model, where a data owner publishes to multiple subscribers, a PULL model where a data user (human or machine) makes a request of a data provider, and a PUSH model, where a user provides data to another user and asks that user to perform a processing, changing, or canceling action on that data. Figure 40 shows ISA-95 verbs classified by the transaction model they support. The CONFIRM verb is used to complete transactions in all three models.

Figure 40: ISA-95 Verbs Classified by the Transaction Model They Support

Figure 41 depicts a scenario that uses a number of the concepts described in this section. A customer requests a large, urgent order from a manufacturer. To fill this order, the manufacturer must alter production schedules at multiple manufacturing locations. This event triggers a chain of information exchanges between the Enterprise Marketing and Sales, Order Processing, and Global Production Scheduling functions. The Global Production Schedule function uses a PUBLISH model transaction message with a SYNC CHANGE verb to align multiple local production schedules with the newly changed global schedule. This transaction crosses the enterprise-control interface, and triggers information exchanges between the local production scheduling and production control functions. Once the new schedule is implemented, a series of confirmation messages moves between the business functions in the reverse direction. To complete the PUBLISH model transaction, a transaction message with a CONFIRM verb crosses back over the enterprise-control interface. This scenario is also used later in this Case Study as part of a more extensive scenario.

Figure 41: A Model of the Activity that Ensues when a Large, Urgent Order Triggers a Production Schedule Change

Since ISA-95 does not describe the role of CRM systems in manufacturing enterprises, this Case Study uses the model in Figure 42 to complement the ISA-95 manufacturing models.

Figure 42 shows the taxonomy of typical CRM application functions. CRM applications typically have functions for customer acquisition and retention, as well as for customer understanding, which is often called business intelligence. Figure 43 shows how these functions are used by the Enterprise Marketing and Sales and the Enterprise Customer Service functions in this expanded model. These diagrams illustrate how the ArchiMate language can be used to combine and adapt diverse paradigms for use in Enterprise Architecture.

Figure 42: A Taxonomy of Typical CRM Application Functions

Figure 43: Enterprise Business Function Usage of CRM Application Functions