Autonomy for Software Architecture Design

Break free from the Ivory Tower: Embrace autonomy for efficient and effective Software Architecture Design

May 03, 2023

Software Architecture is both an art and a science and a critical part of a Software (and Product) Development Lifecycle (SDLC/PDLC). The Software Architecture processes an engineering organization employs ultimately determine how successfully the organization can scale to meet quality, speed, and capability demands.

As a software engineering organization grows, a top-down architecture process can not keep up with demand and quickly becomes a bottleneck. A bottom-up approach, where everyone designs as they go, results in duplication, disparate technology stacks, and other inefficiencies.

For software architecture processes to scale, they need to be decentralized like the software systems it produces. For decentralization, autonomy plays a critical role.

Autonomy is critical to scaling an engineering organization. However, autonomy without constraint is chaos.

Over the past decade, I have been formulating a framework for effectively managing Software Architecture processes that involve multiple independent teams. This framework is based on my experience and insights gained from industry leaders. Having been part of teams with too little or too much structure, I have helped scale architecture processes from scratch to meet the needs of growing organizations and reorganized overly-centralized processes to enhance autonomy and efficiency.

Several books and articles have covered similar architectural concepts at a high level and their potential uses. I will delve into how I specifically apply these concepts holistically. Additionally, I will guide you on incorporating an architecture process framework through iterative steps to scale them from a single development team to half a dozen or more.

This article provides a high-level overview of the process and its components. In subsequent articles, I will delve deeper into the details of various components.

What does autonomy have to do with software architecture?

Autonomy in software development is the ability of individual teams to make decisions and develop solutions independently without needing constant oversight or approval from a central authority. This approach empowers teams to innovate, iterate, and adapt to changing requirements faster. Software Architecture encompasses all software development, so for software development teams to be autonomous, the architecture processes must also enable autonomy.

Autonomy leads to faster decision-making, which leads to faster implementation. Teams can make decisions quicker since they are not constantly waiting for approval. This quick decision-making reduces bottlenecks and enables teams to respond more effectively to new challenges and opportunities.

Streamlines communication within teams
Reduces dependencies on decision-makers
Encourages proactive problem-solving

Autonomy fosters a culture of innovation because teams are empowered to explore new ideas and solutions. This freedom can lead to more creative and effective solutions.

Encourages experimentation and learning
Promotes cross-pollination of ideas between teams
Facilitates the discovery of novel approaches

Autonomy inspires ownership, contributing to higher job satisfaction and motivation among team members. Individuals with more control over their work tend to be more engaged and committed to the project's success.

Encourages a sense of ownership and responsibility
Empowers individuals to utilize their skills and expertise
Fosters a positive work environment that values creativity and initiative

Won't all this autonomy lead to chaos?

Autonomy without constraint can indeed lead to chaos. Autonomy is not independence and isolation. It is essential to strike the right balance between autonomy and structure to ensure the overall success of the software architecture process.

For effective software architecture, collective impact is more important than individual impact. Individuals and teams must align on a framework to have a positive collective impact while maintaining autonomy.

A framework for autonomy should:

Establish clear goals and guidelines: Clearly defining objectives and expectations helps everyone understand the overall direction and constraints they should work within without stifling their autonomy.
- Align team goals with organizational objectives.
- Communicate boundaries and limitations. Who can make which decisions? Who will do which things?
- Encourage a shared understanding of best practices.
Foster collaboration and communication: Promoting a culture of collaboration and open communication ensures that autonomous teams work together effectively and can learn from each other's experiences and expertise.
- Implement communication channels for cross-team collaboration.
- Share successes and failures to enable continuous improvement.
- Encourage regular team check-ins and knowledge sharing.

The components

The key components of a decentralized Software Architecture framework that enables autonomy include:

Design Documents with Architect sponsorship
Design Socialization
Staff+ Engineer and Architects Collaboration Forum
Architectural Principles
Technology Radar/Menu
Any/Architecture Decision Records
Architecture Advisory Forum
Developer Enablement

The above order is the approximate priority for introducing these concepts. They are also prioritized by relative implementation complexity and return on investment.

Design Process

The components that drive the design process are:

Technology Menu/Radar: A catalog of technologies and their fitness in software systems.
Architecture Principles: These guidelines are team-sourced and team-agreed-upon for designing and operating software.
Design Document: A document that describes the context of a problem and the solution to address it. To encourage team ownership of the problem, senior or staff+ engineers drive the design and solution, and Architects sponsor them.

When used in conjunction, these components cultivate designs that satisfy business requirements and goals. By following the Architecture Principles and using technologies from the Technology Menu when creating designs, teams are granted autonomy to self-design solutions while avoiding chaos.

The Architecture Advisory Forum

The Architecture Advisory Forum is a group, usually consisting of architects and engineering leadership. The AAF owns the components and processes of Software Architecture. However, the AAF is not a regulatory body. Members of the AAF are facilitators of design and processes.

