Chapter 5. The Architecture Overview

The building is a marvel—its architecture immortal!

The preceding chapter covered the essence of the system context. The system to be built—that is, the IT System—has been a black box until now, and we have been carefully walking around its edges. In this chapter, we take our first bold step in opening up the black box and peek into it for a good look! Specifically, we will put on our view lens to glimpse a set of complementary views of the system’s architecture.

The architecture of any system can be rendered through multiple viewpoints, or views. Although each view has a specific value statement, my intent is to focus only on those views of the architecture that are just enough for the solution architect to effectively communicate the solution architecture with the intended stakeholders. (I use the terms “solution architect,” “software architect,” and “enterprise architect” interchangeably in this book; they refer to the same general role, that of the overall architect for a complex system.)

This chapter introduces three essential views of the systems architecture under consideration: namely, the Enterprise view, the Layered view, and the IT System view. These three views collectively provide a high level overview of the system’s architecture. It is important to note that the architecture overview is the first step into the internals of the system. As such, the first treatment of it is conceptual in nature—that is, a technology agnostic overview—for all three views. A technology agnostic view implies that the architecture artifacts, at this stage, are not influenced by the software and middleware products.

The chapter concludes by instantiating the architecture overview for the case study of the Elixir system.

If we go back to first principles and acknowledge the essence of simplicity in support of effective communication, it is more important for the architecture overview diagram to be simple, brief, clear, and understandable than comprehensive or explicit in all its details. Consequently, such diagrams typically use an informal free-form diagrammatic notation, although a current breed of architecture tools provides annotated widgets in an effort to standardize and formalize. Regardless, the schematic diagrams are typically elaborated through supporting text that explains the main concepts of the architecture.

The three types of architecture diagrams are

• The Enterprise view

• The Layered view

• The IT System view

When alternative architectural solutions are being explored, an architecture overview diagram may be produced for each option to enable various stakeholders to discuss the trade-offs between the options.

The Enterprise view of the architecture is often produced as part of an overall IT strategy. It may be used to describe the IT capabilities required by the organization in support of its business objectives vis-a-vis the system or application under consideration that is to be built. It provides an overview of the main conceptual elements (a.k.a. ABBs): components, nodes, connections, data stores, users, external systems, and a definition of the key characteristics and requirements that each of them are expected to meet. The diagram also provides an early view of the placement of the ABBs into conceptual architecture layers. The view is fairly static in nature, which is to say that the interrelationships between the ABBs are not highlighted.

The Layered view focuses on developing a set of architecture layers; each layer is defined by a set of characteristics that determine the placement of the ABBs in one of the many layers. A layered architecture follows a set of guidelines for communication and information exchange between the ABBs. Adherence to the guidelines fosters a good integration strategy prescribing interdependencies, linkages, and communication paths between the ABBs.

The IT System view introduces dynamism into the system by further elaborating (in the form of data flow) on the interrelationships between the ABBs. As such, it influences the inception of the functional and operational models (the topics of Chapter 7, “The Functional Model,” and Chapter 8, “The Operational Model”).

The architecture overview establishes a big picture view of the system in which the architecture components play the role of the foundational building blocks, the ABBs. It helps formulate some architecture principles and guidelines around how the components may collectively coexist and cooperate to realize architecturally significant use cases. Although some architectural decisions (the topic of the next chapter) may start getting identified as challenges that need to be addressed, the architecture overview is not the step in which I suggest design commitments are formalized. Such commitments are timelier after the functional and operational models (see Chapters 7 and 8) are established.

It is important to understand and acknowledge that the development of the architecture of any system is an iterative process. Recognize that the functional model and the operational model are the primary models. Also, be aware that their establishment and formalization may require you to revisit and revise the architecture overview diagrams if changes are made to the main concepts and relationships.

• It serves as a foundation aspect of the system’s architecture and is used as a guide for the more elaborate and detailed functional and operational architectures of the solution.

• It is used to communicate a conceptual understanding of the architecture of the evolving solution to the stakeholders.

• It is leveraged as a mechanism to evaluate different architecture options to solving a particular class of problems.

• It is used to capture the Enterprise and the System views of the architecture in a single consolidated artifact.

• It supports the orientation of new technical team members joining the project.

Put simply, the absence of this construct deprives the software development team of envisioning the “big picture.” The overview is often used not only to identify and remediate architecture problems early on but also to take a step back, when stuck with a problem, and recognize the guiding principles and patterns that may assist in a constraint-based problem solving process.

