Continue Improving Adding to the Building Block

Building Blocks

Overview | Introduction to Building Blocks | Building Blocks and the ADM | Building Blocks Example

---

This chapter explains the concept of building blocks and contains a fictional example illustrating building blocks in architecture.

Overview

This section is intended to explain and illustrate the concept of building blocks in architecture.

Following this overview, there are three main parts:

• The first part, Introduction to Building Blocks (Introduction to Building Blocks), discusses the general concepts of building blocks, and explains the differences between Architecture Building Blocks (ABBs) and Solution Building Blocks (SBBs).
• The second, Building Blocks and the ADM (Building Blocks and the ADM), summarizes the stages at which building block design and specification occurs within the TOGAF Architecture Development Method (ADM).
• The third part, Building Blocks Example (Building Blocks Example), comprises a series of separate subsections that together provide a detailed worked example showing how building block context is captured, how building blocks are identified, and how building blocks are defined when executing the major steps of the ADM.

Introduction to Building Blocks

This section is an introduction to the concept of building blocks.

Overview

This subsection describes the characteristics of building blocks. The use of building blocks in the ADM is described separately in Building Blocks and the ADM .

Generic Characteristics

Building blocks have generic characteristics as follows:

• A building block is a package of functionality defined to meet the business needs across an organization.
• A building block has published interfaces to access the functionality.
• A building block may interoperate with other, inter-dependent, building blocks.
• A good building block has the following characteristics:
  • It considers implementation and usage, and evolves to exploit technology and standards.
  • It may be assembled from other building blocks.
  • It may be a subassembly of other building blocks.
  • Ideally a building block is re-usable and replaceable, and well. specified.
• A building block may have multiple implementations but with different inter-dependent building blocks.

A building block is therefore simply a package of functionality defined to meet business needs. The way in which functionality, products, and custom developments are assembled into building blocks will vary widely between individual architectures. Every organization must decide for itself what arrangement of building blocks works best for it. A good choice of building blocks can lead to improvements in legacy system integration, interoperability, and flexibility in the creation of new systems and applications.

Systems are built up from collections of building blocks, so most building blocks have to interoperate with other building blocks. Wherever that is true, it is important that the interfaces to a building block are published and reasonably stable.

Building blocks can be defined at various levels of detail, depending on what stage of architecture development has been reached.

For instance, at an early stage, a building block can simply consist of a grouping of functionality such as a customer database and some retrieval tools. Building blocks at this functional level of definition are described in TOGAF as Architecture Building Blocks (ABBs). Later on, real products or specific custom developments replace these simple definitions of functionality, and the building blocks are then described as Solution Building Blocks (SBBs).

More detail on each of these aspects of building blocks is given below.

Architecture Building Blocks

Architecture Building Blocks (ABBs) relate to the Architecture Continuum (The Architecture Continuum), and are defined or selected as a result of the application of the ADM.

Characteristics

ABBs:

• Define what functionality will be implemented
• Capture business and technical requirements
• Are technology aware
• Direct and guide the development of SBBs

Specification Content

ABB specifications include the following as a minimum:

• Fundamental functionality and attributes: semantic, unambiguous, including security capability and manageability
• Interfaces: chosen set, supplied (APIs, data formats, protocols, hardware interfaces, standards)
• Dependent building blocks with required functionality and named user interfaces
• Map to business/organizational entities and policies

Solution Building Blocks

Solution Building Blocks (SBBs) relate to the Solutions Continuum (The Solutions Continuum), and may be either procured or developed.

Characteristics

SBBs:

• Define what products and components will implement the functionality
• Define the implementation
• Fulfil business requirements
• Are product or vendor-aware

Specification Content

SBB specifications include the following as a minimum:

• Specific functionality and attributes
• Interfaces; the implemented set
• Required SBBs used with required functionality and names of the interfaces used
• Mapping from the SBBs to the IT topology and operational policies
• Specifications of attributes shared across the environment (not to be confused with functionality) such as security, manageability, localizability, scalability
• Performance, configurability
• Design drivers and constraints, including the physical architecture
• Relationships between SBBs and ABBs

