Blog 23.4.2019

How to lead software architecture

leading software architecture

Good to see you here! We have no doubt this post has good information, but please keep in mind that it is over 5 years old.

leading software architecture

Background

“80’s rule man, best time ever! Then that Cobain had to come around and ruin it all.” is a funny quote from the movie Wrestler. Today’s software experts might also yearn for former times. In the waterfall model, the role of architecture was clear – it was designed up front, after requirement analysis and before the implementation phase. In the current Agile era, architecture is often evolving without clear goals and objectives.

Yin and Yang

According to “Clean Architecture”, the purpose of architecture is to support the lifecycle of the system. The ultimate goal is to minimise the lifetime cost of the system and to maximise programmer productivity. Traditionally, dedicated experts have been accountable for this function. In this blog, these experts are called software architects, but technical leads and stack leads are also commonly used titles. Typically, software architects have a strong technical background and good leadership skills.
One of the Agile core values is the development teams’ autonomy. Teams design, implement, test and deploy independently. Traditional Agile methodologies, such as XP (Extreme programming) and Scrum, do not mention how architecture design should be led in practice. XP advises, for example, that architecture design just emerges alongside other design.
The larger the project (i.e. multiple teams), the more complex is the product’s software itself. This means that architectural decisions will have a bigger impact. The question then arises how architecture design is led and what responsibilities software architects versus teams have?

Make your system visible

Systems thinker and the father of the quality evolution, W. Edwards Deming has said that 96% of organisational performance is a function of the organisation’s structure. Only about 4% of an organisation’s performance is attributable to the people. Part of the structure is to understand how collaboration works in the system.
The following table makes collaboration between architects and teams visible. Every row of the table represents a potential point of leverage. The columns represent different options as to how collaboration can be implemented. Left columns represent a more distributed and emerging architecture mindset (i.e. Agile) and the right columns a more centralised and formalised approach. Organisations are different, and therefore leverage points and options vary as well. Rows are also independent, so for example “Architects are part of the teams” and “Architects are dedicated mostly to architecture topics” can be used on the same project.
<– more distributed                more centralised →

Point of leverage
Option 1
Option 2
Option 3
Option 4
Hierarchy levels One level – no special roles, just team members Two levels. Developers and architects Three levels+. Team members, architects, chief architect
Scope of software architects None Architecture principles (e.g. standards, concerns, styles) Architecture principles and infrastructure & operations As option 3 plus enterprise architecture
Alignment No architects. Team member is the only role Architects are part of the teams. Architects work as free agents Architects form a team or department
Decision making No architects. Teams make architectural decisions Teams and architects make architectural decisions together Architects make most of the architectural decisions
Division of Work No architects. Teams share responsibilities dynamically Architects and teams share their responsibilities dynamically Architects have predefined responsibilities
Capacity No reserved capacity. Teams use their time on architectural topics if needed Architects/teams have reserved capacity for architecture topics Architects are dedicated mostly to architecture topics

No “one-fit for all” solution

After the current collaboration model is defined, the next step is to decide the future direction. Organisational systems are determined by their context, so “one-fit for all” solutions aren’t appropriate. Nevertheless, some conclusions can be drawn.
Typically, the long-term goal should be to move to the more distributed and self-organising collaboration model. When people understand the collaboration strategy, it is much easier to take actions toward it. Unfortunately, organisations underestimate the amount of work that the transformation requires. People have different skills and expectation levels and unlearning at both the organisational and individual level is required.
Agile is also a highly disciplined method. Business people and team members must work together daily; the cross-functional team structure is mandatory and software delivery must be frequent, to name just a few principles. If the organisation won’t bend to these demands, a more centralised collaboration model might be the valid option.
Sub-optimising is also a risk in bigger organisations. A team might violate architecture principles thoughtlessly, just to finish their sprint backlog faster. The other team might implement a similar service that has been already created by another. Architects see more easily the whole and are able to make holistic decisions.
Many organisations’ technical debt is huge as well. Products suffer wrong technologies or bad programming practices and an enormous amount of refactoring work is needed. Painful architectural decisions are often made more efficiently by a more centralised collaboration model.

A hero is required

Software architecture is not the hottest topic in the software development field. In addition to this, it is very abstract and hard to lead. However, all software has an architecture regardless of if the architecture is managed or not. Smart organisations understand that the organisation structure should be optimised for the most crucial paths of collaboration – and collaboration between teams and architects is part of it.

Graphic design
Ville Takala 
References
https://www.quotes.net/mquote/132593
The Clean architecture – Robert C. Martin
Technical leadership and the balance with agility – Simon Brown
https://eric.ed.gov/?id=ED577444
https://www.researchgate.net/profile/Varvana_Myllaerniemi/publication/233792525_Comparison_of_Software_Architecture_Design_and_Extreme_Programming/links/0fcfd50b8b54316e7d000000/Comparison-of-Software-Architecture-Design-and-Extreme-Programming.pdf
https://agilemanifesto.org/principles.html
https://sites.google.com/a/scrumplop.org/published-patterns/product-organization-pattern-language/conway-s-law

Advisory Services

agile

Architecture Consulting

scrum

software architecture

Juhana Huotarinen

Juhana Huotarinen's background is in software engineering and lately he has been leading Gofore's subsidiary Rebase Oy. He is passioned about lean thinking, agile transformation, software megatrends, and work culture. Juhana follows the "every business is a software business" motto.

Back to top