The key takeaway for you is to acknowledge the importance of the architecture overview construct so that you are convinced to apportion commensurate time and effort in its development and documentation.

The target operating model for any organization or enterprise can be categorized into one of these three: operational excellence, product leadership, or customer intimacy. Businesses typically focus on one of the three models to differentiate itself from the competition. An operating model, in turn, is made up of operating (a.k.a. business) processes, business structure, management structure, and culture, all of which are synchronized to foster value generation. From an IT standpoint, the three business operating models can be broadly mapped to four IT-level operating models:

• Diversification—With low standardization and low integration requirements

• Coordination—With low standardization but high integration focus

• Replication—With high standardization but low integration focus

• Unification—With high standardization and high integration imperatives

For more information on IT operating models, see Weill and Ross (2004) and Treacy and Wiersema (1997).

The discussion on business and IT operating models here may seem to be a bit out of context when actually it is not. I have found this knowledge to be helpful when interrogating an architect on the rationale for an enterprise-level architecture view and how it is related to the organizational imperatives per se. To be able to talk the talk on business-to-IT alignment is certainly a skill an architect should seek to have in her repertoire.

Enterprise architecture provides a mechanism to identify and represent—in a single unified view—the business processes, data and information sources, technologies, customer-facing user interfaces, and delivery channels that take the operating model from vision to reality. The Enterprise view, which is the enterprise architecture viewpoint, is the single architecture diagram that communicates the enterprise’s core business processes along with the application and infrastructure building blocks that foster their realization. The diagram is typically and intentionally represented at a high level and does not drill down into detailed elaborations of the application, data, technology, or business process architectures. However, this single view becomes the starting point, in subsequent treatments, for further detailed elaboration of the artifacts.

Now let’s look at a real-world Enterprise view diagram so that we can understand each artifact and how to appropriately capture them. Figure 5.1 depicts a simple one-page diagram of the high-level business processes, technology enablers, data and information, delivery channels, and types of users. Collectively, they represent the Enterprise architecture view of a typical banking system. (I again chose a banking system for illustration, owing to our familiarity with money matters.)

It is important to justify the rationale for the inclusion of each conceptual element in the Enterprise view. The justification is typically illustrated in textual form. The rest of the section elaborates a systematic approach to capturing the architecture components, using the Enterprise view in Figure 5.1 as an example.

While taking the elevator up to the company cafeteria, for instance, you may get questioned by a colleague: “So how do you read and interpret the enterprise-level view of the systems architecture?” You have to keep your explanation simple lest you lose his attention due to the smell of hot food getting stronger and stronger. So here is a one-minute elevator speech that you may use:

The Enterprise view categorizes the systems and functions required to build the IT System while depicting the general direction of information flow. Various types of users interact with the IT System through a variety of delivery channels through which the system functions are made accessible. The system functions are typically implemented as a set of core business processes. Data and information are critical to the realization of the business processes; they typically reside in either one or more enterprise information systems or in some system that is external to the enterprise; some of the data is required as inputs to the process steps, while some information is generated by some of the process steps. A set of technology enablers is required to interface with the enterprise information systems to facilitate data and information exchange.

Let’s now focus on capturing the essential information.

• Customers access the applications over the Internet (and in some special cases, the intranet) using their web browsers as the delivery channel.

• Employees, including call center personnel or administrators, access the system over the intranet using their web browsers. These users could also access these applications via their corporate virtual private network (not depicted in the figure).

• External partners are allowed to access a functional subset of the system using web services (as the delivery channel) based service invocations.

Users access a certain subset of functions through one or more delivery channels. The available feature functions may vary between the delivery channels and may also be delivered through different presentation styles that are appropriate for the delivery channel. As an example, employees may be able to access additional functions that customers cannot. Customers may be able to access all functions on both their desktops as well as their mobile devices, whereas employees may have to access the more mundane administrative functions only via the desktop version of the application.

• Open Checking Account—Provides the ability to open a checking account for the customer; the process is expected to be completed in less than 10 minutes. The process can be invoked not only at the branch office through a teller counter but also through a self-service online banking portal.

• Transfer Funds—Provides the ability to transfer funds from one account type to another within the bank. It also provides the ability to transfer funds between international bank accounts requiring a transaction fee; the process is expected to complete in no more than one business day.

