Finding Architecture

For a concept and a discipline that has been in practice for decades, software architecture has way too many definitions and interpretations. Every company that I have worked for had their own collective understanding of what architecture is - but every time I changed companies, I found out that their understanding is different to the previous place I've been, sometimes slightly - sometimes considerably more. But in a general sense they were all correct and they all worked. But, when asked the question what is architecture, I never had an answer that I felt good about or an answer that made sense to others I was talking to.

I've never been after the text book definitions of anything, but I have never contradicted with them either. I just like to word them the way that it made sense to me - to the people I'm communicating with.

And this short write up is about finding a definition for the term architecture - for me.

The Context of Architecture

Before I get to a definition, I think it's important to set some context to it.

• A software project always have business requirements in the form of functionality and quality attributes (non-functional requirements)
• The software product or solution will exist in an ever changing business environment exposed to market changes, competition, regulations and politics etc.
• Different parts of the product or solution will be designed (definitions of how the software will be implemented) by different people with different skill levels having access to varying degree of information in the context, with competing priorities, etc.
• Software will be implemented, deployed and serviced by different people, again with different skill levels, access levels to information and competing priorities. etc.
• Software has to be built using, integrated to and work with different technologies and protocols with each person building, integrating, deploying, supporting and using having different degrees of exposure and expertise to those technologies.
• People who are involved in building the software could be from different companies, from different parts of the world, speaking different languages, possessing different skills, holding different value systems etc. etc. etc.

All of these factors, collectively and independently influence how software is made, deployed, supported and used.

What is Architecture?

Given this context, architecture is a set of policy decisions made to govern design, implementation and operations of the software solution, as responses to the prioritized risks identified in each of the above categories (contextual influences).

Communication of Architecture

Based on the stakeholders involved, communicating of the architectural decisions itself could have different degrees of risk exposures. For example,

• If the team is relatively small and everyone has equal knowledge and exposure to the contextual influences - and the architect is a member of the team, the risks of a miscommunication is relatively very low.
• If the teams are globally distributed and different teams have different levels of exposure to different contextual influences, the risk of a miscommunication is relatively high.

Based on the communication risk assessment, the architect must choose appropriate tools and methods to communicate the policy decisions to the stakeholders.

• Sometimes decisions could be communicated verbally to the team.
• In some instances decisions could be recorded as Lightweight Architecture Decision Records and coexist with source code.
• Some decisions has to be communicated as models such as threat models or process models.
• Some decisions should be communicated as structural diagrams such as context diagrams or component diagrams.
• Sometimes decisions should be communicated as concrete design artifacts such as deployment diagrams or class diagrams.
• And in some cases, the communication needs to be concrete implementations such as frameworks or contract interfaces.

Whatever the communication mechanism be, it is important to remember and emphasize that the architecture is the policy level decision that was made as a response to an identified risk - architecture is not the medium used for communication.

Deployment design is not architecture - it is just sometimes it is best to communicate the policy decisions around deployment in a deployment design, due to the risks of those decisions not being communicated, understood and enforced correctly in the implementation.

In relation to the other definitions

Below are some of the definitions that I have frequently encountered in the wild.

The important stuff—whatever that is; this refers to the fact that software architects should concern themselves with those decisions that have high impact on the system and its stakeholders

That which is fundamental to understanding a system in its environment

Things that people perceive as hard to change; since designing the architecture takes place at the beginning of a software system's lifecycle, the architect should focus on decisions that "have to" be right the first time. Following this line of thought, architectural design issues may become non-architectural once their irreversibility can be overcome.

A set of architectural design decisions; software architecture should not be considered merely a set of models or structures, but should include the decisions that lead to these particular structures, and the rationale behind them. This insight has led to substantial research into software architecture knowledge management..

Even though I'm not meeting them word to word, I believe my interpretation is not in disagreement with any of them. However having this interpretation has helped me make architectural decisions with a purposeful clarity and communicate them effectively to my stakeholders. I hope at least some of you readers will find this perspective more relatable and gain more clarity of thought in architecture through it.