Building Blocks and the ADM

Basic Principles

This section focuses on the use of building blocks in the ADM. General considerations and characteristics of building blocks are described in Introduction to Building Blocks .

Building Blocks in Architecture Design

An architecture is a set of building blocks depicted in an architectural model, and a specification of how those building blocks are connected to meet the overall requirements of an information system.

The various building blocks in an architecture specify the services required in an enterprise-specific system.

There are some general principles underlying the use of building blocks in the design of specific architectures:

• An architecture need only contain building blocks to implement those services that it requires.
• Building blocks may implement one, more than one, or only part of a service identified in the architecture framework.
• Building blocks should conform to standards relevant to the services they implement.

Building Block Design

The process of identifying building blocks includes looking for collections of functions which require integration to draw them together or make them different:

• Consider three classes of building blocks:
  • Re-usable building blocks such as legacy items
  • Building blocks to be the subject of development, such as new applications
  • Building blocks to be the subject of purchase; i.e., Commercial Off-The-Shelf (COTS) applications
• Use the desired level of integration to bind or combine functions into building blocks. For instance, legacy elements could be treated as large building blocks to avoid breaking them apart.

In the early stages and during views of the highest-level enterprise, the building blocks are often kept at a broad integration definition. It is during these exercises that the services definitions can often be best viewed. As implementation considerations are addressed, more detailed views of building blocks can often be used to address implementation decisions, focus on the critical strategic decisions, or aid in assessing the value and future impact of commonality and re-usability.

Building Block Specification Process in the ADM

The process of building block definition takes place gradually as the ADM is followed, mainly in Phases A, B, C, and D. It is an iterative process because as definition proceeds, detailed information about the functionality required, the constraints imposed on the architecture, and the availability of products may affect the choice and the content of building blocks.

The key parts of the ADM at which building blocks are designed and specified are summarized below.

The major work in these steps consists of identifying the ABBs required to meet the business goals and objectives. The selected set of ABBs is then refined in an iterative process to arrive at a set of SBBs which can either be bought off-the-shelf or custom developed.

The specification of building blocks using the ADM is an evolutionary and iterative process. The key phases and steps of the ADM at which building blocks are evolved and specified are summarized below, and illustrated in Key Phases/Steps of ADM at which Building Blocks are Evolved/Specified .

Figure: Key Phases/Steps of ADM at which Building Blocks are Evolved/Specified

In Phase A the earliest building block definitions start as relatively abstract entities within the Architecture Vision.

In Phases B, C, and D building blocks within the Business, Data, Applications, and Technology Architectures are evolved to a common pattern of steps:

• Step 1, Baseline Description produces:
  • A list of candidate building blocks, from the analysis of the baseline
• Step 3, Target Architecture Model, takes this list and high-level model as inputs, and evolves them iteratively into a definition of the Target Architecture, specified in terms of ABBs. Specifically, Step 3 produces:
  • A high-level description and broad model of the target system in terms of ABBs
  • A rationale for each building block decision
• Step 4, Services Portfolio, produces:
  • For each ABB, a service description portfolio, built up as a set of non-conflicting services
• Step 5, Business Goals and Objectives, produces:
  • A confirmation of the merit and completeness of the model and service description portfolio, and a description of how the emerging Target Architecture meets the objectives of the architecture development
• Step 7, Architecture Definition, produces:
  • A Target Architecture, fully specified in terms of ABBs
  • A fully defined (by service) list of all the standards that make up the Target Architecture, and all the ABBs that will be used to implement it
  • A diagrammatic depiction of the building blocks at the levels needed to describe the strategic and implementation aspects of the architecture
• Step 8, Gap Analysis, produces:
  • A gap analysis of eliminated building blocks, carried over building blocks, and new building blocks

Finally, in Phase E the building blocks become more implementation-specific as SBBs, and their interfaces become the detailed architecture specification. The output of Phase E is the building block architecture, both in ABB (i.e., functionally defined) and SBB (i.e., product-specific) forms.

The minimum contents of an ABB specification and a SBB specification are described in Introduction to Building Blocks .

Levels of Modeling

