(Editor’s Note: What follows is a Part I of a 6-part series written by Iasa Global Founder and CEO Paul Preiss. Each part will appear on Wednesday.)
By Paul Preiss
Design methodologies for architecture are relatively difficult to find, especially those that relate to both technical and business outcomes. One of the goals of the BTABoK was to create a ‘method to the madness’ for current architects and architecturally significant decisions. Keep in mind, in this article, we are referring to the design of the combination of business and technology areas, so the design of a purely manual business process is not part of our consideration (see Iasa definition of architecture). We are going to discuss the following model for design relationships and a structured approach using the BTABoK structured canvas approach.
Taken from BTABoK Design Article: https://iasa-global.github.io/btabok/design.html
So what is this diagram? In the context of architecture we often talk about design as a single thing. We design software, we design automated build environments, we design services. However design turns out to be complex set of interactions with design decisions, requirements, and options for a decision. These are further complicated in their relationships to the overall solution space. The larger the Scope of the solution space the more complex the set of relationships.
As we consider a design the most important outcome of this process is not the models we use but the decisions we make. These decisions are what lead to value outcomes like business benefits, risk, technical debt, etc. These decisions flow through the delivery process and ultimately control the maximum amount of value derived by our client for the solution. (Article on Clients???). These decisions are at the core of what great architecture is all about and why architects study more than just technology or cost factors in design.
Keep in mind that a) not all decisions in a solution space are architecturally relevant, b) decision input is often facilitated across teams or experts in a depth areas, and c) most decisions link to other decisions and must be balanced (conformance) across the solution. One great architect I met said our job is to make sure that ‘no one gets everything they want, but everyone gets enough’ which I hit very close to home.
Requirements
So we talk about stories, epics, requirements, use cases, and all of the other names used to describe a thing we want the solution to look like, taste link, withstand, function like, etc. The BTABoK uses Architecturally Significant Requirement because is the most recognized in any methodology (though we have specific cards matching with Agile Architecture). I think it is easy enough to show what an ASR looks like for you to understand what makes it significant.
ASR Card from Requirements (https://iasa-global.github.io/btabok/requirements.html)
As you can see what makes an ASR ‘architectural’ are its characteristics. Cost, novelty, risk etc. In addition ASRs come in multiple types. Functional ASRs provide clear functionality which can be linked directly to a business objective (OKR). Quality Attribute ASRs are those that provide cross-cutting impact on structural outcomes like performance and reliability. Finally, constraint ASRs may link to an architectural principle, a standard that must be followed, or other constraints which limit the options open for the design decision. For example, if the solution must be PCI compliant.
Design is partly the act of deciding on a solution to an ASR. However, ASRs are not in themselves valuable unless they can be measured. So it is essential in design that the requirement be linked to an OKR or a fitness function which can be measured against risk or impact to the solutions functional requirements such as performance.
Options
Anyone who has designed systems (or even dog houses) knows that once you start reading or making requirements a bunch of options pop up in your head (‘we could use React, hmmm or React Native, Angular, Vue, or others?’). These options just can’t help but pop up even in the most basic description of a solution design space.
Options come in many forms. Technology breadth includes the options of using different technologies to the solution design space. Technology depth relies on deeply understanding a technology choice and being able to utilize it for maximum benefit and the strongest quality attribute support. Patterns are reliable solutions to common implementation problems. Reference models are a grouped set of design decisions and patterns within a technology space, normally within a technology depth area. (the next article will cover Design Options in depth).
Figure 1 Design Landscape
The design landscape is a set of three canvases which lay out WW02 or TOGAF technology stack. But instead it lists all the types of technologies that you might want to implement based on a requirement, but in there generic ‘technology type’ kind of way. The goal of the design landscape is to help think about solutions without thinking about products or specific technologies. This helps to setup the solution to the requirement without getting bogged down. Think of it like a flavor wheel in a wine tasting… it helps you think about things you might need and then asks you to decide if you really need it. As you will see in a future article, if you were doing this process sequentially as opposed to the web-worked fractal that is creative thinking, you would use these icons to populate a context view of the solution. But let’s save that for part 2 or 3.
Decisions
Decisions are the heart of architecture. If requirements help us shape the objectives then decisions help us sculpt the final graceful curves of the finished product. All too often, models are considered architecture. Here is a reference model from MS Azure…
Figure 2 Azure Reference Architecture
If you were shown this diagram you might be told ‘this is an architecture’ for a Highly Available Web Application. However, those of you familiar with modern architectures in Azure would immediately spot the problem with the diagram… Namely, that it is OLD. It has been updated since to recommend what Microsoft considers to be today’s decisions. The current model looks like this:
Figure 3 Up to Date Reference Architecture
Any programmer will tell you this is a MUCH different beast. We have added service busses and changed the API App and Web Job into a Service Bus and Function Application. So what’s the big deal? WE HAVE NO IDEA WHY! This change in decisions will make the application functionally different, it will work with different cost profiles, state management, will require the use of a drastically different way of coding and will likely lock us into Azure (hmmm, now why would they do that? 😊). I could duplicate this example a dozen times from a dozen different vendors, solution design and real world projects.
Decisions, not models are the snapshot of architecture, though of course we still love models which help us understand and get to the decisions. Enter the architecturally significant decision record. The ASD as we fondly call it, is a workable one page decision management engine. In future installations of this series we will show the scope and numbers of ASDs (and ADRs) on different products with different complexity estimates.
Figure 4 Architecture Decision Record Template
They ADR is a bit complex and we are going to have couple of articles dedicated to it (as well as the spin off versions in excel and markdown), but for the time being notice the big sections. The top area describes the decision and links it to a requirement this ensures that we are working through traceability and not just design overload. It also describes the scope of the decision which will impact the next area. The right column defines the HOW the decision will be made. How reversible it is, how long do we have to make the decision itself, what information quality we need (never 100%!), and the effort we will put into it. In addition we can describe the owner the process the authority type, and the consequences. This thinking helps us shape the decision from a 1 hr whiteboarding (or canvas and sticky notes) to a year long study.
The card obviously has the 3 options (why 3 and not 2 or 4? Limited space and time) and the areas on which we will compare them. Areas are the things like cost, support, existing skillset, etc that will allow us to show WHY we made the decision. Here is a mocked up example of the previous serverless decision:
Figure 5 Fake Example of an ADR
You can find all of these canvases in a mocked up miro board of the Iasa canvases we will be covering in these articles here: https://miro.com/app/board/uXjVORNRx4s=/?share_link_id=155880042988
I am looking forward to this Design Series based on the BTABoK. Here is my current thinking on the order they will come in:
- Dissecting Design – And Introductio
- Options, Options, Options – So Many Choices
- Deceptive Decision Making – Why Aile Architecture is so Hard
- Views and BEYOND – Thinking, Facilitating and Communicating
- I Like Patterns – Patterns , Reference Models and Conformance
- Assessments, Tests and Chasing Perfection – How Governance and Architecture are Different
Ok I might make all of those in 6 weeks (I might not) but here’s hoping.