A principle is a concept or value that is a guide for behaviour or evaluation.
This post presents a principled approach to architecture. These principles specify what I believe is important about architecture, without diving into any details about how an architect should work. No matter how an architect works day-to-day, by following principles, you can be sure you are providing value in the right areas.
As usual, this post is personal opinion, and I’m interested in hearing any differing or similar opinions in the comments.
Principle 1: Solutions
Architects should understand the distinction between products and solutions. Typically, this distinction is quite clear for people from product marketing and sales backgrounds, but less clear for engineers. Although on the surface the terms seem similar, there is an important distinction to be made between a product and a solution that should be understood and respected.
What’s a Product?
A product is a defined set of features or capabilities that are used “as-is” directly by an end user. The end user can benefit from the product quickly and effectively to gain from that product’s particular features. Thinking in terms of technology that we know about, each of Amazon’s individual services is a product. For example, EC2, S3, and SQS are all products (even though they are sold as services).
What’s a Solution?
A solution is the application of one or more products to solve a specific problem. Let’s consider an e-commerce startup that sells books online so that we can think in terms of technology that we know about. This particular startup needs to solve a problem of providing an online shopping cart for users. By combining the individual products of EC2, S3, and SQS, the startup can build a solution to a particular problem.
Thinking in Solutions
Now that we know the difference between products and solutions, you may justifiably be asking “so what?”. We can answer that question by looking at how we divide work. We already have excellent engineering teams (and AWS) building individual products and services for Workiva’s platform — no-one needs an architect’s help to do that. Instead, I would suggest that that one of the core qualities of a software architect is understanding how to build solutions out of products.
More specifically, architects should understand both what products and services are available in our internal platform, and what products and services are available through AWS, paying attention to the features that each of these products provide. They should then be able to combine these features into a solution for product-line or platform problems by following sound architectural patterns and principles.
Focusing on solutions provides a distinct path for working on new projects and new ideas — any new problem defined by the organization should ideally be solved by using existing products in a novel way. If we cannot find a solution using existing products, it is the architect’s job to understand why not: what can be improved, what gaps in functionality exist, or what new development needs to happen to solve this problem.
Principle 2: Alignment
Alignment is arguably the most important work that an architect does. Most of us have started out as individual contributors to a project, and only recently have moved to a position of architect. This shift in position implies a shift in focus away from individual contributions onto technical leadership. This shift can be very difficult, and problems that arise typically come from a lack of alignment.
As an individual contributor, it is relatively easy to be in alignment with your team just by doing a good job on the things you are assigned to do. By doing a good job on assignments, you get recognition, and eventually a promotion. If you continue to do well at your assignments you may eventually be asked to take on an architecture position. At this point, you have been trained to expect assignments, do good work on them, and to be rewarded for it. Unfortunately, this previous training sets you up for failure as an architect. As an architectural leader, it is now your responsibility to find the right problem to solve, instead of just solving the hard problems you have been given.
“This requires that you to talk to a lot of people and listen to their problems, and then place a bet on a solution to one of these problems that will actually both be feasible but will also be important to the success of the company or organization. Your manager might help identify people that you could talk to, but you must take responsibility for doing the legwork and making the final choice in problems to address and approaches to solve them.”
Wrapping Up
Architects are responsible for building a bridge between the engineering team and needs of the business. One way to accomplish this is by focusing on guiding principles like those I’ve outlined here. In this article I’ve listed only two principles that I feel are important to architecture: solutions and alignment. I’m sure there are many more. I chose these two because I feel they provide a complimentary approach to defining work: by focusing on solutions, you drive towards alignment with real business needs, and by focusing on alignment, you understand business problems and potential solutions that may solve them.
Aligning with the organization through a solutions-first approach allows you to provide clarity to business stakeholders on what problem you are solving and why, and it provides value to the engineering stakeholders by clearly understanding and communicating the features of each product and service we build and how they are used to solve customer problems. A win-win situation.