Defining and developing the context for a set of building blocks takes place at two levels:

• The business process level (colored green in the diagrams in this section). This deals only at the highest level with what has to happen for a business process to be carried out.
• The technical functionality and constraints level (colored blue in the diagrams). This level deals with the component activities that form part of the business process and whether they can be supported or not.

Defining and developing an actual set of building blocks also takes place at two levels:

• The architectural model level (colored red in the diagrams). This level identifies the systems and components that will implement the technical functionality and expresses the relationships between them. This level introduces the idea of a notation to describe the architectural elements and relationships.
• The solution model level (colored black in the diagrams). This is the level where the individual products and/or product components that will implement the architecture are identified.

Working through the four levels is an iterative process. Iteration between the Four Levels of Modeling shows how considerations at any level can result in change at any or all of the other levels.

Figure: Iteration between the Four Levels of Modeling

Mapping the Modeling Levels to the ADM

The Business Process level of definition takes place in Phases A and B of the ADM.

The Technical Functionality and Constraints level work happens early in Phases B, C, and D, once the characteristics of the current system have been established. At that stage it is possible to identify the constraints imposed on new architecture work by the legacy of the old system (the baseline).

The Architectural Model and Solution Model levels consist of work done later in Phases B, C, and D, the Target Architecture steps of each phase, and Phase E. The Architectural Model work is mostly done when taking different views of the architecture, and the Solution Model work in Phase E, where selection of products and projects takes place.

To show how building block definition happens in practice, the remainder of this chapter consists of a fictional worked example. In this fictional example much detail has been left out in order to emphasize the process.

Building Blocks Example

Introduction

This and the following sections provide a detailed worked example showing how building block context is captured, how building blocks are identified, and how building blocks are defined when executing the major steps of the ADM.

Structure

The levels of modeling within the ADM are explained in Building Blocks and the ADM , and the example follows the structure of modeling explained there:

• Background to the Example (Background to the Example)
• The Business Process level (Business Process Level (Phase B))
• The Technical Functionality and Constraints level (Technical Functionality and Constraints Level (Phases B, C, & D))
• The Architectural Model level (Architectural Model Level (Phases B, C, and D))
• The Opportunity Identification level (Opportunity Identification (Phase E))
• The Building Block Re-use level (Re-Use of Building Blocks in Other Projects (Phases F to G) )

Background to the Example

In this example, a fictional company called XYZ Manufacturing has decided to improve the efficiency of its mobile sales force by replacing paper-based configuration and ordering systems with an IT solution.

The XYZ team have already done the preliminary stages of describing their existing system and reviewing it from a number of different viewpoints, and as a result have established a number of goals and objectives for the new system.

The principal goal is to give the sales force in the field direct access to the sales process back at base. This will allow sales staff to create and verify the product configuration, to check the price and availability of the goods, and to place the order while actually with the customer.

Other stages of the sales process - such as initiating the sale and determining the customer requirements - are considered to be outside the scope of this example.

Business Process Level (Phase B)

The inputs to ADM Phase B are:

• Request for Architecture Work
• Statement of Architecture Work
• Business principles, business goals, and strategic drivers
• Architecture principles
• Architecture Continuum
• Architecture Vision

The outputs of this step are:

• Statement of Architecture Work (updated if necessary)
• Validated principles, business goals, and strategic drivers
• Target Business Architecture
• Baseline Business Architecture
• Views corresponding to the selected viewpoints addressing key stakeholder concerns
• Gap analysis results
• Technical requirements (drivers for the Technology Architecture work)
• Business Architecture Report
• Updated business requirements

As a preliminary to this step it is necessary to define the scope of activity, including what is in scope, what is out of scope, what the limits are, and what the financial envelope is. Within this step fall defining the business process, recording the assumptions made, and developing any new requirements. The information collected is used to gauge the current system and to determine the return on investment of potential changes. Use-cases are a useful tool in this step to describe the business processes and they can be used to do a sanity check against the resulting architecture.

The business goals driving improvements in the sales process were:

• To improve the quality of the sales process
• To reduce the number of errors in the sales process
• To speed up the sales process

