Phases B, C, and D - the Architectural Model Level

In Phases B, C, and D a number of different architectural 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 architectural 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:

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

Figure J-6: Existing Architecture in TOGAF Terms

Notice how in Figures J-6 and J-7 the legacy systems supporting the Price list, Product Info and Order Acceptance applications are easy to handle as monolithic building blocks. Figures J-8, J-9 and J-10 show how 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 was depicted in the following figure. Note that the Inventory Control and Scheduling System are not covered.

Figure J-7: 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
• 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 J-8: Augmented Future Architecture of Functions

The future architecture diagram (Fig J-8) 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 Figure J-3 will be resolved through a single metadata definition and rules for synchronization as shown in Figure J-7. 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 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 reusable 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. The figure above 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.

Table J-2: 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 reusable 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 reusable building block for other applications.

The laptop with the SOAP 2 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 reusable building block given its applicability across applications past, new and future. The SOAP 1 and configuration systems were identified as two additional building blocks.

We depict the architecture building blocks at a high level in the following diagram.

Figure J-9: Representation of XYZ SOAP system

Figure J-9 presents a relationship view of the system. Compare this with Figure J-8, 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.
• Figure J-9 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. The following depicts the services mapped to component in the architecture model.

Figure J-10: 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 one could easily envision such questions and how to pose those questions in light of the architecture. 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. Here is an example of a building block specification document.

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.

The Opportunity Identification level

Copyright © The Open Group, 1998, 1999, 2002