This is important for architects because… this is a fundamental definition of the profession.
Software architecture is often defined in different ways, but experienced practitioners can give consistent definitions.
Why is architecture difficult to define? As with most information technology roles, there are no required certifications for software architects. There is also very little in terms of formal training. The title is often given to or claimed by people that are neither doing the work nor have the requisite experience.
What architecture is not… Because software architecture is unregulated and defined in many different ways, it is important to establish what architecture is not as well as what it is. We will point out some common misunderstandings below.
Simple definition. The software architecture of a system is the set of structures needed to reason about the system. These structures are software elements, relationships between them, and properties of both. Software architecture tasks include design, analysis, documentation, and implementation of the abstract elements and behaviors of software systems in a way that bridges business goals with implemented systems, especially through specification of the attributes of those software elements and behaviors.
Broadest definition. The broadest definition of software architecture includes anything that allows us to manage the complexity of the system. This is not a useful definition, but it does suggest that any work that is not design, analysis, documentation, or implementation, but does contribute to managing complexity could be considered part of the job description of the architect.
Is Software Architecture Necessary?
Definitely. There are, of course, some systems – simple computer programs – for which a lot of work on design, analysis, and documentation is not strictly necessary. Nonetheless, even simple software systems are designed and have an architecture. It may not be a good architecture and it may not be understood, but architecture does exist for all systems. The real question is about how much design, analysis, and documentation is necessary for the system. For small systems, formality may not be necessary, but the architecture still exists even if it is only expressed through the source code.
Architecture and Agile? This is sometimes a misconception that architecture is not required for Agile projects. The rationale for this belief is that with an Agile methodology, the decisions are not made in a “waterfall” method with Agile, but the decisions that get made along with sprint planning are nonetheless architecture decisions. Architecture is independent of the software lifecycle methodology.
KEY POINT: All software systems have an architecture.
Elaboration of the Definition
Definition. To restate our definition above, “The software architecture of a system is the set of structures needed to reason about the system, which comprises software elements, relationships between them, and properties of both. Software architecture is the design, analysis, documentation, and implementation of the abstract elements and behaviors of software systems in a way that bridges business goals with implemented systems, especially through specification of the attributes of those software elements and behaviors.”
Business Goals. Software architectures are used to satisfy business goals. These business goals typically include goals that generate revenue, satisfy customers, and deliver product to market faster. Architecture is the bridge between those business goals and the finished systems. Nonfunctional quality attributes are the main bridge between those business goals and finished systems.
Design. The design of the system is the specification of the software elements, the relations between them, and the systems behaviors. There is a common misconception that the design of a system is what software architecture is all about. While design is the most important of software architecture skills, without the other skills the designer is probably a good senior developer, but is not really an architect.
Analysis. Analysis is probably the most difficult of software architecture tasks. To be clear, we are not talking about “business analysis” where we map requirements onto software features. While an organization typically has “business analysts”, mapping requirements onto features is more of a design function. The analysis we are referring to in the software architecture context is technical analysis. Such technical analysis is typically applied to determine the structure and behaviors of existing systems.
Why is analysis so difficult? The analysis of existing systems should be straightforward, but this is rarely true in practice. Analysis becomes more difficult as systems scale in size, complexity, and importance. There will typically be many technologies employed that no one single person can understand, the rationale for design decisions may not be understood, and systems are often undocumented. Perhaps most importantly, systems are often broken in fundamental ways and the organizational concerns around such analysis are often profound.
Documentation. Documentation is probably the easiest of the typical architecture tasks, but it is easily the least fun. Learning how to document software architectures properly is perhaps the fastest way for a senior developer to advance their career, but most senior developers detest creating documentation.
Implementation. Implementation skills are strictly necessary for a legitimate software architect. The architect must be a proficient developer, typically as proficient as the senior developers on staff. There are those who call themselves architects who do not have coding skills. Perhaps they are good managers, analysts, or contribute well in some other way, but if you are not a good coder, then you are not a legitimate software architect.
Completeness. While we do want to be careful not to add too much information to an abstract model of a system, we equally want to be certain that we are not omitting too much detail. Example: A “box and line” drawing is often a good start at describing an architecture, but it is not a complete architecture.
KEY POINT: All real architects are developers as well. If you can’t write code, you may have a software architect title, but you aren’t really an architect.
Types of Software Structures
There are broadly three types of software structures – modules, runtime structures, and allocation structures.
Modules/Code. “Module” is an overloaded term and is often understood to be a file of compiled code. In our context, however, we are referring to any implementation unit that has specific computing responsibilities. This could be application code, a database, or a web service. The key distinction is that it is an implementation unit that needs to be developed.
Runtime structures/communications. Runtime structures are those that are created dynamically to support the system’s behavior while the code is executing. That is, runtime structures are used to allow the modules, mentioned above, to interact with each other.
Allocation structures/deployment. We have already covered code structures and the communications among the code structures. “Allocation” structures are defined allow for the system’s organizational, software development, installation, and execution environments. It might seem to a developer with limited experience that these are not critical concerns, but as a system scales in size and complexity, allocation structures become increasingly important. In fact, for the largest systems they are often the dominant concern.
Example of allocation structures. Consider an organization that has Angular and MVC clients, Java web services, a SQL Server database, Microsoft Windows Server infrastructure, and leverages third-party services. The implementation work would likely be allocated among five different teams with five different skill sets installed by five different procedures and running on five different pieces of infrastructure. These allocation structures should be specified as part of the architecture.
KEY POINT: There are three key ways of defining software structures, including module, runtime, and allocation structures.
What is an “Architectural” Structure?
We have defined architecture as a set of software structures and behaviors and what a software structures are, but it is important to define which structures are “architectural”. We need to know how much to analyze, how much to design, and how much to document. Just as importantly, we need to know when to stop with these activities.
Easy to Identify. Software structures are typically easy to identify, but not all software structures are “architectural” structures. A structure is “architectural” if expressing that structure in the design allows reasoning about the system in an abstract way. When we leave the abstract level and discuss the implementation level, the structures we are examining are no longer “architectural”.
We are “reasoning” about “quality attributes”. The reasoning about the system – things that enhance our understanding of the system in an abstract way – should be about system functionality and “quality attributes”. We often refer to these as “functional” and “nonfunctional” requirements, respectively. Quality attributes are things that customers may not notice or think about, but are nonetheless important.
Example of quality attributes. If we were designing a physical building, the rooms, the landscaping, and the elevators would be the system functionality, but fireproofing, noise management, ease of maintenance, security, and energy efficiency would be the quality attributes. Those who are in the building every day typically don’t notice the building’s quality attributes.
“Internal” elements. We can reason about structures at different levels. Structures that are internal to a particular element, however, are not architectural if they do not contribute to our abstract understanding of the system at a particular level. Example: We could specify the design of a system down to compiled machine code, but that clearly would not help us understand the system generally.
KEY POINT: A structure is “architectural” if it supports reasoning about the system and the system’s properties. Omit information that does not allow for reasoning about the system’s quality attributes.
System Architecture and Enterprise Architecture
Another complication with defining software architecture is that there are other IT specializations that have legitimate “architects”. Keep in mind that our definition calls for specification of elements of an entire system in an abstract way. In addition to software architects, other types of architects that fit that definition are system architects and enterprise architects.
System architecture. System architects are typically concerned with mapping of functionality onto hardware and software components. They are also concerned with human interaction, often referred to as UX, but that may also fall under the software architect.
Enterprise Architecture. Enterprise architects are typically concerned with supporting the organization’s core goals and strategic direction. They could also be described as “business architects”. This should not be confused with business analysts who typically specify individual features in detail. The role of the enterprise architect is often part of the job of the “Product Manager”.
Can’t work in isolation. If you are introducing a software system, you need all three types of architects working together. One person may be holding all of the roles or perhaps two of the roles, but it is unrealistic to suggest that any of the three roles could exist without the others. Example: When designing a system, issues such as power consumption and physical placement of servers must be considered. These would be key points of negotiation between the software architect and the system architect.
Constraints on software architecture. It is critical for software architects to understand that the system architecture and enterprise architecture poses “constraints” or limits on what we can do with the software architecture. Failure to understand and work within the constraints imposed by the system and enterprise architectures will typically result in failure of the software architecture.
What about other types of architects? In the IT profession, “architect” titles are handed out pretty liberally, but except for software, system, and business architects, all of the other so-called “architects” are really just designing a simple component of a system rather than an entire system. For instance, a “database architect” would typically work on the database portion only and a “SalesForce architect” would work on the SalesForce portion only.
(1) Difficult to define. Software architecture is difficult to define. The definition needs to include what architecture is not as well as what it is.
(2) Managing complexity. Any activities that contribute to managing the complexity of a system may be considered part of a broader definition of architecture.
(3) Architecture is ubiquitous. All systems have architectures even if they are not documented architectures or good architectures.
(4) Key Tasks. The key tasks of a software architect include design, analysis, documentation, and implementation. If the person cannot write code, they are not really a software architect even if their position has such a title.
(5) Not too much, not too little. A proper software architecture is a “complete” and “abstract” description of the system’s elements at a certain level. The best test of completeness is whether or not the specification supports reasoning about both the functional and nonfunctional aspects of the system.
(6) Structural specification. A software architecture is a collection of specifications of module, runtime, and allocation structures.
(7) Agile and architecture. Agile methodology and architecture can coexist, but the architecture needs to be iterative as well as the implementation in an agile environment.
(8) System and Enterprise Architectures. Software architecture must coexist and be constrained by the system and enterprise architectures.