The solution architecture design activity is critical for most (larger) IT initiatives and therefore needs careful planning. And by careful, I don’t mean a plan with hundreds of tasks, but something more than the anti-pattern of “we’ll see how we go for this sprint” or the dreaded “develop solution architecture” task.
The below is an attempt to break down and structure the architecting activity. It’s a simple matrix of the required activities for developing any solution. I hope it can help structure your efforts, especially if you are following one of the many Agile-like methods out there.
The approach is built around a simple 3 by 4 matrix breaking the architecture activity into 12 discrete activities.
The Three Columns: Function, Operation, and Change
A solution architecture should address at least three separate design concerns:
- Function – what is the intended function of the system?
- Operation – how do you operate the system?
- Change – What kind of development environment does it need to implement changes beyond the initial project delivery? How do you manage the impact of change?
Any of those three concerns can be documented using the traditional architectural views (IASA or TOGAF).
The Four Rows: Problem statement, Logical Solution, Technology Implementation and Trade-offs
Each design concern is split into four layers (aka rows): a problem specification (or use case, a set of requirements), how it is solved (logically, not tech), the technology implementation, and the (main) optimisations.
- Problem statement: This is the summary of the architectural significant requirements or the main problem statement. It is not the 308 individual user stories or the 2178 lines of itemised business requirements. It is the summary of what is believed to be significant enough to influence the design of the architecture. You write this, not the business analyst.
- Logical Solution: This activity is about the solution for your defined problem statement (and not about technology). If it is too trivial, then you’ll need to check a couple of things: Is the problem statement actually a solution definition? Is the technology implementation portrayed as the solution? I find this separation of concerns (problem vs solution vs technology) useful, as you can define the solution (as it should ideally work) without the worries of the technology landscape. The next two rows are about dealing with the real world implementation, its constraints and compromises.
- Technology implementation: This activity determines the required (and viable) technology, and how it should be used to implement the defined solution. Because the solution is defined separately, it is now easier to perform a gap analysis between what’s possible and what should happen (aka tech debt?). It also enables you to discuss different functional components using the same technology platform without mixing the two.
- Optimisation: This is optional, but suggested for technologies that cannot fully implement a solution. For example, caching technologies can help a system meet response time expectations. Why separate this? Because a cache is a work-around that impacts the solution, e.g., the cache refresh complicates having “up to date” data and the “write” latency. Again, the importance of the solution definition is to understand what’s a compromise and what’s not.
Putting it together
When you arrange the three columns and four rows into a matrix, you’ll get the below result. It suggests a row by row sequence starting from top left corner working your way down to bottom right corner. However, it is not the only way to sequence the activities. Skipping a row or leaving a column blank isn’t advised, but possible.
There are a number of ways the matrix can help guide the architecture design activity.
The problem statement row prompts a requirements review. Do the use cases or requirements cover all three aspects (function, operate, and change)? This should remind (or challenge) you to think about the problem statement(s) more holistically and enable you to check with your stakeholders what they really want.
The matrix offers a simple activity classification regardless of your chosen documentation template or viewpoint. The main benefit is sorting out what is a requirement, a solution, a technology decision, or an optimisation choice. Blank cells don’t necessarily need to be filled, but they serve as reminders.
Progress can be planned and tracked by working your way through the matrix. And you can plan one or more cells into Agile sprints, if required / desired.
Focus on the right question – e.g., you shouldn’t move directly from the problem statement to technology implementation. For example, an Oracle database is not a solution. It could be a technology implementation choice for an operational data store, which is a possible solution for a record keeping requirement.
Improved review sessions. The matrix supports more iterative review sessions by allowing you to focus on reviewing particular cells. Similarly, feedback can be organised into the correct cell, if it’s unrelated to the active review session. For example, “Solution | Function” reviews could discuss the functionality of a storage component without needing to discuss the technology (Google Object Store vs Hadoop vs Oracle database). Solution vs technology choice, not the same thing…
I was once asked to explain what I do as an architect (working in the IT industry). After some reflection, I came to the conclusion that my job is about helping people find meaningful structures in what would otherwise seem like chaos. The above matrix doesn’t replace your usual set of skills and techniques; nor should it. But it is intended to help you help people find meaningful structures.