The Role of a Software Architect

Posted on

Introduction

In this article, I will present my point of view on software architecture and the software architect’s role.

I decided to write this article because I often see many people defining software architecture and the software architect’s role differently. There is a certain fuzziness around this topic. Many people see the need for technical leadership in large software development projects, often identified as the software architect. At the same time, we often struggle with a good definition of this role. I hope that this article will help in some way to define discussed subject more precisely.

What is a Software Architecture?

Overview

It is hard to discuss the Software Architects role without first defining Software Architecture. In this paragraph, I am providing my definition of Software Architecture.

Software Architecture is a shared, collective, intentional, evolving understanding of the system. It is kept in a written down, easy to share & change format that allows for modifications tracking. It should bring all requirements, constraints, and different stakeholder needs together to provide a holistic view of what needs to be built to support business goals from a technical perspective. It provides just enough upfront decisions and design while delaying other decisions for later, fostering emergent solutions. It includes:

  • technical vision
  • business context
  • stakeholders map & needs
  • design documents
  • diagrams
  • architectural significant requirements (ASRs)
  • architecture decision records (ADRs)
  • decomposition into domains, modules, components, and interfaces
  • deployment architecture
  • prototypes
  • architecture evaluation report

Communicating Software Architecture

Documenting the Software Architecture will only be valuable when communicated and shared. The social aspect of Software Architecture is essential. Software Architecture can be communicated in multiple ways:

  • by publishing Software Architecture Artifacts (documents, diagrams, ASRs, ADRs, prototypes, …) in an easily accessible place
  • by working collectively on Software Architecture Artifacts together with the Teams
  • by hosting design sessions and workshops with the Teams
  • by reviewing and hosting Q&A sessions with the Teams
  • by hosting informal, unstructured architecture talks

The desired state is when all stakeholders, anyone involved in a software development process, instinctively look into the Software Architecture Artifacts to answer the questions related to the technical aspects of the project. The collective aspect of evolving Software Architecture works best because it engages teams and, at the same time, automatically provides bottom-up feedback, which enables verification of design decisions against reality.

Software Architecture Artifacts

Software Architecture is often associated with a collection of arrows and boxes. This is somehow true, however, Software Architecture is much more. As written in the previous paragraph, it is not about diagrams or documents. It is about shared and collective understanding of the system, often communicated via Software Architecture Artifacts, like:

  • Documents
  • Diagrams
  • Prototypes
  • Start templates

Documents should be easy to share, change, and review. Log of changes should be kept automatically. It should be possible to tell who changed what and when. Having the ability to provide comments explaining the intent of changes is also beneficial. It is also good if we can easily search through documents. Documents can be kept in traditional binary formats used by popular text editors, however, usage of markdown or Wiki can be better from easy to change and review perspective.

Diagrams should be used as a tool for ideas visualization and communication – they should not be perceived as an end goal. Diagrams should be easy to update. At the same time, it should be possible to decide how the diagram elements are aligned on the screen. Diagrams should be elegant and readable. They should not be cluttered. We should avoid presenting too much information at once. Instead, multiple diagrams showing the system at different zoom levels and in different contexts should be used.

Design can often be communicated well, or even better, with a reference code containing prototypes. Teams can use such a code as a reference point to start the implementation of new modules that will integrate into the overall architecture.

Starting templates is a great way to involve teams in Software Architecture documenting activities. Team members can write ADRs, Design Documents based on a common format used within the project.

Stakeholders

Software Architecture should maximize the needs and interests of different stakeholders:

  • on the customer side
    • users
    • security & compliance
    • IT departments
    • legal & finance
    • VP, Directory, CTO, CEO, …
    • …
  • on the software solution provider side
    • product owners
    • sales
    • other architects
    • developers
    • testers
    • devops
    • SRE
    • …

Identifying and addressing all stakeholder’s needs is essential for Software Architecture success. Every stakeholder should feel that their needs are taken into account, and the proposed Software Architecture makes them effective, it helps them achieve their goals.

Architecture Significant Requirements (ASRs)

