How Context Architecture Helps to Describe an IT Application

Architecture provides the ability to describe an existing IT Application or architect a new IT Application. Best practices explain that architecture needs to be described using architectural views. Essentially, IT Applications can be perceived from the Business View and the IT View. The context architecture explained in this article is one of the views within the IT View.

In summary, the context architecture captures the IT Application details from a bird’s eye point of view, treats the IT Application as a black box, and describes the surrounding environment with enhanced details. Hence, it easily helps the stakeholders of a project (executive management, project sponsor, project manager, business architects, and IT architects) to understand IT Applications end-to-end at high level in a short time.

In this article, the context architecture is explained using a baseline scenario and two variant scenarios. The baseline scenario depicts a matured baseline version of context architecture and helps to derive variants specific to the problem in hand. The two variant scenarios depict context architecture for typical specific problem scenarios.

BASELINE SCENARIO: Figure 1 shows the context architecture model that captures the IT Application as a black box and surrounded by users and systems.

The lines are relationships, generally “association.” Unidirectional blue association arrows from internal/external users represent that “the users’ user interface devices play the role of client,” while the “IT Application plays the role of server.” Similarly, the red associations from IT Application represents that “the IT Application is playing the role of client” while “External System A and Internal System 1 play the role of server.” The gray association represents the pull and push of data through batch.

Note that the IT Application sits in a data center that belongs to the particular enterprise, for example here “XYZ Enterprise.” All those applications that belong to the XYZ Enterprise that are external to IT Application are called “Internal Systems.” All those users who work in XYZ Enterprise offices for XYZ Enterprise are called “Internal Users.” The table in figure 2 is used to describe the context architecture model in figure 1.

VARIANT SCENARIO 1: Sometimes there is a need to capture the context architecture at a still higher level than the baseline model that can cover the data center, etc. The typical context architecture model in figure 3 captures this scenario.

In figure 3, the IT Application is shown as “Application” and “Data.” This context captures the DC (Data Center) and DRC (Disaster Recovery Center). The DC provides online services to end users, hence DC Online. The DRC Nearline carries only snapshots of Data, while DRC Offline carries IT Application, but the Application part has reduced capability. A point-to-point connectivity is established among the DC Online, DRC Nearline, and DRC-Offline.

This architecture model is a typical context architecture that covers the DC/DRC for IT Application. It can be modified/extended to suit to your needs. For example, DRC Nearline is optional; the point-to-point connectivity is optional; etc. Use the table in figure 2 to capture the external entities “internal/external users” and “internal/external systems.”

VARIANT SCENARIO 2: Sometimes there is a need to capture context architecture for an IT Applications that ends up with multiple instances with respect to time zones. The typical context architecture model in figure 4 captures this scenario.

In figure 4, each country (or geographic location) has its own users and systems classified as internal and external to XYZ Enterprise (or World). In one of the Countries, the Data Center is maintained that has all the instances of “IT Application (Application & Data).” The Disaster Recovery Center is proposed in some other geographical location.

What is beyond context architecture? For each element in the context architecture, one has to provide nothing but more details, more details, and more details. This is possible through working on other architectural views. For example. the “Data” part of the context architecture needs to be handled through “information architecture (where data architecture is subset).” In another example, the “User Interface part of the Application” part of the context architecture needs to be handled through “UI Architecture/Usability Engineering,” etc.

by Venkata Rao Kadari, who has 19 years of experience in enterprise architecture. He is principal solution architect at Mahindra Satyam Ltd., India. He can be reached at venkata_kadari@mahindrasatyam.net or vkadari67@gmail.com.