In this example, financial and time constraints and business return have not been dealt with in detail, but normally these constraints would be used to guide the process along the entire way to avoid over-engineering or "creeping elegance". The architect should especially look at these constraints whenever iterating between steps. Also not shown in this example are the use-case scenarios. However, the process described below does include participants, or actors, of the use-case with brief descriptions of their roles in Use-Case Table of Sales Process .

For the sake of brevity in this example, it is assumed that the scope of the architectural work would not extend beyond the sales arena, and that the proposed solutions fit within the financial and time constraints imposed by XYZ.

The assumptions made by the XYZ architect during Phase B are:

• To support the mission of the business, it is desired to have the sales person and the customer meet and interact face-to-face at the customer location.
• The model for such a customer visit should be two persons interacting using a shared PC.
• The sales person needs to be able to close the deal on-site, and then synchronize with information held at the sales base.
• There is a clearly-defined product set subject of the sales process; e.g., there is a car to buy.

The relevant business process in scope of this example in the XYZ company is the customer-facing portion of the sales process and the supporting systems. This sales process consists of the following steps:

1. Initiate the sales process with the customer:

   1.1

   Sales Person

   1.2

   Customer

2. Discuss the customer requirements:

   2.1

   Customer

   2.2

   Sales Person

3. Work with the customer to create a product configuration:

   3.1

   Sales Person

   3.2

   Sales Person's Laptop

   3.3

   Sales Person's Local (LIPR) and Central (CIPR) Information Process Resources

   3.4

   Product Configurator

   3.5

   Customer

4. Verify that the desired configuration can be delivered:

   4.1

   Sales Person

   4.2

   Sales Person's Laptop

   4.3

   Inventory Control System

   4.4

   Scheduling System

   4.5

   Customer Accepts or Rejects

5. Determine the price of the requested configuration:

   5.1

   Sales Person

   5.2

   Sales Person's Laptop

   5.3

   Pricing System

6. Confirm the desire to purchase with the customer:

   6.1

   Sales Person

   6.2

   Customer

7. Place an order:

   7.1

   Sales Person

   7.2

   Sales Person's Laptop with Printer (for Fax)

   7.3

   Order System

   7.4

   Customer

8. Customer acceptance:

   8.1

   Sales Person

   8.2

   Customer

The following use-case table represents participants (sometimes referred to as "actors" in use-cases) in the rows, steps of the business process in the columns, and roles in the cells. Note that this is an example, and it is not intended to be accurate, but rather demonstrative. Constructing a use-case table is a comparatively small effort that will ultimately enhance the speed and quality of the resulting architecture.

The meanings of the various acronyms used in the table, and in subsequent figures, are listed below:

CIPR

Central Information Processing Resource

ICSys

Inventory Control System

LIPR

Local Information Processing Resource

OrdSys

Order Processing/Information System

ProdConfig

Product Configurator System

ProdSys

Product Information System

SchSys

Scheduling System

$Sys

Pricing Information System

		2:Discuss	3:Create	4:Verify
	1:Initiate	Reqmts	Config	Config	5:Price	6:Confirm	7:Order	8:Accept
Sales Person	Greets customer.	Listens.	Represents options with different capabilities.	Accesses ICSys and SchSys and presents availability to customer.	Accesses price system and presents price to customer.	Presents offer.	Accesses order system.	Presents contract.
Customer	Accepts sales person.	Discusses problems/ desires.	Listens and decides on options based on capabilities.	Accepts or rejects.		Accepts or rejects.		Signs or rejects.
Sales Person's Laptop			Interacts with configurator.	Interacts with ICSys and SchSys.	Interacts with price system.		Interacts with order system and receives fax response.
Sales Person's CIPR			Provides central information processing.
Sales Person's LIPR			Provides local information processing.
ProdConfig			Presents configs to sales person per needs, providing capabilities.
ICSys				Provides availability.
SchSys				Provides delivery date.
$Sys					Provides price information on a config.
OrderSys							Processes order and sends fax of order to sales person's laptop.

Table: Use-Case Table of Sales Process