• Open Mutual Funds Account—Provides customers and employees (henceforth called account holders) the ability to open a mutual fund account with the bank, thereby allowing the account holders to access the bank’s most trusted and highest performing funds. The feature also allows the account holders to seamlessly link the account with a checking account and provides up to 40 free transactions per month.

• Pay Credit Cards Settlement—Provides customers with the ability to settle credit card payments online. The process is made simpler by providing direct debit from a checking account with overdraft protection to facilitate seamless and hassle-free credit card payments.

The rest of the business processes should also be similarly described and captured at a high level, thereby providing an overview of how the core processes assist the bank in excelling in the operating model that it has chosen for competitive differentiation.

For the sake of brevity, I will not describe all the business processes in Figure 5.1; I will exercise the same liberty while describing the rest of the Enterprise view artifacts.

• CRM—In the customer relationship management system, the customer entity, her demographic information, the number of subscribed banking products, and her account standing, are key business entities that are required to realize the core set of business processes.

• Products—This represents the various products that the bank offers to its customers and employees. Examples of products are checking accounts, savings accounts, mutual funds, credit cards, and so on.

• Orders—This represents the orders that bank customers place. Orders can be payments, mutual fund transactions, funds transfers, and so on.

• Business Rules Catalog—A collection of business rules is used to realize the various implementations of the business processes. Each business rule uses information elements and enforces certain conditional logic upon them. The rules can be represented in natural language and can be modified by business users. Listing 5.1 gives an example of a rule.

Listing 5.1 Business Rule Example

Click here to view code image

---

If mutual_fund_transaction_number is <= 40 then transaction_fee_flag =
"false"

---

The rest of the information and data entities should be similarly documented.

• Message Transformation—Facilitates information exchange between heterogeneous systems. This enabler transforms message packets, which are units of information exchange, from one data format (for example, supported by the system of record) to another (for example, as expected by the business process step). It is typically used to standardize on a message format that may be used to implement the core business processes of the IT System. Optionally, it may also help in transforming messages from a standard format to one that an invoking client system may expect or support.

• Message and Service Routing—Supports basic and advanced message and service routing capabilities. Also supports the intelligence to find the correct service provider for a given service request and appropriately route the service request.

• Real-Time Event Bus—Provides basic and advanced capabilities supporting simple and complex event processing. This enabler facilitates the processing of asynchronous business and system events and may also optionally leverage the message transformation and routing capabilities for event dispatch and processing.

• Directory Server—Stores and manages the user profiles that are needed to validate user credentials to perform authentication and authorization for role-based access to the IT System.

• B2B Gateway—Facilitates the receipt of requests from third-party external systems, typically through service invocations. The role of the gateway is to provide a focal point for handling both incoming and outgoing requests. For incoming requests, originating from external entities, it determines the right supporting service before invoking the service and generating the response. For outgoing requests, the gateway is responsible for locating the external service, creating the service request, and subsequently invoking the service.

The remaining middleware components should also be captured at least at a similar level of elaboration.

A standard and well-accepted guiding principle determines the placement of components in layers: components in any given layer may interact only with components that are in lower layers in the Layered view of the architecture. A layered architecture fosters modular design; the interlayer dependencies minimize tight coupling in the architecture.

I want to highlight some of the advantages of a Layered view, while making no claim that they are exhaustive. Let me remind you of the recurring theme of this book: understand just enough to convince yourself of its importance and capture just enough to allow effective communication to all involved stakeholders! So here are a few reasons for developing a Layered view:

• Provides an exposition mechanism—Other applications and systems can use the functionality exposed by the various layers of the IT System.

• Fosters modular testing of the system—Test cases can be developed and executed on a per layer basis with normative guidance on the nonfunctional requirements (NFR) that are expected to be met.

• Fosters best design practices—Through the enforcement of low coupling (between layers) and high functional cohesion (within the components in each layer), optimal designs can be achieved.

• Streamlines systems development—Design and implementation skill sets can be aligned to the technology requirements of each layer.

• Enforces interlayer communication—Components, other than communicating with other components in the same layer, can only communicate with components that are in lower layers.

• Supports nonfunctional requirements—Components in a layer that are susceptible to high workloads can be distributed into multiple physical servers (tiers), driving standardization of the operational topology of the deployed IT System. (For more details on operational modeling, see Chapter 8.)