The AAF and its members:

Works with cross-functional teams and senior leadership, such as the CTO (who is responsible for technological vision), to determine a set of Architecture Principles.
Facilitates the Technology Decision process and works with teams to agree upon a process to add items to the Technology Menu and promote them from trial to adoption.
Works with teams to agree upon a Design Document standard.
Sponsors team member designs to ensure that they follow the Architecture Principles, use technologies from the menu, and satisfy the needs of the stakeholders.

Design Socialization

A design review and approval process may appear to be missing. When a design has AAF member sponsorship, adheres to Architecture Principles, and utilizes adopted technologies from the Technology Menu, it does not need approval. Instead, people present designs for socialization. Through this socialization, other teams learn how the ecosystem evolves and share knowledge and best practices. This sharing nourishes the ecosystem, allowing it to flourish.

However, some designs may need AAF discussion. Additional discussion is required when one of the following occurs:

Stakeholders cannot reach a consensus on what solution is optimal.
The design cannot satisfy an Architectural Principle.
The design needs to use a Technology not on the menu.
The solution is complex or involves many teams to develop.
The solution will take a considerable amount of time or effort to implement.

Staff+ Engineer and Architects Collaboration Forum

While the AAF is responsible for facilitating the Software Architecture framework, they need help. Successful software development requires clear and frequent communication across the organization. Communicating things that affect the entire engineering organization one on one is inefficient. On the other hand, gathering all of engineering to discuss things regularly is impractical.

An effective way to scale up bidirectional communication between Architects and the rest of the engineering team is for them to partner with Staff+ Engineers. Different organizations have different terminologies, but generally, "Staff+" denotes the higher-level engineers, such as Senior, Staff, Principal, etc.

The team members to include in this group depend on the organization's size. An ideal Collaboration Forum consists of the Architects and a few Staff+ Engineers from each team. These cross-functional team members enable efficient communication of complex topics throughout the organization.

In this forum, among other topics I'll discuss in future articles, the members align on all aspects of Software Architecture. The Architects learn the needs of the other engineers. The Staff+ Engineers learn the needs of the business's Software Architecture. The Staff+ Engineers then share that knowledge with the rest of their respective teams. It fosters an environment of open communication and trust.

Decision Records

Software design requires a lot of decisions. Decision Records, typically called ADRs (short for "Any" or "Architecture" Decision Records), are records of these decisions.

The goal is to capture the context (Who, What, Why) of decisions so those working on the project in the future (including future you) can understand why the team made a particular decision. If you spend the effort to come to a decision, record it to preserve that effort.

An ADR:

Allows the team to review and align on a decision
Prevents second-guessing when there is insufficient information to know why a decision was made
Prevents forgetting that a decision was made and wasting time redoing a decision
Documents and socializes decisions so other teams can benefit

A typical Design Document may include several discrete decisions. They may seem minor at the time, but they could have significant ramifications down the line. Example decisions include:

Why did we decide to use a NoSQL database instead of a traditional relational database?
What format was chosen for dates in JSON?
What was the rationale for selecting a specific programming language for this application?
What was the justification for selecting a particular authentication and authorization mechanism for this application?

Developer Enablement

As organizations grow, sharing best practices and avoiding duplicating efforts becomes more challenging. Utilizing a Developer Enablement team can decrease these challenges. They are a specialized group within a software development organization that focuses on empowering and supporting software developers. Their main objective is to simplify the development process and maximize productivity.

A well-functioning Developer Enablement team can help scale Software Architecture needs by driving the adoption of best practices, standardizing processes and tools, and providing training to keep developers up to date on the latest technologies and methodologies.

Ways a Developer Enablement team can enhance Software Architecture include:

Establishing a shared repository of reusable code libraries. All development teams can use these libraries for efficient software development and architectural consistency.
Streamlining developer onboarding with documentation and resources about the development processes to introduce newcomers to the Architectural Principles and other design processes.
Developing tooling and CI pipelines for linting, testing, ADRs, documentation, etc., to automate best practices.
Facilitating cross-team collaboration and knowledge sharing through internal forums, chat platforms, and regular sync-ups, fostering innovation and architectural coherence.

A Developer Enablement team is usually one of the later things to introduce into the framework because the organization has to be large enough to require and support one. However, smaller organizations can benefit from the same concepts by allocating time and people each development cycle to work on developer enablement.

What does this look like in practice?

The team wants to develop a new feature. What's next? The most important thing to start with is writing things down. A design begins with a Design Document.

The team is excited to embark on the development of the new feature. Sam, a Staff Engineer, is assigned to drive it forward. Eager to kick off the process, he reaches out to Mia, a seasoned Architect, for guidance.

