Chief Technology Architect, Hilti Group, Fastening and Protection Solutions
Throughout my IT career I have worked in various kinds of architecture roles, including Software Architect, Solutions Architect, Enterprise Architect, and now Chief Technology Architect. While it is tempting to view these positions as progressive rungs in an ascending ladder, I find it more useful to view them as complementary functions in the endeavor to design and build adaptable systems which sustainably deliver business value over time. From this perspective Software Architects have a unique and vital contribution to make, because they are often closest to the de facto architecture of a system.
What Is Software Architecture?
This article is inspired by a 15-minute talk, titled “Making Architecture Matter,” presented at an O’Reilly conference in 2015 by renowned software architecture guru, Martin Fowler.
Martin begins his talk by emphasizing that software architecture isn’t just about crafting elegant diagrams. Although these can help communicate important aspects of the application architecture, they themselves do not capture the actual architecture of a software project. Rather, the totality of the application architecture can be best expressed as the shared understanding of a system by expert developers who are most familiar with the application. In other words, if you’re going to understand the actual architecture of a system, you need to look at the code – not simply as an abstraction but understanding how different pieces work both individually and collectively. This intimate knowledge is a key enabler for engaging in discussions that produce sound technical decisions which affect the overall system design.
Martin grapples with how to define precisely what software architecture is, referring to an article he wrote, Who Needs an Architect, in which he quotes Ralph Johnson as saying, “Architecture is about the important stuff. Whatever that is.”
Given this characterization, one might speculate about how architecturally significant decisions are made. It is the job of the Software Architect to ensure that consequential decisions are made in a strategic manner. In other words, the architect is the person who sees the larger technological landscape, discerning emerging trends and discriminating between enduring paradigm shifts and passing fads.
Choice of technical frameworks is but just one crucial decision in which software architecture must play a role. We are, for example, in the midst of a number of paradigm-shifts that will influence the direction and focus of our software projects. Here are a few noteworthy examples:
- IoT, Edge Computing
- Microservices, Event Driven Architecture
- Vendor Neutral, Multi-Cloud
- AI/ML, Large Language Models, Prompt Engineering
Some of these are well established, while others are beginning to gain traction. It is therefore important for architects to lead teams in the transition from legacy models to trending paradigms that will result in increasing levels of reliability, scalability and cost-effectiveness.
The Right Level of Abstraction
Martin goes on to state that our goal as software architects is to design systems that reduce the number of components that are difficult to change.
Well-factored systems tend to rely on well-known design patterns, such as SOLID, Gang of Four and Domain-Driven Design. Adhering to these principles will aid in the design of modular systems with loosely coupled components and clear separation of concerns. In addition, it is important to establish how services interact with one another, abstracting away direct dependencies in favor of asynchronous communication based on patterns such as CQRS, publish-subscribe and event sourcing. Martin has an excellent presentation on the Many Meanings of Event-Driven Architecture, in which he discusses the pros and cons of various event-based architectural patterns. The purpose of applying these patterns is to reduce parts of the system design that are difficult to change, thereby increasing flexibility and helping insure against premature obsolescence.
It is important for software architects to understand, no matter how beautiful and elegant your designs are, dev teams will almost always adulterate them by introducing anti-patterns. Developers will often apply architectural patterns without fully understanding them and will, as a result, introduce hacks and workarounds that defeat the very purpose for which a pattern was created. As Martin states an article titled Who Needs an Architect, the best architects are like mountaineering guides: “a more experienced and skillful team member who teaches other team members to better fend for themselves yet is always there for the really tricky stuff.”
Why Architecture Matters
One of the most challenging aspects of a software architect’s job is to communicate to stakeholders and key decision-makers the value that effective software architecture brings to the business. Sometimes companies fail to recognize that, to a certain extent, all companies need to see themselves as being in a technology company – or at least recognize that well-built software can be a differentiating factor that provides a crucial competitive advantage.
Even if a company acknowledges the importance of software architecture in general, it may not recognize that quality software architecture is essential to building systems that are large, complex and play a critical role in running the business. Responsibility for communicating this message lies with us, and our profession suffers the extent to which we fail to convey the role software architecture plays in both avoiding costly mistakes and rapidly introducing new product features. Martin calls this the Design Stamina Hypothesis, which postulates that at a certain point in the application development lifecycle, good design allows features to be introduced at a faster pace than when design is not considered, or where poor design choices have resulted in an inordinate accumulation of technical debt.
One of the misperceptions that architects face is that we are engaging in architecture for architecture’s sake, or that we propose new technologies mainly because of the “coolness” factor. Our challenge is to counter this misperception by arguing not merely for the aesthetic value of good design, but for the pragmatic, economic value. We need to frame the need for intentional design as something that can save the company significant costs by averting disadvantageous technology and design choices, producing a distinct competitive edge through market differentiation and paving the way for increased customer satisfaction. If we can clearly communicate the value proposition of sound architectural design and the benefits of ensuring correct execution of that design, we will help increase the rate at which an organization can deliver features that delight customers.
My commentary on some of Martin Fowler’s views of software architecture is not intended to paint a complete picture of this important role and how it differs from other types of architects. Rather, I’ve sought to highlight the importance of designing the structure of a system at the code level to ensure that the application of relevant patterns results in a design that can sustain cumulative functionality over time, increasing business value while reducing time to market.
Here are some open questions on the role of Software Architect and its importance.
- What is the scope of the Software Architect role and its responsibilities?
- What artifacts should a Software Architect be expected to deliver?
- How does the role of Software Architect differ from that of Solution Architect?
- How close should a Software Architect be to application code?
- What is the value proposition of software architecture?