Effective Software Architecture needs to be created in a context. It is not effective to design everything up-front. At the same time, it is not effective to not get a deep enough understanding of what needs to be built. This is because projects are very different. For example, a global e-commerce store differs significantly from mass IoT data processing software or from computer-aided design and simulation software used in construction engineering. Each context will bring different requirements and architectural patterns. We need to discover enough to be able to design within the context. We can write down our requirements as Architecture Significant Requirements (ASRs) documents, which would contain:

  • influential functional requirements / influential use cases
  • technical requirements
  • compliance requirements (PCI, GDPR, SOX, HIPAA, …)
  • quality attributes (availability, scalability, performance, …)
  • constraints around costs, schedules, risks
  • Service License Agreements (SLAs)

Software Architecture should act as an enabler, maximizing selected quality attributes while minimizing costs.

Architectural Decision Records (ADRs)

Creating Software Architecture involves making many decisions. Each important decision should be:

  • documented
  • communicated
  • reviewed – others should provide feedback
  • subject to change
  • should provide context
  • should provide justification
  • should provide alternatives analysis, different solutions analysis
  • when applicable, provide a pros and cons analysis
  • when applicate, provide a decision matrix analysis

Writing those decisions down avoids repeating the same discussions and decisions, provides a reference point, a knowledge base. Initially, writing decisions might look like an additional cost, and it is, however, it is far less expensive to reference past decisions instead of repeating the same discussions over and over again.

Decisions can be kept as Architectural Decision Records (ADRs) documents. They can include decisions like:

  • technical decisions, like version control system (VCS), languages, databases, application servers, container platform, cloud provider
  • decisions on cross-cutting concerns, like authentication, authorization, logging, system observability
  • decision on continuous integration and continuous deployment (CI/CD) design
  • decision on software development release model and branching strategy

Trade-offs

It is worth noting that there is no perfect Software Architecture. Easy decisions that have only pros and no cons are rare. Most decisions will be about trade-offs. This is why Architectural Decision Records (ADRs) are important, as they allow us to move back in time when the decision was made to understand the context and justification for taking selected trade-offs.

Evolving

Software Architecture is not something that is written once and then executed. It should be evolved under a constant feedback loop by the teams involved in the software development process. Architecture should not be written in stone. Architecture should foster emergent solutions. It should change whenever the architectural context changes. Bottom-up feedback from teams affected by architectural decisions is very important. We want to make sure that architecture will not prevent stakeholders from achieving their goals, instead, it should act as an enabler.

Architectural Patterns

Building software on a proven foundation is a good idea. Reusing concepts that worked on other projects can reduce the risk, cost and allow us to finish projects quicker. However, patterns will benefit us only when used in the right context for the right purpose. Getting the right pattern fit is essential based on identified Architecture Significant Requirements (ASRs).

Over the years, the number of patterns grew, and we can pick from a large catalog of Software Architecture patterns, each having its pros and cons. Some example architectural patterns are:

  • Monolith
  • Microservices
  • Service-Oriented Architecture
  • Layered Architecture
  • Ports and Adapters
  • Publish-Subscribe Pattern
  • Client-Server Pattern
  • Peer-to-Peer Pattern
  • Controller and Worker Pattern
  • Pipe-and-Filter Pattern
  • Circuit Breaker Pattern
  • …

Use them whenever based on context and requirements, you can asses that problem-pattern fit was reached.

Maintainable Software

Software Architecture should consider the current project lifecycle phase, expected scale, and the project’s expected lifespan. Large-scale projects with long lifespan expectations should promote maintainability as one of the quality attributes. It is worth noting that in some cases, especially during the project’s introduction and growth phase finding the market fit, working business model, and putting software in end-users hands might be a higher priority. Sometimes prioritizing for the long term might not work because the long-term might never come. Guessing lifespan expectations is not always possible. At the same time, building on the wrong foundation will prevent product success when it turns out to be in demand. If, from the context perspective, we can already expect a long lifespan and large scale, software architecture should promote the following:

  • well defined boundaries around business domains
  • well defined interfaces
  • well defined responsibilities
  • modularity
  • high cohesion
  • low coupling
  • clean code
  • technical debt prevention
  • meaningful and stable tests