Since the company has yet to adopt a design template, Mia recommends using a simple Python PEP format, similar to PEP 3131, as a starting point. Sam creates a Design Document page in Confluence, using the headings from the example Python PEP. Mia shares that the goal is to provide enough context for another engineer on the team to implement the feature without much additional input. Essentially, Sam should answer the What and Why of the problem and the Who and How of the solution.

Sam gathers details on the What and Why of the problem by reaching out to the team's Product Manager to capture functional and non-functional requirements. He also talks with Mia and the team to determine the Who. Mia walks him through a few questions to determine who would be affected by this feature. Who are the stakeholders? Is there a security aspect that requires the security team? Will this involve some infrastructure or monitoring and thus affect the platform team?

The focus then turns to the How. Sam collaborates in iterations with Mia to converge on a solution. Mia suggests starting with a sequence diagram using PlantUML rather than describing with only words. This diagram will allow Sam to figure out all the actors and components in the system and see how they interact. It helps clarify which interactions are needed and highlights the gaps in understanding. From this diagram, the team can quickly understand the solution.

What technologies should the solution use? Lacking a Technology Menu, Sam sticks to the technologies the team is familiar with and has already operationalized. Since no Architectural Principles are defined yet, Sam asks Mia for input. Mia coaches Sam to ensure the design meets business needs and adheres to common architectural principles.

After a few iterations, Sam and Mia have a workable design. Sam has ensured the design satisfies the stated feature requirements as well as standard operational requirements like monitoring and deploying the solution.

Is it done? They use Andrew Harmel-Law's Advice Process to determine when a design decision is ready: consult people with expertise in the area and everyone meaningfully affected. Sam and Mia agree the design is complete since he has gathered and acted on advice from experts and stakeholders.

Socialization is necessary for a healthy architecture process but not a prerequisite for implementation. So the team can now start implementing the design. Sam still wants to start the habit of socializing, so he schedules a meeting to present the design and the process used to create it within his team. He hosts it as a silent meeting, so for the first 15 minutes, everyone gets a chance to read the design and write comments while Sam replies when they appear. After the silent reading portion of the call, Sam discusses any unaddressed questions and concerns. After careful consideration, he determines that no design changes are necessary.

The process can evolve now that the team's first design is complete. Mia and the other Architects begin meeting regularly with Sam and other Staff+ Engineers in a Collaboration Forum. They use this forum to discuss the evolving process, foster collaboration, and share knowledge.

From these meetings, the Architects collect Architecture Principles from the team. They choose a handful of principles that address acute problems within the organization and help move business goals forward. They prioritize principles that significantly impact the outcome yet have a small implementation cost. The Architects propose these principles to engineering leadership and then to the rest of engineering for adoption. Once stakeholders buy into these initial principles, they are documented and put into use.

Mia then works with the teams to begin cataloging all the technology currently in use in a Google Spreadsheet. She collects how it's used, what it's used for, and the sentiment on its continued use. Mia plans to implement a nice visual Technology Radar, but this is a good enough start, so she shares it with the team.

The Staff+ Engineers and Architect sponsors can now consider the Architecture Principles and Technology Menu in new designs. Many decisions have been made, and there has yet to be a mechanism to record them formally. That's okay; most of what has been documented up to this point has already organically been decided. They aren't new decisions; they're existing ones that have now been written down.

With the initial components in place, it's time to adopt ADRs. The first ADR that Mia writes is the decision to use ADRs. She wanted to get this step out of the way before any major decisions were needed. The team didn't want the creation of a process to get in the way of making a decision.

Mia considered retroactively recording important previous decisions, like when she retroactively recorded what technology was in use. She and the architecture team decided not to spend time doing this. They would only record past decisions if it took significant time to track down the previous decision when trying to make a new one. They would focus on recording new decisions.

Most of the process has grown organically with a purpose and destination. It has been incubating with one team at a time. Instead of ad hoc collaborations, Mia and the other architects decide to form an Architecture Advisory Forum. The process is getting large enough that it needs stewards. Also, there are more decisions to be made that will have a more widespread impact.

The AAF decides that when it's time to expand the principles and the technology menu, do so with an ADR process. For example, why do we want to adopt this principle? Why do we want to use this new technology? Of course, Mia records this decision in an ADR.

Now that the teams have better cohesion and alignment on principles and technology, they form a Developer Enablement team to help spread best practices, tooling, and code libraries. This collaborative approach enables the company to successfully develop its new feature while fostering a supportive and efficient environment for its software engineering team.

Wrapping up

Scaling Software Architecture effectively requires striking a balance between autonomy and structure. Software engineering organizations can foster innovation, increase efficiency, and streamline decision-making by employing a decentralized framework that supports autonomy.

By utilizing the components of this framework, teams can design autonomously while still adhering to overarching principles and patterns. This allows for scaling and growth while maintaining consistency and efficiency in the design process.

Future articles in this series will delve deeper into each component and provide more detailed guidance on implementation and how it looks in practice.

Dev Details

Discussion about this post