- Prerequisite Review
- Discussion
- Understanding Architecture
- Role of the Architect
- Service-level Requirements
- Essential Points
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.1 Understanding Architecture
According to the Rational Unified Process:
"Software architecture encompasses the significant decisions about the organization of a software system. The selection of the structural elements and their interfaces by which the system is composed together with their behavior as specified in the collaboration among those elements. The composition of the structural and behavioral elements into progressively larger subsystems, the architectural style that guides this organization, these elements, and their interfaces, their collaborations, and their composition. Software architecture is concerned not only with structure and behavior but also with usage, functionality, performance, resilience, reuse, comprehensibility, economic and technology constraints and trade-offs, and aesthetic issues."1
That is a pretty lengthy definition, so let's look at a little simpler definition provided by the SunTone Architecture Methodology:
Architecture is a set of structuring principles that enables a system to be comprised of a set of simpler systems each with its own local context that is independent of but not inconsistent with the context of the larger system as a whole.2
Both definitions focus on system structure. You create an architecture to describe the structure of the system to be built and how that structure supports the business and service-level requirements. You can define the structure of a system as the mechanisms that the system employs to solve the common problems of the system. A mechanism is a capability that supports the business requirements in a consistent and uniform manner. For example, persistence is a mechanism that should be used consistently throughout the system. This means that any time the system uses persistence, it is handled in the same manner. By defining persistence as an architectural mechanism, you provide a default method of addressing persistence that all designers should follow and implement consistently. The architectural mechanisms, such as persistence, distribution, communication, transaction management, and security are the infrastructure on which you build the system and must be defined in your architecture.
What does it mean to create an architecture? It means that you have created a software infrastructure that addresses the service-level requirements that have been identified for the system. For example, if the system has a service-level requirement that states no user response time will be greater than three seconds, then the software infrastructure you create must ensure that the system can meet this requirement. It also means that you have given the designers an infrastructure that allows them to design and code the system without worrying about compromising this service-level requirement. One of the real issues around architecture is: When does the creation of an architecture stop and the design process begin? There is not a definitive answer for every system. This issue of architecture and design can be summed up in terms of focus and control. Architecture defines what is going to be built and design outlines how you will build it. Architecture is controlled by one or a few individuals who focus on a big picture and design is controlled by many individuals who focus on the details of how to achieve the big picture. An architect creates an architecture to a point where the design team can use it to make the system achieve its overall goals. So, if you are creating an architecture for experienced designers, you might not produce the detail that you would need if you had a group of less experienced designers.
As you create an architecture to satisfy the business and service-level requirements of a system, you usually don't have unlimited funds to purchase hardware, software and development resources, so you need to make the system work within your predefined limitations. For example, how can you make the system scale to meet the demands of the Internet age, when you have only a single computer to support your internal employees? How do you create an architecture without funds to buy software products? These are examples of problems faced by architects when they are creating a system architecture. You will be presented with many difficult choices and make many trade-offs to solve these types of problems. As you make these trade-offs, it is important that you document each decision made regarding the architecture of the system. If you make a decision to have an Oracle database persist the objects in the system, then you should document why you chose Oracle over another database vendor. This allows others working on the project or entering the project at a later time to understand why decisions were made and prevents you from justifying your decision over and over again. Most of the trade-offs you make when creating an architecture focus on the service-level requirements or mechanisms. Most systems do not have the funding available to meet all of the service-level requirements originally envisioned by the system stakeholders. So, you as the architect must balance the service-level requirements against the cost to attain these requirements. If it will cost your entire budget to buy high-availability hardware to achieve the 24x7 availability, thereby leaving no money to purchase an application server to help maintain that service-level requirement on the software side, you must make adjustments in your software architecture. These adjustments depend on the system for which you are creating the architecture and your relationship with the stakeholders.