Overview
The software architecture discipline is centered on the idea of reducing complexity through abstraction and separation of concerns. Even though the discipline has significantly matured over the past 20 years, it's hard to find architects who easily agree on the right way to architect. There is no clear guidance on how to architect and an architect must use judgment to decide on the level of detail that must be exposed or hidden in order to explain to various audiences how a system will address key business drivers.
There is no standardized definition of software architecture, but there is no shortage of notable interpretations. The SEI has documented & catalogue hundreds of definitions. The philosophy of SoftwareArchitectures.com aligns well with the definition from the Software Architecture in Practice, Second Edition: The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. However, Eoin Woods' definition eloquently gets the point across: Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be canceled.
Software Architecture Explained
The field of Software Architectures deals with the issue of complexity by defining a software system from an abstract point of view. Breaking a problem into smaller parts makes it easier to analyze separate entities and the relationships between them.
The architecture of a software system defines the overall structure in terms of components and interactions among components. A component, or a module, can be identified as a well defined unit that performs some function. An example of a component is a database or some object. Interactions among components occur through connectors such as a procedure call, or some protocol. Finally, properties of a component specify how a connection with other components can be made via a connector.
Muting insignificant details allows for development of a series of blueprints that show the overall structure of a system from different perspectives. Just like a plumbing and an electrical blueprint of a building are different, the static and dynamic views of a software system convey a different meaning.
Quality Attributes
The logical reasoning behind component breakdown and the relationship between the components is not coincidental. Delivering just the functionality of a system is only half the battle. It’s important to address the way functionality is designed, developed, and delivered as two systems with the same functionality requirements may have different quality needs. For example, if one system has to be distributable across multiple platforms and the other system must run exclusively on Windows Server platform, then the architectural decisions made in each case will be different.
Architectural Styles
Like physical structures that are designed to serve a specific purpose, software systems are also designed to live up to their expected behavior as defined by user requirements. Over the years software practitioners realized that a certain system design is more suitable in one situation and is not acceptable in another. The observed commonality has been loosely “codified” by the practitioners and codified. An architectural style, or an architectural approach, is usually one of the earliest decisions an architect makes as some architectural styles can be ruled out by vague requirements such as “a system must process data in real-time.”
Software Development Lifecycle and Software Architectures
Software architecture work can start as soon as solution vision has been stabilized and an initial set of high level requirements is known. As more information elicited, system & software architecture is revisited in an iterative fashion. Most of the architectural work is done during requirements gathering and early design stages. At that time a certain set of tests is run to ensure that the overarching architectural style chosen will live up to the expected behaviors of the system. Architecture is referenced by the designers, developers, and testers throughout the lifecycle of a product. When a major change request occurs, such as a change that requires modification of multiple components, architecture of a system is consulted to gain visibility as to how a modification should be made. To put it anothe way, software architecture becomes a unified communicaiton mechanism to facilitate conversations among business and technical stakeholders.
Early Years
The field of computer science has come across problems associated with complexity since its formation. Earlier problems of complexity were solved by developers by choosing the right data structures, developing algorithms, and by applying the concept of separation of concerns. Although the term “software architecture” is relatively new to the industry, the fundamental principles of the field have been applied sporadically by software engineering pioneers since mid 1980s. Early attempts to capture and explain software architecture of a system were imprecise and disorganized - often characterized by a set of box-and-line diagrams. During the 1990’s there has been a big push to define and codify fundamental aspects of the discipline. Initial sets of design patterns, styles, best practices, description languages, and formal logic has been developed during that time.
Benefits of Investing in Software Architectures
Designing a set of blueprints for a software system makes sense, but what is the return on investment? How is the bottom line improved as a result of investment in software architectures? The first clear benefit of investment in architectures is organization’s ability to deliver a system that behaves as expected. By going through the architecture design process hard questions are raised and answered. For example, how a system will address the issues of security, throughput, availability, and modifiability, will be addressed before code is written. The second benefit of architectural view is visibility into further module decomposition that provide reference framework to developers, testers, and maintainers. Thirdly, architecture of a system (using tailored views for give audience) becomes a unified communications vehicle between various stakeholders. And finally, the maintenance of a product will be easier, as software architecture will provide a developer the “map” of the system that will help with localization of a problem.
