Chapter 3. Capturing Just Enough
Define the boundaries, and I will show you how to flourish even within them.
The preceding chapter highlighted some of the considerations to ascertain the importance of architecture in the development of any nontrivial system. You may have gone through the views and viewpoints in more detail or may have read about different architecture schools of thought around some of its other facets. Now you may be thinking, “What are the most essential architecture aspects that I need to focus on? Where do I start? When time comes for my next architecture assignment, will I be well prepared?” If that’s the case, I don’t blame you for such questions and thoughts.
The pivotal theme of this book is seeded in practicality—specifically to identify the areas in software architecture that are critically important and within each area to determine what is just enough to capture the essence of the task at hand. Follow the The PSA cult with conviction, contribute to, and shape it for adoption en masse!
This chapter highlights the architecture aspects I feel are just enough to be captured with commensurate time, effort, and due diligence, such that the software architecture of any nontrivial IT System will be conspicuous in its value and outcome.
Architecture Aspects in Focus
Any software architecture has multiple aspects, some of which have the potential of going into excruciating, often unnecessary detail (from an architecture standpoint). The trick is to be able to choose those aspects that not only provide adequate coverage of the various facets of the solution but also satisfy the need for effective communication with all the involved stakeholders. The choice also depends on the inherent complexity of the system that is being built and, of course, on your personal preference.
As mentioned, the theme of this book is to focus on just enough—to concentrate the architecture work effort in only the areas that I have found to be necessary and sufficient even in building the most complex systems.
The facets covered in this book are as follows:
• System Context—Documents how the IT System, which is typically represented as a black box, interacts with external entities (systems and end users) and defines the information and control flows between the system and the external entities. It is used to clarify, confirm, and capture the environment in which the system has to operate. The nature of the external systems, their interfaces, and the information and control flows are inputs to the downstream specification of the technical artifacts in the architecture.
• Architecture Overview—Illustrates the main conceptual elements and relationships in any software architecture described through simple and clear schematic representations. The architecture overview diagrams can be produced at different levels: an enterprise-level view, an IT System-level view, and a layered architecture view. These views help in representing the architecture artifacts supporting an IT System. This artifact provides high-level schematics that are then further elaborated and captured in the form of functional and operational models. It also depicts the strategic direction that the enterprise may be taking as it pertains to building IT Systems, specifically the system under consideration.
• Architecture Decisions—Provides a single consolidated artifact in which all the architecturally relevant decisions are captured. Decisions are typically made around, but not limited to, the structure of systems, the identification of middleware components to support integration requirements, the allocation of functions to each architecture component (or architecture building block, ABB), allocation of ABBs to the various layers in the architecture, compliance and adherence to standards, choice of technology to implement a particular ABB or functional component, and so on. Any decision that is considered architecturally important to satisfy the business, technical, and engineering goals is captured. Documentation usually involves the identification of the problem; evaluation of the various alternative solutions with their pros and cons; and choice of the solution, supplemented by adequate justification and other relevant details that are expected to help downstream design and implementation.
• Functional Model—Also known as the component architecture or model. It describes, defines, and captures how the architecture is deconstructed into IT subsystems that provide a logical grouping of the software components. This artifact describes the structure of an IT System in terms of its software components with their responsibilities, interfaces, static relationships, and the mechanisms in which they collaborate to deliver the required functionality expected of the system. This artifact is developed iteratively through various stages of elaboration.
• Operational Model—Represents a network of computer systems that not only support some of the system’s nonfunctional requirements (for example, performance, scalability, and fault tolerance, among others) but also run the middleware, systems software, and application software components. This artifact also defines the network topology that interconnects the computer systems. It is also developed iteratively through various stages of elaboration.
• Integration Patterns—Represents a set of most commonly used reusable patterns that focus on simplifying and streamlining the techniques by which the system under construction connects and communicates with other participating applications and systems. It leverages architecture patterns such as mediation, routing, transformation, event detection, message brokering, and service invocations.
• Infrastructure Architecture—Focuses on the development of infrastructure including servers, storage, hardware, workstations, nonapplication software, and the physical facilities that support the development, testing, deployment, management, and maintenance of the application.
It is critical to recognize that any system will render itself usable if it is right-performing. The infrastructure aspects must focus on making the system usable in relation to latency and turnaround time for user to system interactions, while ensuring that the computational capacity is right-sized to support both the functional and nonfunctional requirements.
Summary
The utopia of getting things to be just right eludes popular wisdom; it is something that is missing in most walks of life.
In this chapter I identified and described (albeit very briefly) only those aspects that are necessary and sufficient to develop any successful software architecture.
System Context starts by considering the IT System to be a black box and only depicts its connection and information exchange with other external applications and systems. Architecture Overview illustrates the architecture building blocks of the system, providing a first look at the system internals through the lens of an architect. The Functional Model provides a first look at a subsystem view of the architecture that not only describes a systematic grouping of functionality but also introduces the interfaces that each functional (that is, software) component exposes and consumes. The Operational Model addresses how the operational topology may be defined such that the functional components may be appropriately hosted on the operational runtime topology. Integration Patterns elaborates on the mechanisms and techniques for simplifying the integration with other applications, systems, and databases by identifying reusable and scalable techniques. Infrastructure Architecture focuses on the actual servers, hardware, networks, and their physical placement in data centers and facilities. Architecture Decisions is a critical piece of work that captures the thinking around the various alternatives considered during the problem-solving process of some specific areas of concern that require an architectural approach to problem solving.