Software Architecture Definition Dissection
Whenever we have a software project in hand, most of the time, it means we have encountered either a problem or an opportunity in a business domain. Regardless of the methodology and approach, we are using to manage the development process, we need to do some activities which RUP calls them Disciplines.
These engineering disciplines are Business Modeling, Requirements, Analysis and design, implementation, Test and finally deployments. There are many Principles, patterns and practices which are applicable in these disciplines. If we focus on these categories of activities following relationships reveals. After business modelling and requirements we have some stuff which we generally call them “Requirements”, but in a technical term, we need to clarify them to be more declarative and effective in next steps. These requirements are a collection of:
- Functional Requirements: What the software should do. For example, in an e-Commerce application the customers should be able to have a trolley to collect all the items they want to buy, or this system again the customer should be able to purchase their orders.
- None Functional Requirements: In which conditions and with what level of qualities the software should work. Maximum response time for the application for 10K concurrent request should be less than 1 sec.
- Constraint: What rules, principles and law should be considered to validate a solution? The project should be lunch before the New Year. Based on the customer organization IT strategic plan, development tools must be Java-based.
Last two types of requirements form the foundation of software architecture. As large scale software and the software development processes behave as complex systems, we need to control the complexity to make these systems more manageable, most effective strategy in managing complexity in software development is Divide and Conquer. It means to divide the software, the development steps to smaller steps to more manageable items and manage these parts relationship. Because having a web of communication between software elements without a supervision result in chaos. Here is where
architecture comes in. In a point of view Software architecture is the structures of the software’s structures and their relationships, and architecting a software means “making a decision about important things in the software points which changing the decisions are very hard, this tow must be done so that the quality attributes of the software which are stated in None Functional Requirements and the limitation on the solution in term of constraints should be considered.
Based on this definition when we talk about “Architecture in the software” we can divide the definition to focus on a different part of it. The term software architecture can be divided into three subcategories.
- Architecture Patterns/Style
- Reference Architecture
- Software Specific architecture
These categories are interrelated and affect each other, but for simplicity, I assume they have strict borders with each other.
When we use the word “Pattern” it means we are trying to create a new language for more effective communication which we transfer a large amount of information just using some specialized word. A sophisticated pattern language at least should have, the “Pattern Name”, the “Problem Statement”, “The solution imposed for the problems”, “Pros and Cons”. Base on a definition from POSA (Buschmann, et al. 1996), Architectural patterns express fundamental structural organization schemas for software systems. They provide a set of predefined subsystems. Specify the responsibilities and include rules and guidelines for organizing the relationships between them.
Some of the patterns are wearable with each other and they can be combined to solve a more complicated problem. Moreover, each pattern has a set of Facts and term of definition which solves the problems by those assumptions, most of the time a homemade definition for these terms and facts results in a Frankenstein architecture, creating software by this Frankenstein kill your software very soon.
A list of software architecture design patterns are: (Buschmann, et al. 1996)
- Multilayered architecture
- Blackboard pattern
- Distributed Systems
On the other hand, “Architecture style” is recurrent Architectural Design. It doesn’t exist to solve the problem. Each software architecture can contain several Architectural Styles, and each Architectural Style can make use of several Architectural Patterns. An architectural style is characterized by the features that make a building or other structure notable and historically identifiable. Some of these styles are:
- Representational state transfer (REST)
- Cloud computing
A reference architecture is a set of decisions which try to meet the constraints, manage the organizational risks and decrease complexity by setting guidelines and high-level technical decisions. For example, using AWS as the infrastructural backbone is one of this type of decisions. It means regardless of the project or features you are working on you have to obey these instructions and guidelines. For example, when you start a loyalty system for an e-commerce application which in its reference architecture it’s ruled the infrastructure is based on AWS, you are not allowed to suppose you will work with Azure. Using gRPC instead of web APIs is another example here.
Software Specific architecture
Each software has its own special quality attributes and constraints, those decisions that address these software specific problems form software specific architecture, most of the time these decisions are not repeatable in other software while the environment, quality attributes, even development team vary. Each solution for this type of problems must be taken based on architecture patterns and reference architecture. For example, a decision on how a data must be persisted to provide the fastest accessibility with least bandwidth usage in a distributed trading is a topic for such decisions.
When a software architecture design performs, it might be clear about which part of this definition we talk, this approach helps to avoid reinventing the wheel and focus on our specific problems that are unique for current problem and hand. The following figure depicts the relationship between these elements and definition.