Figure 5.2 shows a typical Layered architecture view. I leave it as an exercise for you to determine the placement of the architecture components from the Enterprise view (Figure 5.1) into the Layered architecture view. This section provides a good overview of the various layers in a layered architecture model...just about! You may need to consult a dedicated book on SOA if you are serious about the homework assignment. In that case, see Executing SOA: A Practical Guide for the Service-Oriented Architect (Bieberstein, Laird, Jones, & Mitra 2008).

The Layered architecture view in Figure 5.2 introduces a set of commonly used architecture layers of any non-trivial IT System. I recommend this view because it addresses any architecture regardless of whether it is SOA based or non-SOA based. If it is the latter, the Services layer would not be required, whereas the Service Components layer may be replaced by a Components layer. Voilà, you get two in one!

In the following sections, I share definitions of each layer. The intent is not only to provide an understanding and appreciation for each of the layers but also to assist in determining the placement of the architecture components, or architecture building blocks (ABB), into the appropriate layers. Henceforth, I use the terms architecture components and ABBs interchangeably as they mean the same construct.

Figure 5.2 depicts a nine-layered architecture with five horizontal layers and four vertical layers. The horizontal layers—Operational, Service Components, Services, Business Processes, and Consumers—follow the basic principle of a layered architecture model in which ABBs from layers above can only access ABBs from layers below, and not vice versa. The vertical layers—Integration, QoS, Information Architecture, and Governance—usually contain ABBs that are cross-cutting in nature; cross-cutting implies that the ABBs in this layer may be applicable to and used by ABBs in one or more of the horizontal layers. Some architecture schools may look at the Layered view and opine that it is a partial layered architecture, their rationale being that any layer above does not need to strictly interact with elements from its immediate lower layer. For example, a specific access channel may directly access a service rather than needing to go through a business process. So if you come across students from such a school of thought, relax, take a deep breath, and accept them as your friends, because they are also correct! Just remember that the access constraints between components in layers are dictated by the architectural style, guidelines, and principles that are applicable for a solution.

The following sections provide short definitions for each of the layers. The definitions will help you identify architecture components and place them in the proper layers in the Layered architecture view. Remember your assignment?

