Software architecture has traditionally been about creating standards and designs to achieve consistency across an application or system. These choices are often assumed to be well-considered decisions made by smart people known as ‘architects’ who can see all the requirements and how everything should work. They are not challenged by an individual developer, whose role is simply to code it all up.
But in today’s agile-enlightened world, we’re aware that it’s impossible to know all the requirements. And we recognise that it’s developers themselves who are best placed to make most design decisions.
So where does this leave architects? What should they actually do?
What is architecture? What is an architect for?
If you want to build a house, you hire an architect. You need to have a decent design before even a single brick is laid. If not, you might put in foundations that turn out to be too weak to support the higher floors. This could be a very expensive mistake to correct later. Buildings are constructed from the ground up, so you could find yourself pulling everything down and starting again. An architect’s plan should help you to avoid this.
Similarly, software architects plan for building systems in the digital world. Martin Fowler’s article “Who needs an architect?” is a great description of software architecture and what architects should do. Although he rejects the building architecture analogy by arguing that structural engineering is actually a better parallel, the term “software architecture” is here to stay. And it’s still useful if you bear in mind the structural concepts too.
Much like putting in the right foundations, Fowler notes that software architecture is “the important stuff”, “the decisions you wish you could get right early in a project” and “the things that are hard to change”. Gravity is a constraint of the physical world that puts many irreversible decisions about a building at its base. And there are numerous similar constraints in software. Certain things can become more difficult to change as your business and its systems grow. Architects seek to minimise the irreversibility that would otherwise hinder you.
The building analogy works well for a single software application. But enterprises increasingly use many independent applications and services that are integrated with each other. This is more like a city whose various buildings are connected by power lines, roads and water pipes. No single person controls exactly how every building looks or functions. A better analogy for architecting that system might be urban planning (again suggested by Fowler).
And so we broadly define two software architect roles:
- The application architect – the structural engineer who looks out for the long-term sustainability of an application, its functionality and its design.
- The enterprise (or systems) architect – the urban planner who ensures that the complete set of interacting entities functions correctly, and that a system can evolve and expand freely.
In this post, I’ll explore two things:
- How the line between these architecture types is blurring
- What this means for how an architect operates
Modern software is changing the architect role
Writing and running even the simplest computer program has always had overheads. These mainly include: the hardware and operating system the your code runs on; your language choice and its dependencies; and how you build, test and run it. Experienced architects would usually be asked to make these important choices.
But developments over the last decade are making many such decisions more easily reversible. And more recently, these are really starting to come together. Cloud infrastructure is largely eliminating hardware considerations, sometimes completely in the case of ‘serverless’ offerings. A container-based approach, most notably using Docker, means applications are much freer to define their dependencies and language choice. And with familiar generic utilities such as UNIX make coupled with the latest DevOps tools, all your software can be built and tested in a standard way.
Furthermore, application design itself is harder to get wrong. Few applications are written in the bare bones of a language. Instead they’re built on a framework or major library. Most frameworks have a basic separation of concerns to guide you, and some will be very opinionated. These guidelines do a lot of the architect’s job, and free development teams to work on the functionality. For example, the MVC pattern has become the most popular on websites for this reason. It provides a rigid backbone, but is also flexible enough for almost any application. You can add helpers, other library classes, data providers, queue systems and many other patterns to help you modify and extend your application. Similarly, extensible classes, plug-ins, event listeners and service providers are all design patterns that anticipate change.
The largest application architecture decision now is probably the core framework you begin with. Beyond that, a good technical lead can handle the bulk of an application’s design. Implicit in the discussion of an architect’s role has always been the idea that “the developers” (as if they are somehow a different class) will make poor decisions. But generally a few days of researching open-source examples, blog posts and StackOverflow will get you up to speed on best practice for your framework. The prevalence of web applications means most engineers are familiar with the constraints of operating over networks and remote resource limitations. Non-functional requirements that once might have been an afterthought are now central concerns: end-user performance and security are top of the list for implementation choices.
Using the right technology to solve a problem is now easier than ever. Most elements of your application can be changed easily if necessary. And so software architecture is becoming much more about the integrations (and therefore about the whole system) than application design itself.
Agile is changing the architect’s role
As with a physical building, traditional architecture lays down an up-front plan that everyone can follow. But agile development encourages responding to change and adapting your plan. So how does architecture work in that world?
Clinging to the up-front plan is folly. The pace of change of requirements and code in agile development is faster than your design documents and architecture diagrams can keep up with. A traditional architect is left either to despair and give up, or to continue drawing out-of-touch PowerPoint diagrams. They end up in an ivory tower, building idealistic models of how things should work with no regard for practicality or value. There is simply no room for these architecture astronauts in an agile process.
The idea of “agile architecture” has been developed to help. It’s seen as an architecture that can adapt and make change easy. But if architecture is about what’s difficult to change, then isn’t agile architecture an oxymoron? You might argue that if you design a system that allows easy extension and modification, that there’s not much architecture to be done at all.
The problem is that you can’t design a system to be flexible in all scenarios. Some judgement is required about what is and is not likely to change. Agile architecture is less about a single system design, and more about the processes and conversations that keep the design valuable. Without an up-front plan to be followed, architects must be involved in the many small decisions and changes of focus that emerge during agile development. They must be part of the project team. They must understand the structure of the code, its strengths and weaknesses. Their role is to navigate in a sensible overall direction.
Without this direction, the team will make design decisions to achieve only the goals in their next iteration or two. You may criticise this as short-term thinking, but it’s absolutely the right thing to do. Iterative processes are specifically designed to focus on the next most valuable thing for the business, and anything beyond that is too uncertain. Of course this purely iterative approach will probably hit a local maximum of value, after which progress becomes harder. The team will move towards a solution constrained by the characteristics of their system that are irreversible over a few iterations.
So the agile architect has two responsibilities:
- To ensure that valuable iterative development can continue for as long as possible, by avoiding the difficult local maxima.
- To avoid the current systems and processes hindering rather than helping the business.
So what should an architect actually do?
Ensure valuable iterative development continues
An excellent Equinox article in 2015 describes an architect’s options for fitting into an iterative development team: as a tech lead, stakeholder, product owner or QA expert. But in any of these roles, it’s key that they collaborate closely with the team, rather than dictating standards from outside. And in all cases, they should do at least the following:
- Define the important questions, and ensure the team ask and answer them at the right points. Don’t hold “sign-off” meetings. These are arguably a process smell.
- Guide development teams in day-to-day design. LESS have a great – if slightly philosophical – article on how to be a good architect within your team. There are dozens of useful activities you can do. Understand any new packages or applications. Review designs, particularly of new APIs. Keep asking about non-functional requirements. Chair discussions and provide a voice of experience for developers. Educate people where appropriate. Facilitate the right conversations. Read important code commits.
- Help prioritise the work. Product owners will naturally order work to deliver the next most valuable feature, and to quickly learn about their users. Architects will want to order work to test and learn about the solution. This conflict needs good negotiation and compromise to avoid a solution that either doesn’t work for users or isn’t technically sound.
- Provide assurance to technical stakeholders, such as other developers, that your team is making good decisions. Share these decisions and why you made them. This will avoid a lone developer from your team having to defend these choices to the CIO at the coffee machine.
Recognise when the current approach becomes a threat
Product owners care about what projects are being done and why. They care about balancing commercial and customer needs, and handing over new function to the business efficiently. They also care about some long term decisions, especially if they affect quality, cost, security, performance or team morale. But their roadmap is usually only written in detail for a few sprints, perhaps over the next two or three months. Most design decisions are made during the iteration planning process.
Architects have a different focus. They care about where your business capability will be left after a particular set of projects. They care about how implementation choices might help or hinder the business in future. They care about the things that are hard to change within the chosen patterns and frameworks, and the irreversibility introduced by the iterative process itself.
The electric light did not come from the continuous improvement of candles
This quote is attributed to management professor Oren Harari. It teaches us that a team working iteratively on an application is unlikely to make any innovative breakthroughs. They will never decide to build a new application. They have no authority to take that risk. The investment is outside of their remit. And without intervention, they will continue to work iteratively regardless of the benefit. At some point it will become uneconomical.
So where in the agile process do we spot this is happening and take action?
There’s not much discussion of this in the agile literature. Perhaps that’s because it can’t be addressed within the development process itself, and the responsibility for it is probably not with the product owner. Investment and risk at this level are strategic questions that have no place in the world of iteration planning. Product owners regularly balance priorities and sometimes challenge them, but rarely do they set them or write the business cases for them.
For me, it’s at this strategic level that the full value of architecture can be realised. It’s outside of your day-to-day processes. It’s working alongside the management team and the business strategy. It can still be iterative and responsive, but on a timescale of quarters, rather than weeks. An architect should be able to:
- Present broad options to support the current roadmap of features, along with some cost-benefit analysis. The default position is usually that the architecture does not need to change. And with a suitable architecture this may be true: the development teams will be fine working on each feature iteratively. But sometimes, a group of features together will justify an investment that each of them alone would not. It is important to exploit these opportunities, and get buy-in on the increased cost and risk.
- Scenario test the architecture against tricky new features or directions. For example, how difficult would it be to support a native mobile application or integrate with a partner? Would you need to begin investing now to ease this project?
- Stress test the architecture against possible risks. For example, if a third-party service you use was to disappear, what would the impact be and how could you recover? Do you need to invest to mitigate that risk?
- Present opportunities that the architecture provides. Build proof-of-concept demonstrations. Get people excited about the possibilities that the platform provides to spark business cases around them.
To do this effectively, the architect needs not only to have intimate knowledge of the systems, but also to be well-briefed on the organisation’s latest plans and thinking. These provide vital context for assessing the relevance and value of design decisions on the ground, and for steering the investigation of opportunities and risks.
At its heart, architecture is about making good investment decisions. We shouldn’t let the idea of agile architecture fool us into thinking that we can change everything easily. And we shouldn’t let the popularity of iterative development distract us from making well-planned investments. To achieve this, architecture is a topic that needs regular management team attention, and proper representation either from an architect directly or a well-briefed CIO.
I hope to explore exactly how this can work in a future post.
How is software architecture represented in your organisation?
Andy Worsley 