By Paul Preiss
There are numerous articles on making better decisions in the delivery of working systems. The purpose of this article is to begin delving into some of the more common techniques in use by effective teams to design, analyze and improve the architectures of complex systems. The goal of the article is to combine the excellent work in analytics of systems which combine both built systems as well third party libraries or even SAAS-based components. In addition, we will begin to combine both business-related assessment methods with more technical evaluation techniques.
I will be teaching all of these techniques in Architecture Core in Dublin on Oct 3: https://www.ictskillnet.ie/training/iasa-foundation-course/
This is the first of many articles on these topics so I will simply be setting the stage for further discussion on each of these methods and hopefully follow on in my podcast with their authors or ‘owners’. I will as much as possible give credit (if I miss something please put it in the comments as I have every wish to highlight the people who created these techniques).
So what are the differences between the two and why are they important? In my study of architects, we constantly refer to business and technology. So much so that they lose direct meaning. We use requirements, stories, features, and similar methods to ‘evaluate’ business, and yet these things in and of themselves are not measurably impactful to what we consider business outcomes. They effectively become the measures of success, while in many cases the larger opportunities go unnoticed. The Kodiak digital camera comes to mind. Even in this article, I am using disruptive technology (markdown with gitpages) which undermines the ‘value’ of all the features in MS Word. It was a single app that changed the transportation world. And another that changed the hospitality industry. So we must evaluate the business side of our systems differently. I like to consider this the science part of our work, and while true academic rigor is likely out of our reach, science is fundamentally about measurement and the attempt to repeat outcome measures using similar if not exactly repeatable techniques.
The business assessment techniques and measures I will discuss in this and future articles are:
- Objectives and Key Results
- Business Capabilities
- Investment Prioritization and Roadmaps
- Benefit Realization
- Customer Behaviors
- Iasa Engagement Maturity Model
On the technical side, I was fortunate enough to just finish reading Software Architecture Metrics, which is is a compilation of articles which I hope to explore on my podcast with the brilliant authors of the book. Many of the references to technical evaluation methods or technical assessments in this article will make reference to that book, which is excellent for understanding the structural decisions that make those repeatable business outcomes possible.
The technical analysis methods I will discuss in this and future articles are:
- Views, Viewpoints, Design Languages
- ATAM, PBAAM, SARM
- Module Maturity Index
- Process Improvements and Automation
- Fitness Functions (which I also believe can also be adapted to business outcomes)
- Architectural Mentoring, Peer Reviews, Assessment
- Assessment tools
Form, Structure, and Function
Before diving into these techniques, I’d like to clarify a concept that will help to highlight the differences in analysis and design. In building architecture there are constant discussions about form, structure and function. Form is the output of a building process, it is the way the building ‘feels’ including things like negative space which is as important as the building itself. If you’ve ever stood in the middle of a gothic cathedral, the granduer of the space is partially due to the sheer amount of space it surrounds. Form also identifies the outcomes of the building. The style, the feel, the design elements which make it both striking and interesting. Function, on the other hand is how a building is used. I like to think of of it as where the plugs are in a meeting room. Put 16 plugs in a meeting room all in the ceiling in the back right corner. It could still arguably have meet its ‘functional requirements’. And yet the form is sacrificed because the true function was not understood. Finally structure is what connects form and function. If you have ever visited a building site before it is finished you see its structure. Form is realized by structure which enables function. This is the heart of architecture both in the business technology world and in the building world. The only difference is how we define form. Form in the BTABoK is business value or value to the client and the client’s customer. In many ways, it defies the notion of stakeholder requirements as many requirements actually work against the value the project was supposed to deliver (I will definitely do a piece on this). So our job as architects is primarily to enable, create or conjure up form (value) by ensuring structural concerns which enable function (essential features).
What About Analysis
So after that rather esoteric discussion what about all of these analysis tools? How do we make this real?
The first step is to realize that each of the tools we are discussing helps us understand the systems we create in different ways and they can be used at different times, with different levels of formality, and with different stakeholders. None of them can be fully mastered nor is there ‘one ring to rule them all. Like all tools, you use them when they are needed. But the first AHA moment that most of my students and mentees have and what we find in most of our assessments is that a team is thinking only on one axis, either the business or the technical.
So the first step to making these real is to understand that you need to have analysis skills on both sides of the equation. When we teach Core we always start with the business. It is quite fun to teach a software developer expecting to start out with hexagonal architecture patterns, layer analysis, and architecture design views, and actually try to understand a business model. It is even more interesting to watch them learn why this is important to even the most technical decision.
Business Analysis Tools
There are a never ending supply of business books and business methods in the world but the tools that I have found most useful to architects fall into three main areas a) understanding the business and customer, b) extracting measurements from the operating and revenue models, and c) how the organization invests in and delivers change.
I am not going to re-iterate the BTABoK here but to contextualize this a bit, you design very different software for a bank than you do an army. Understanding business models provide a clear picture of WHY WE ARE DOING THIS THING IN THE FIRST PLACE. Oh I know that’s why we have product owners right? Nope, doesn’t work, product owners are not technical enough to deep dive into the structural implications of many important decisions. And while yes a few of them are (just like there are developers who understand enough business) in general these people end up becoming… yep, architects. So to understand your system and analyze it from a business perspective.
1. Look at the business model and business capabilities. These will give you deep insight into where the money comes from and who the customer is and why the company exists.
2. Extract key measurements (OKRs) from these areas. You may need to dig deeper into these to reach the level of project you are doing, which I will show you in a future article. (Hint: take a look at Benefits Dependency Networks).
3. Look at where projects originate (business cases, hallway conversations) and how they are funded.
4. Understand how staff and budget are assigned (investment prioritization). This will show you the true stakeholders and how change is enabled. This analysis will give you a glimpse of the politics of ‘success’.
5. Once you understand these items, compare them to your backlog. Can you make links to what we call Architecturally Significant Requirements? Can you identify items that are more important than others? Ones that directly impact customers (I only use the word customers for people who give the client money…. employees are always stakeholders)?
This is the beginning of understanding a system from a business perspective and it will literally double the quality of the systems you design and build. It will also provide you with significant ammunition during design decisions and in facilitating discussion among stakeholders.
Technical Analysis Tools
Most people don’t believe me but this is actually my favorite part of architecture too… it wasn’t until I learned the power of understanding business techniques that I truly understood how much of an engineer I was, nor some of the silly design decisions I made. The structure is the root of excellence in technology. Code level excellence is a must but it is how that excellence emerges over time and adapts to its environment that we truly begin to understand a system’s quality attributes.
The first thing to note is that quality attributes are systemic but they are primarily structural in nature. But for them to be useful they also have to be measurable. If you review the list of quality attributes from ISO 52010 you will find a) there are a lot of quality attributes and b) some of them are very very difficult to measure. I think my favorite is ??? Teachability??? I mean seriously… how on earth do you measure that? So for a quality attribute to be useful it must be measurable.
This was one of the more memorable aspects from the Software Architecture Metrics book. The MMI was developed to provide structural assessments which include both quantitative and qualitative measures while reducing to a reasonably understandable outcome and an actionable set of steps to improve in lower scoring areas. I highly suggest every architect buy and read this book.
Again since this is primarily an introduction article I will start with a simple list for architects to follow.
1. Start with the basics. What are you designing and how far in the future are you looking? Use views from a viewpoint library, but for god’s sake keep your models simple and as generic as possible. Never, ever publish a model without a legend. Visual languages are slippery little bastards. A dotted line could mean asynchronous or simply a partial dependency. You can’t help having to communicate with stakeholders but keep your internal models as basic as possible (I don’t care if you think pink or yellow make it look better).
2. Views were designed to make you think in different ways. What will performance look like, and how will it impact layering? Did we think about geography and the size of data transfer?
3. Remember design and analysis are really the same things. They are about creating effective decisions for a requirement based on a set of available options. Use your experts to broaden those options but use decision records to track WHY you made decisions.
4. Patterns and styles are your friend until you begin to reach a certain density or a set of favorites. Patterns overly applied create horribly interconnected systems filled with complexity.
5. Design time coupling and runtime coupling are different. Design time coupling can be dealt with using architectural analysis methods. Runtime coupling requires a deep understanding of the domain… lots more on this later.
6. ATAM is likely the most successful analysis method for architecture in the world. It helps create what-if scenarios in which the designers must answer every increasingly difficult and wild possibilities. But it also uncovers many of our design time flaws before a line of code is ever written. PBAAM from Iasa is undergoing some work and is an amazing tool to ask better questions during reviews.
7. I’m going to do a whole article on fitness functions which are a way of automating architectural tests and scenarios into an evolving architecture. They are primarily structural in nature but I believe they will become a natural set of architecture tests just like patterns have become a natural and expected part of the design.
8. Finally don’t forget the amazing tooling that exists in the marketplace for understanding complex systems. From complexity to layering we can learn a great deal from these tools. I’m hoping to do a whole series of blog/podcasts on these tools.
So that was my introduction to architecture analysis. Lots more to write. I will be digging into these topics with examples and hopefully backing them up with interviews and blogs from experts in each. There were a few bullet points I didn’t cover but don’t worry I will get them soon.