Steps 1, 2, 6, and 8 are not within scope of the architecture work since the only participants involved are humans. The other steps are considered within scope since there are computing components involved in supporting the sales process. Note the computing participants are the first set of identified candidate building blocks - Business Process-Driven List.

During Phase A, the business goals were developed into more detailed business requirements, and these were:

• To improve on the current turnaround time of 48 hours for order processing
• To reduce the number of errors in orders by a factor of three

A very simplified view of the candidate building blocks required to support the business process with an idea of location is provided below. This model was built from elements of the above table.

Figure: Model of the Candidate Building Blocks: Business Process-Driven List

Technical Functionality and Constraints Level (Phases B, C, & D)

The objective of the first step in Phases B, C, and D of the ADM is to build a high-level description of the characteristics of the current system, re-usable building blocks from the current system, the technical functionality needed to address the business problem, and to identify additional constraints. This is necessary as the description documents the starting point for architectural development and lists the interoperability issues that the final architecture will have to take into account. Potential re-usable building blocks may be contained in the existing environment. They are identified in this step.

The best approach is to describe the system in terms already used within the organization. A reliable picture can be built up of the business functions served and the platforms which support those functions. Gather and analyze only that information that allows informed decisions to be made regarding the Target Architecture.

The inputs to this step are:

• Descriptions of the current system
• Information on the existing architecture
• Model of candidate building blocks

The essential outputs from this activity are:

• A clear description of the current system and its functions
• A statement of the constraints imposed by the internal organization
• A statement of the constraints imposed by the business or external environments
• Architecture principles embodied in the current system
• Assumptions of required technical functionality
• Candidate building blocks - Baseline-Driven List
• Model of candidate building blocks (see Candidate Building Blocks from the Baseline-Driven List )

The key input to this step is the existing architecture. In this example, a depiction of an existing architecture is shown in XYZ Existing Architecture . Additionally depicted in this architecture model are pointers to existing problems with the existing architecture. These pointers are used by the architect to determine where existing components are failing, and where existing systems can be re-used.

Figure: XYZ Existing Architecture

It is necessary to record existing strategic decisions about the existing architectural and technological issues such as:

• The existing architecture is founded on the mainframe.
• Databases are tied to application logic.
• Security is embedded in the application.

The next step consists of restating the business process, considering what functionality will be required, and deciding what constraints apply. Decisions at this stage are not definitive, but act as input for the following steps and iterations.

The architects of XYZ identified the following pieces of technical functionality as necessary to support the business processes. This list was produced using standard brainstorming techniques.

Assumptions of Required Technical Functionality

• Access to central functions
• Application support for simultaneous access by multiple sales persons through multiple connections
• Execution of local functions at the point-of-sale
• Access to product information
• Entering and checking the required product configuration
• Access to customer information
• Access to price information
• Order entry
• Order acceptance
• Delivery of confirmation of order to the customer
• The process must be secured

Also in the brainstorming session, some assumptions were made and therefore must be documented as they should be used throughout the process:

• Initiation of the sales process and determination/agreement of the customer requirements were outside the scope of the current work.
• Functionality could be distributed between the point-of-sale and a central base.
• Closure of the order should take place at the central location.
• The price list and product information could be made available electronically.
• Access could be provided to the acceptance and confirmation of order systems.
• The ordering, product information, and price information systems could be linked together.

One constraint was put on the development because XYZ already had systems in place to support the sales process:

• Existing systems should be used to support product information, order placement, and customer information.

Figure: Model of Candidate Building Blocks Augmented with Technical Functionality

The above model is scrutinized and questions are asked about the functionality that could be provided by the existing system. Candidate Building Blocks from the Baseline-Driven List depicts the set of candidate building blocks from the existing system, resulting from this question.

Figure: Candidate Building Blocks from the Baseline-Driven List

Architectural Model Level (Phases B, C, and D)

In Phases B, C, and D a number of different architecture views are considered and used to build up a model of the new architecture. At XYZ, the Architectural Model level was developed in the following steps:

1. A Baseline Description in the TOGAF format
2. Consider different architecture views
3. Create an architectural model of building blocks
4. Select the services portfolio required per building block
5. Confirm that the business goals and objectives are met
6. Determine criteria for specification selection
7. Complete the architecture definition
8. Conduct a gap analysis

In executing Step 1, the existing architecture was assessed:

• To describe the architecture principles of the existing architecture
• To describe the existing architecture in TOGAF terms
• To identify new requirements, inhibitors, and opportunities

Figure: Existing Architecture in TOGAF Terms

Notice how in Existing Architecture in TOGAF Terms and Future Architecture of Functions the legacy systems supporting the price list, product info, and order acceptance applications are easy to handle as monolithic building blocks. Augmented Future Architecture of Functions , Representation of XYZ SOAP System , and Services Map show they can be connected to new building blocks using adapters.

In Step 2, the function view was examined based upon what the system was intended to do, and how it should behave. The function view is depicted in Future Architecture of Functions . Note that the inventory control and scheduling system are not covered.

Figure: Future Architecture of Functions

In executing Step 2, a view of the future architecture was created by processing the technical functionality that must be provided and by:

• Identifying obvious additions
• Identifying what would be carried forward from the old system
• Determining the return on investment for various options, allowing them to be ranked
• Assessing the risk of the various changes
• Checking the coverage of the technical functionality
• Adding technical functionality required for completeness, checking against the TOGAF Technical Reference Model (TRM)
• Updating and clarifying the business requirements and technical functionality
• Iteratively adding precision and detail to the future architecture
• For each architectural decision, completely following through the impact of it
• Noting the rationale for each decision whether the answer was yes or no, so as to avoid reopening old issues later

Figure: Augmented Future Architecture of Functions

Augmented Future Architecture of Functions shows how the constraints identified in the earlier technical functionality and constraints work have been incorporated. It was necessary to retain the existing systems for order handling and product information. The initial constraint list also included retaining the existing system for customer information, but this was overridden by the need to improve the quality of the sales process and a new system is proposed to deal with this. Return on investment is the driving force behind the decision to retain the existing system for price data. Quality problems with the price system highlighted in XYZ Existing Architecture will be resolved through a single metadata definition and rules for synchronization as shown in Future Architecture of Functions . These legacy systems are integrated into the new SOAP (Sales Order Application) by developing adapter software. The following describes the SOAP application.

• SOAP consists of two parts. SOAP1 runs at the central site, and SOAP2 on a portable system carried by the sales person. Communication between the two is carried by a reliable transport (TCP/IP and RAS), and includes security provided by a firewall. Asynchronous messaging is also provided. Fax services are required at the central site so as to provide the customer with written confirmation of acceptance of the order. Data synchronization services are needed to keep the sales person's portable systems and the central systems up-to-date with each other. Iteration of the architecture development process to validate the results against the business requirements is helped by considering detailed "use-cases". For instance, consider the activity of verifying an entered configuration.
• Entry is handled by SOAP2, running on the sales person's portable system. SOAP2 must deal with:
  • Establishment of the link to SOAP1:
    • Physical link
    • Protocols
  • Security check
  • Direct information request to the proper database
• Then, at the central site:
  • SOAP1 contacts the configurator.
  • The configurator:
    • Reacts to the named request
    • Gets information from the price, product information, customer information, and production systems
    • Determines the yes or no result
    • Returns to SOAP1
  • SOAP1 returns the result to SOAP2.
• All of the separate elements in the use-case must be supplied by the Solution Architecture. Another way of refining the developing architectural model is to use the architecture views:
  • The Computing view is often the default.
  • The Data Management view is often useful.
  • The Security and Management views are of growing importance.
  • Performance is an important consideration both on the existing architecture to discover the underlying assumptions and on the future architecture to document the assumptions and provide a basis for change in performance limits. Performance should be addressed in a number of views, including the Computing, Communications, and Builder's views.

To ensure that building blocks are as re-usable as possible, detailed information is needed about the building block. For this reason it is helpful to take views of individual building blocks and not just of the complete system. For the maximum benefit, it may be necessary to take views of both ABBs and SBBs.