Using the above quality attributes will increase the probability of keeping the cost of making changes over time under control.

Architecture Evaluation Report

Software Architecture should be subject to continuous evaluation. We should recurringly ask stakeholders for feedback on architecture. Based on the feedback, Architecture Evaluation Report should be created. We want to verify that architecture:

  • promotes important quality attributes
  • delivers on Service License Agreements (SLAs)
  • acts as an enabler
  • minimizes costs
  • minimizes risks
  • satisfies technical requirements
  • satisfies compliance requirements

Such feedback can be gathered by asking stakeholders to fill Architecture Scoring Form, which would contain ratings for Software Architecture characteristics being measured. We should establish what to keep, change or remove based on the feedback.

What does a Software Architect do?

Having the Software Architecture term defined, we can now move to the definition of the Role of a Software Architect.

Since Software Architecture is often associated with a collection of arrows and boxes, some might think that Software Architect just draws those arrows and boxes. Based on the previous paragraph, we already know that Software Architecture is much more. The same applies to the Role of a Software Architect.

Software Architects work at the intersection of Business and Technology. They interact with stakeholders to understand needs and provide technical solutions. They often wear many hats and are engaged in different steps of the Software Development Process. Here is the summary of different tasks often performed by Software Architect:

  • provides initial technical vision, and multiple possible solutions, based on the business goals, business model, costs, constraints, schedules, risks, the skillset of the team, and quality attributes
  • identifies architecture stakeholders and their needs
  • documents requirements as Architecture Significant Requirements (ASRs)
  • documents important decisions as Architectural Decision Records (ADRs)
  • creates different solution analyses, decision matrices, and pros/cons analyses, decides on trade-offs
  • creates design docs, diagrams
  • creates, shares, and collaboratively evolves architectural artifacts
  • works together with the development team on architecture and project development
  • makes sure that everyone involved in the Software Development process understands the technical aspects of the project
  • writes prototypes
  • acts as a mentor
  • promotes emergent solutions
  • updates architecture based on feedback gathered from architecture scorecards

Types of Software Architects

The Role of a Software Architect also depends on the Software Architect’s type. The following different Software Architect types can be defined:

  • Enterprise Architect – works across different business value streams, manages products portfolio, aligns business and technical strategy, makes sure that technology supports business goals.
  • Solutions Architect – works across different systems, aligns solutions for common problems, provides shared services used in different products.
  • System Architect – works on a single system, provides technical vision, and solutions for business problems, works with the teams on evolving system design, works with Solutions Architects on shared services adoption, and works with Enterprise Architects to ensure technical alignment with portfolio.
  • Application Architect – similar to System Architect, works on a single application, provides technical vision, and solutions for business problems, works with the teams on evolving application design, works with Solutions Architects on shared services adoption, and works with Enterprise Architects to ensure technical alignment with portfolio.
  • Domain Architect – has deep specialization within the domain of expertise, examples include: Security Architect, Data Architect, AI Architect, Mobile Architect, Cloud Architect, Infrastucture Architect.

Qualities of an Effective Software Architect

Becoming a good Software Architect is a challenging task. This is because being effective in this role requires us to develop skills beyond technology. This is not to say that technical knowledge is no longer beneficial. On the contrary, having wide and deep technical knowledge is required. Software needs to be built on a solid technical foundation. However, when it comes to the role of a Software Architect, additional skills need to be developed to succeed in this role. Below I am outlining a set of skills that, in my opinion, a good Software Architect should have:

  • great analytical skills
  • prototyping skills
  • avoids single-solution mindset
  • great communicator
  • knows how to evolve solutions, work under a feedback loop
  • negotiation skills
  • team player, effective collaboration, and delegation
  • mentor
  • wide technical knowledge
  • deep technical knowledge in selected areas
  • understanding of the business context and the business domain
  • understanding of basic finances, business models, and costs structures
  • understanding of the large organizational structures
  • ability to create, maintain, share, and collectively evolve technical documentation
  • ability to effectively work with all stakeholders involved in the software creation process (customers, product owners, sales, security & compliance teams, managers, other architects, developers, testers, devops, …)