Standard industry models like ACORD and MIMOSA are typically leveraged and adopted to define the information architecture and the business protocols used to exchange business data. (ACORD is an insurance industry standard that has a data and information model; see https://www.acord.org/Pages/default.aspx. MIMOSA is an open information standard for operations and maintenance in manufacturing, fleet, and facility environments; see http://www.mimosa.org.) The layer also stores the metadata required for data mining and business intelligence (BI). Components in this layer ensure the adherence to and the implementation of any data or information standards (industry level or enterprise specific) that are either mandated (legal, corporate policies, IT standards, and so on) or adopted by the IT System.

Note: I have seen layered architectures that have this layer placed either as a vertical or a horizontal layer (just below the service components layer). You can adopt either one of the representations.

My expectation is that, based on the definitions provided here, you will be able to identify architecture components and place them in one of the nine layers. You are empowered to leverage the definition of the layers, while you embark on architecting, designing, and documenting your own solution architecture.

Once all the architecture components are placed in one of the nine layers, they need to be appropriately documented such that their description communicates their role, responsibility, and intended usage in the overall solution architecture. You may also notice my use of “components” and “ABB” interchangeably; they refer to the same construct and are used to keep the terminologies a bit flexible.

And lastly, the nine-layered view is meant to be a guideline. You can always refine the Layered view by adding or merging layers as you see relevant; just keep in mind that layers are supposed to be characterized by low coupling (between components across layers) and high cohesion (between components inside layers). Speaking of guidelines and relevant refinements, in Chapter 11, “Analytics: An Architecture Introduction,” I develop a refined Layered view of an analytics reference architecture!

The IT System view needs to be captured and documented so as to provide enough information, at a conceptual level, for the subsequent development of other more detailed architecture artifacts. The IT System view serves as the starting point for the development of the functional and operational models (topics of Chapters 7 and 8, respectively). This view may be extended or refined during the definition of the functional and operational models. As an example, the conceptual nodes in this view not only serve as key inputs to the identification of physical servers but also help in identifying the right technologies to implement the functionality of each of the nodes. More concretely, the operational model may map the conceptual nodes in the IT System view to actual physical servers. Each physical server may potentially support multiple conceptual nodes, and similarly, any given conceptual node may be deployed on multiple servers. The final deployment topology design is influenced by the system NFRs and constraints.

Figure 5.3 depicts an IT System view for the illustrative banking system. I will not describe each node in Figure 5.3 in great detail. Time and space are more optimally spent by looking at a template that I recommend you follow while documenting each node. I do, however, provide a brief description of each of the numbered nodes in the diagram before discussing the documentation template. I also describe one of the nodes and provide an example of how to fill up the template with the relevant information.

Let’s look briefly at the nodes first:

1. Public Firewall Node—Resides in the demilitarized zone (DMZ) and allows only HTTP traffic to enter into the enterprise network.

2. Dispatcher Node—Used for load balancing of multiple requests across a cluster of Web Informational Nodes and Application Server Nodes.

3. Reverse Proxy Node—Is a hardened (that is, has tightened access restrictions, following security guidelines) web server used as an interceptor of any requests from external clients granting access to only authenticated and authorized users and to authorized systems.

4. Enterprise Firewall Node—Opens only some selected and secure ports into the secured enterprise network, thereby protecting critical enterprise applications and data through a double door mechanism.

5. Security Node—Provides authentication and authorization for some of the enterprise applications, databases, mainframe systems, or packaged applications.

6. Web Informational Node—Serves only static content and enhances performance for web-based applications.

7. Application Server Node—Hosts the application components that implement the business logic.

8. EAI Integration Node—Provides capabilities to integrate with back-end systems. (EAI stands for Enterprise Application Integration.)

9. Content Syndication Node—Aggregates and publishes enterprise content.

10. Enterprise Firewall Node 2—Used in hosted situations in which a part of the IT System topology is hosted and maintained by third-party vendors.

The preceding documentation becomes redundant when there is enough information available to provide more detailed documentation of each of the nodes in the IT System topology. In the rest of the section, I provide such an example.

Each node in the IT System view is expected to have the following information:

• Node Name—Specifies the name of the node.

• Description—Provides a detailed description of the characteristics and features of the node.

• Services or Components—Describes the services or components that are running on the node; for example, Relational Database, Transaction Manager, State Management, and so on.

• Nonfunctional Characteristics—Describes the list of nonfunctional characteristics that the node must support and fulfill.

• Connections to Other Nodes—Enlists the other nodes that are connected with this particular node in the topology.

• Hardware Description and Operating System—Describes the hardware architecture of the physical server on which the node is deployed and the type of operating system along with its software version.

Let’s look at the Application Server Node, labeled number 7 in Figure 5.3, as an example in context, to provide guidance on how to capture the detailed artifacts for each of the nodes in the IT System view.

For the Application Server Node, the following documentation is an example:

• Node Name—Application Server

• Description—The Application Server Node is responsible for processing the transactions and providing web users access to back-end systems and databases. It supports web transactions and provides many of the operational characteristics identified by the operational requirements of the application; these include multithreaded servers to support multiple client connections, redundant services to handle additional loads, dynamic load-balancing capabilities, a pool of database connections, automatic failover, and recoverability. The node may be deployed in clustered mode and hosted either on multiple virtual machines (on a single physical machine) or on multiple physical servers. Above and beyond providing the technology and operational capabilities, this component also hosts the deployed application components that implement the system’s business logic.

• Services or Components—The Web Application Server Node, which is an instance of the Application Server Node, will host the following components:

• The application components that encapsulate the business logic for all the deployed applications.

• Application Server software.

• The supported version of the Java Virtual Machine.

• Software for monitoring web site usage and gathering statistics around usage, threats, and so on.

• Systems management software to detect, diagnose, and automatically correct failures and configurations to notify system administrators of critical server conditions.

• Nonfunctional Characteristics

• Response time—Indicates time to respond to a user request at peak operating hours under maximum workload. As an example, the response time must not exceed 5 seconds at least 90 percent of the time.

• Availability—Provides metrics regarding the percentage of operating time that the node must be operational. As an example, the node must have an uptime of 99.95 percent on an annual basis. Availability of the applications running on this node must follow the same uptime metrics.

• Scalability—Provides guidance on how to scale the node to support the agreed-upon performance metrics. As an example, guidance on how vertical and horizontal scalability (more on different types of scalability in Chapter 10) may be necessary based on specific type of workload conditions.

• Workload monitoring—Statistics must be available on the following:

• The average and peak load profile of user and system requests during an entire day.

• The average and peak number of active concurrent database connections during an entire day.

• Connections to Other Nodes—The node is directly connected to four nodes:

• Enterprise Firewall Node provides security at the network protocol level.

• Personalization Node provides targeted application features and capabilities.

• Security Node propagates security credentials to the applications.

• EAI Integration Node provides integration logic facilitating the required integration with database systems, packaged applications, and legacy systems supporting the business processes.

The preceding information may also be represented in a tabular format, which may render it more conducive to the reader (see Figure 5.4). Adopt whichever format is more acceptable for easier communication. Each of the nodes in the IT System view should ideally have the level of documentation illustrated here for the Application Server Node.

This marks the end of the illustration of the three complementary views of a system architecture. As you iterate and refine the development of the views and the ABBs, you will see some patterns emerge not only on how the various ABBs are characterized but also on how they interface and communicate with each other. Fowler (2002) provides a very good reference for enterprise architecture patterns.

Take a moment now to pause and recollect what you read and, more importantly what you understood and consumed so far in this chapter. Before you read further, I recommend you open a document and create your own template for the architecture overview, not to emulate the content described so far but to ensure that your understanding is clear. There is no hard and fast rule that the template has to follow exactly as described. Make it support enough artifacts to adequately communicate the architecture overview as you see pertinent and applicable to your IT System and its intended stakeholders.

While the entities and components in the Elixir Users (refer to Chapter 1, “Case Study”) and the Elixir Delivery Channels are self-explanatory, the following sections provide just a brief description of each of the other components or ABBs. The actual definition would certainly be more detailed. The idea is to give you a starting point from where you can develop and document the architecture facets of the IT System you are in charge of architecting.

And before you look at the components, it is important to understand the definition of a middleware component and an adapter. Many of the Elixir Technology Enablers components are categorized as middleware or adapters. Middleware refers to any component that resides between the operating system (OS) and the IT System, in a typically distributed system. An adapter is a component that converts data formats and communication protocols between two heterogeneous systems so that the two systems can seamlessly communicate and exchange information.

Onboard New Equipment—This business process supports the entire process of adding a new machine (for example, SHV_007) or a new machine family (for example, Shovel) to the Elixir system.

Create Maintenance Order—This business process triggers a new maintenance work order in the Elixir Work Order Management System (WOMS).

Perform Root Cause Analysis—This business process kicks off the process of determining the root cause of a machine or parts failure, from initiation to final analysis outcome.

Change Machine Configuration—This business process modifies any change in the configuration of an already operational machine (for example, replacing two engines with one larger and more powerful engine).

Calculate Production KPI—This business process performs the various key performance indicator (KPI) calculations related to key production business metrics (for example, machine availability for operations).

Capture Shift Details—This business process captures all shift-related details (for example, production, machine downtime, operator downtime, and machine faults).

Product Engineering System (PES)—The system of record that stores the engineering structures for all machine types. It exposes a set of APIs through which the engineering structures may be retrieved.

CAD System—Stores all the digitized engineering drawings for each class of equipment.

RCM System—Stores all the process data around reliability and maintenance of equipment. The failure modes and their probable causes for specific faults and fault types that are stored in this system are used to facilitate root cause analysis of machine or parts failures.

Work Order Management System (WOMS)—Manages the scheduling of maintenance work orders and also capturing the details of finished work orders.

Elixir Operational Data Store (ODS)—Stores all the analytical output and related data attributes that are generated by the Elixir system through successful execution of the business processes.

Enterprise Data Warehouse (EDW)—A corporate data warehouse that stores the historical data for all business-critical data entities and transactions in a way that is amenable to efficient business intelligence reporting.

Note: The Enterprise HRMS System is purposefully omitted; this system is not in the scope of the first phase of the implementation of Elixir.

Data Collection Agent (DCA)—A software application that interfaces with the control systems on the machines and collects the data from the machine sensors.

Enterprise Service Bus (ESB)—A middleware component responsible for any protocol conversion (between client data and transport protocols to the protocol used inside the Elixir system), mediation, and routing of data and information to the subscribed consumers.

Directory Server (DS)—A middleware component used to provision the users and their association to one or more application roles along with their access rights to the subset of physical assets that each user is eligible to view, monitor, and take action on.

Real-Time Analytics Engine (RTAE)—A middleware component that ingests real-time data and performs analytical processing in real time—that is, on the streaming data, before it is persisted into a persistent store (for example, a database).

Business Rules Engine (BRE)—A middleware component that supports the hosting and invocation of business rules required in any business process or computation. The component is used to externalize a subset of the business rules in anticipation of their dynamic nature; that is, the rules may need to be changed frequently without affecting the system operations.

Reverse Proxy Server (RPS)—A middleware component used for hardening the web servers in relation to security considerations; it is used as an interceptor of any requests from external clients and provides authentication and authorization to user requests.

Portal Server (PS)—A middleware component used as a container for all presentation layer components and user interface widgets; it aims at providing a consistent and consolidated user experience for all users interacting with Elixir.

WOMS Adapter—An adapter component that provides an industry standard connection to the Work Order Management System.

PES Adapter—An adapter component that provides a unidirectional connection from the Elixir system to the client’s Product Engineering System.

Keep in mind that the description of the components here may not be adequate. Use your judgment to ascertain the right level of component description that is effective.

Note that the Real-Time Analytics Engine and the Business Rules Engine components are not placed into any of the layers in the Layered view shown in Figure 5.2. With the recent focus on analytics, newer versions of the Layered architecture views are increasingly dedicating a complete layer (with a set of domain-specific pillars) specifically to analytics. The Real-Time Analytics Engine and the Business Rules Engine ABBs will find their natural place in an analytics-centric architecture (refer to Chapter 11).

I encourage you to convert the tabular data in Table 5.1 into a Layered architecture view for Elixir. Have fun with diagrams and component placements—an exercise that often takes up a significant amount of an architect’s time!

I hope that you are beginning to understand the Layered architecture view by now.

At a conceptual level, the Elixir system is an analytical solution with elements of integration with enterprise systems and a user interface front end that interfaces with users through a set of delivery channels.

The IT System view shown in Figure 5.6 is a variation of the sample IT System view depicted in Figure 5.3. Here, I share the characteristics of only the nodes that are specific to Elixir. For the rest of the nodes, refer back to the example in Figure 5.3.

Portal Server Node—Provisions the static and dynamic user interface screens that users use to interface with the system through a set of delivery channels.

Analytics Node—Performs various analytical processing functions—for example, real-time analytics, business intelligence (BI) reporting, and predictive analytics. (Refer to Chapter 11 for a detailed discussion of analytics.)

EDW Node—Consolidates and provisions the data for fast and efficient access, supporting the multitude of queries required for business reporting and ad hoc data analysis.

As with the Layered view, I suggest that you develop a diagrammatic representation as shown in Figure 5.3 and use it as a template for your projects. You can always repurpose and enhance it to support any IT System views. This exercise will be a good investment of your time.

My intention has not, by any means, been to provide a complete representation of the Elixir system components. I have tried to provide enough detail to give you an idea of what needs to be captured, why, and how. In a real-world implementation of Elixir or a similar system, there could be a few more details. My omission is conscious and is for the sake of brevity.

The architecture overview is typically captured as a separate documented artifact. It contains the Enterprise view, Layered architecture view, and IT System view. Although other views may be introduced (you can always add a few), these three views are often adequate to appropriately represent the system under construction. The chapter demonstrated how to document the artifacts—a critical element to effectively communicate the architecture of the system with the stakeholders.

Developing templates for each view would be a good investment of time; once developed, these templates can be reused when you move from one system’s development to another. The basic constructs are the same, so they should come in handy.

The chapter also included an architecture overview for the Elixir case study. It demonstrated how most of the artifacts from the template-driven views may be reused and repurposed.

As a parting note from this chapter, I strongly recommend that you pause and try to understand the essence, importance, and value of this artifact as it pertains to the overall system’s architecture. If you believe in its importance, you will be committed to apportion commensurate time to its development and documentation.

The stage is set for you to define the software architecture. And you are in the driver’s seat already!

Fowler, M. (2002). Patterns of enterprise application architecture. New York: Addison-Wesley Professional.

The Open Group. (n.d.) TOGAF specifications. Retrieved from http://www.opengroup.org/togaf/

Treacy, M. & Wiersema, F. (1997). The discipline of market leaders: Choose your customers, narrow your focus, dominate your market. New York, NY: Basic Books.

Weill, P., & Ross, J. (2004). IT governance: How top performers manage IT decision rights for superior results. Cambridge, MA: HBR Press.