It is the responsibility of the architect to foresee the integration of any application with the rest of the enterprise regardless of the isolated position of the application today. This future integration is facilitated by complete definition of building blocks. It is the responsibility of the business unit to implement in accordance with the rules of the architecture.

Step 3 consists of creating an architecture model of building blocks. Augmented Future Architecture of Functions depicts a future architecture model of functions, but does not express the relationships and interfaces between the elements in the architecture model. As the architectural development process continues, it becomes important to define a manageable granularity for building blocks and to fully define their linkages. Without this work there is no guarantee of interoperability between the various building blocks chosen.

We have identified two lists of candidate building blocks in the above steps. Prior to building a model of building blocks, these lists are processed and some candidates become recommended building blocks.

Candidate Building Blocks:	Candidate Building Blocks:
Business Process-Driven List	Baseline-Driven List
Sales person's laptop	Price list application, data, and platform
Sales person's CIPR	Product information and platform
Sales person's LIPR	Order acceptance application, data, and platform
ProdConfig
ICSys
SchSys
$Sys
OrderSys

Table: Candidate Building Blocks - Lists

The process of identifying building blocks includes looking for collections of functions which require integration to draw them together or make them different.

First, it is recommended that the candidate building blocks from list B be selected as building blocks because they are re-usable legacy items. With these, a building block containing all the adapters is identified given the affinity of similar logic; e.g., providing the network adapter functionality on behalf of all the legacy applications.

Next a network building block appears to be required as it is a new network that must be built or purchased and is independent of the applications implemented. It itself can be a re-usable building block for other applications.

The laptop with the SOAP2 application is identified as a building block because it is a modular pack of functionality specially built with applications and data tightly integrated for the mobile sales force. However, a RAS-capable firewall was also identified as a separable building block.

The new customer information system is also identified as a re-usable building block given its applicability across applications past, new, and future. The SOAP1 and configuration systems were identified as two additional building blocks.

We depict the ABBs at a high-level in Representation of XYZ SOAP System .

Figure: Representation of XYZ SOAP System

Representation of XYZ SOAP System presents a relationship view of the system. Compare this with Augmented Future Architecture of Functions , a functional view, to see how different diagrammatic views of the same system can be used to show different things.

In executing Step 3, the future architecture was created by processing the technical functionality that must be provided and:

• Diagrams of larger systems drawn with this notation quickly show what interfaces are needed between building blocks and which ones need to be identical to realize interoperability benefits.
• Representation of XYZ SOAP System clearly shows where and how glue software is required to bind the legacy systems to the new network.

Step 4 is to select the services portfolio required per building block. Services Map depicts the services mapped to component in the architecture model.

Figure: Services Map

Step 5 in the process is to confirm that the architecture supports the business goals and objectives. This is a relatively subjective task of answering the questions developed in Step 1. In this example, we did not establish a set of questions that would be used to test the architecture, but such questions (and how to pose them in light of the architecture) could easily be envisioned. For example, one question could be: "Does the architecture prohibit the immediate processing of an order by a customer?" which would be answered "no" in our case above.

The use-cases developed earlier are a handy tool to test the completeness and applicability of the architecture and its building blocks.

Building block specifications should be recorded in detail. An example of a building block specification document is given in Customer Information System Building Block Specification .

Where an enterprise architecture exists or is being developed, it may be valuable at this point to review the new set of building blocks. Anything of benefit to the wider enterprise should be abstracted back to an architectural level and then fed back into the enterprise architecture development process.

Step 8 is to conduct a gap analysis, and is not covered in this example.

Customer Information System Building Block Specification

Description

This system is put in place of the existing paper-based customer information system to support the goal of improving the speed and quality of order closure. It shields the database from the complexity of the many applications looking at it but it contains an architectural break-point which could be used later on to make the database itself accessible to other applications.

The interfaces selected must go through an internal approval process modeled on the interface adoption criteria of The Open Group. This means that all specifications must be or become part of the corporate Standards Information Base (SIB).

Functionality		Interfaces - APIs,
Category	Functionality	Formats, & Protocols	Product or Project
CIF Application Code	Respects metadata repository spec	User-defined	User-defined
	Implements business rules	User-defined	User-defined
	Has remote access by SOAP and configurator	DCE RPC	See SIB
	Uses SQL	ANSI SQL
		CLI
	Uses UNIX	UNIX 95