Should Architects Write Code?

Yes, Software Architects should also code. It is impossible to code 100% of the time as a Software Architect. It might even be hard to code 50% of the time. However, I think that the recommendation should be to be able to dedicate 10% – 30% of the time to coding activities. The answer to this question also heavily depends on the Software Architect type. Finding time for coding as an Enterprise Architect is harder than it is for a Single Application Architect. Coding is important because development teams are large and important stakeholders in Software Architecture. Experiencing firsthand how Software Architecture decisions affect daily development tasks can bring an important perspective. Writing prototypes for solutions can quickly invalidate those. Additionally, working prototypes can be used as a tool for design communication.

When do you need a Software Architect?

The answer to this question depends on the factors related to scale and complexity:

  • How complex is a business domain for which a project is created? Are we operating within a complex domain such as banking, health care, finance, accounting, payments?
  • Are we operating within a regulated industry?
  • How complex is the stakeholder’s map?
  • How complex are the requirements?
  • What is the scale of the project?
  • How many teams are participating in the development process?
  • Do we need to align our project with the existing portfolio?
  • How many integrations with other systems do we expect?
  • How important is it to keep track of architecture cost efficiency?

Software Architect is required when the project exceeds a certain scale.

There are plenty of small projects built by small teams of up to 8 team members, in which architecture consists of a managed serverless environment hosting the application and a managed database responsible for keeping data for this application. In such small projects, the team can decide and document architecture without a dedicated person focusing on architecture-related tasks. In many cases, a single team can be successful with informal architecture shared verbally.

Perspective changes when we have 6 teams, each consisting of 8 team members. Each team working on a dedicated Microservice, which adds up to the System that needs to be integrated with other products and fit into the enterprise’s business value stream and the overall company products portfolio. Additionally, having a dedicated person to Software Architecture reduces the probability of having Accidental Software Architecture. We want to target Intentional and Emergent Software Architecture because that way, we can be sure that Architecture supports business goals with quality attributes.

Software Architecture Tools

Software Architect needs to perform many tasks in the areas of:

  • Requirements analysis
  • Needs discovery
  • Problem definition
  • Potential solutions analysis
  • Decision making
  • Knowledge sharing
  • Collaboration
  • Communication
  • Ideas Visualization
  • Evaluation

Below I list some standards, concepts, and tools that can support Software Architect in the above areas.

Standards:

  • C4 model for visualizing software architecture
  • ISO/IEC/IEEE 42010:2022 standard for architecture description
  • 4+1 Architectural View Model

Conceptual:

  • Stakeholders map
  • The Point-of-View Mad Lib Stakeholders Needs Summary
  • Event Storming
  • Architecture Significant Requirements (ASRs) Document
  • Quality Attributes Web
  • Sketch-Swap-Critique-Enhance Round Robin Design
  • Diagrams
  • RAPID Decision Making Model
  • Decision Matrix
  • Pros / Cons Analysis
  • Component Responsibility and Collaborator Cards
  • Architectural Decision Records (ADRs) Document
  • Scorecards

Tools:

  • Asciidoc
  • Antora
  • PlantUML
  • Kroki
  • Draw.io
  • GitBook
  • Confluence Collaboration Tool
  • Visio
  • Enterprise Architect
  • VisualParadigm

Summary

In this article, I have presented my point of view on Software Architecture and the Software Architect’s Role. First, I defined Software Architecture as a shared, collective, intentional, evolving understanding of the system that brings all requirements, constraints, and different stakeholder needs together to provide a holistic view of what needs to be built to support business goals. I also emphasized the importance of emergent solutions and the social aspect of Software Architecture. I defined Software Architecture Artifacts and common Stakeholders. Having Software Architecture defined, I move to the definition of the Role of a Software Architect and the skills required to be successful in this role. I provided information on common responsibilities assigned to Software Architect. I also provided information on when Software Architects are required. I finished with an outline of commonly used standards, concepts, and tools. I hope this article will reduce some fuzziness around the Role of a Software Architect.