Open DB Services	Relational	Codd
	Supports concurrent access	Codd
	Offers SQL	ANSI SQL
Open Security Services	Single sign-on
	Authorization	DCE
	Authentication	DCE
	Integrity
	Audit	DCE
	Non-repudiation
Open Operating System	UNIX	UNIX 95
Network Services	Existing internal network	User-defined	User-defined
Open TP	Multiple concurrent access	The Open Group XA
	Load leveling
+Performance	50 enquiries per second
+Manageability	Online software update
	Service-level data provision	DMTF Spec
	Integration into enterprise management system	TBD
+Availability	24 by 7 by 52

Mandated Building Blocks

Building		Required	Named Used
Block Name	Owner	Functionality	Interfaces
Enterprise Management	Corporate IT	Service-level data
System		handling
		Integration - TBD
Enterprise Network	Corporate IT
CIF System	Marketing

Map to Business Organization Entities and Policies

Policy	Entity	Remarks
Security	Corporate admin
Audit	Corporate admin
Development and deployment	Corporate IT
Metadata definition	Corporate IT
Data quality	Corporate IT
IT architecture	Corporate IT
Corporate SIB	Corporate IT	This is linked to The Open Group SIB.

Opportunity Identification (Phase E)

This is the step where projects are identified, ranked, and selected.

The steps illustrated above have laid the foundation for this analysis. Augmented Future Architecture of Functions , for instance, shows the SOAP applications, the reliable transport, the adapters, and the new customer information system as potential projects.

Re-Use of Building Blocks in Other Projects (Phases F to G)

In ADM Phases F to G, the choice of building blocks may be affected by outside events, such as a change in the availability of products. They can also affect and be affected by issues such as the cost of retraining users during migration from one product to another. Perhaps the most important impact though is the effect that building block choice can have on other work in progress within an organization. This section shows how a diagrammatic representation of the building blocks in a system can be used to identify or prioritize future projects.

An important benefit of defining the building blocks and their linkages is that it becomes possible to pick out re-usable components in the architecture. The best way to do this is to draw up a matrix of the building blocks used in an architecture and the applications that use them. Such a matrix for a simple subset of the XYZ case is shown in Simple Component/Application Matrix .

Figure: Simple Component/Application Matrix

Careful ordering of the building blocks in the left-hand column allows the architect to identify subsets of functionality common to a number of applications. Identifying Common Functionality shows such a subset. In this case the subset of platform, network, and customer information database gives a strong indication that the configurator, SOAP1, and customer information applications should be hosted on the same platform.

Figure: Identifying Common Functionality

Such identifiable subsets of building blocks also serve another purpose, which is that they can draw attention to opportunities for component re-use. If in the future XYZ decides to implement a customer care system, adding that into the matrix reveals that there would be significant advantages to building the customer care system on the same building blocks used for the configurator, SOAP1, and customer information applications.

Figure: Using the Matrix to Steer Future Procurement

The key to success in working with building blocks is to establish a useful level of granularity. Too much detail in the chosen set of building blocks will make the architecture unworkable, while too coarse a level of detail will make the work valueless.
return to top of page

---

Navigation

The TOGAF document set is designed for use with frames. To navigate around the document:

• In the main Contents frame at the top of the page, click the relevant hyperlink (Part I, Part II, etc.) to load the Contents List for that Part of the TOGAF document into the Secondary Index frame in the left margin.
• Then click in that Contents List to load a page into this main frame.

return to top of page

---

Downloads

Downloads of the TOGAF documentation, are available under license from the TOGAF information web site. The license is free to any organization wishing to use TOGAF entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A hardcopy book is also available from The Open Group Bookstore as document G063.

---

Copyright © 1999-2006 The Open Group, All Rights Reserved
TOGAF is a trademark of The Open Group

---

riverafiresom1957.blogspot.com

Source: https://pubs.opengroup.org/architecture/togaf8-doc/arch/chap32.html

Share this post