One of the topics many people fail to understand is the intimate relationship between business strategy and system and software architecture. This is the case for folks on the business side as well as many engineers.
To illustrate this, one company I work with is involved in standardization in the context of home automation. It provides devices that integrate into a home automation system, an area several of the SaaS giants, such as Google and Amazon, are quite interested in. These large players are, obviously, looking for a situation where they have free access to all devices in a home and can collect all the data, control every aspect of each device and provide integration across devices.
The standardization process is largely driven by the big SaaS companies and they went in with the above strategy. However, when all the intelligence would move to these large players, our company would be relegated to a basic provider of mechanics and hardware. It would cut off the digitalization dimension of differentiation for the company and, in the worst case, cause the company to only be able to compete on cost.
As the company, like many others, had resource constraints, it sent an engineer to the standardization meetings, who focused exclusively on the technical qualities of the APIs that were being proposed as part of the standard. It was only during the workshop I had with the company that the implications of this approach became obvious: by pursuing a technology-first agenda, the company was cutting itself off from some very important business strategy options.
As a typical example that I’ve experienced several times, system architects optimize the products of the company for the lowest bill of material cost, which typically involves limiting the CPU performance as well as the memory size to the absolute minimum required by the product at the time the production starts. Although a reasonable and frequently followed strategy over the last decades, it’s obvious that this invalidates any opportunities for the company to adopt DevOps and the ability to complement transactional product sales with recurring revenue from providing new functionality.
The point of these examples isn’t to claim that architects are idiots (typically they’re among the smartest people I know) but to illustrate the close relationship between technical design decisions concerning the system and its software architecture and the company’s business strategy. When considering this, three aspects benefit from being discussed: who makes decisions, when are these decisions taken and how do we validate them?
First, although many fail to recognize this, in practice it’s the system and software architects who set the real business strategy for the company. As the above examples illustrate, if the architecture doesn’t support specific business strategies, these strategies can’t be realized. The architectural design decisions make certain business strategies easy or even trivial to implement and others prohibitively expensive. Hence, business leaders may set the strategy, but the actual realization may fail or not materialize due to incompatible system and software architectures.
Second, architectural design decisions often take a long time to get fully implemented and incorporated into the product or product portfolio. For new products, the development process simply takes the time it needs and we may find out along the way that changes are needed to the design decisions. For existing products, there typically is a backlog of activities and architecture refactoring is typically not highly prioritized. Consequently, in practice, major architectural design decisions that are needed to enable more radical business strategy changes need to be taken 12-36 months before the business strategy needs to be operationalized.
Third, all decisions we make, including the ones concerning architectural design, are based on a prediction of what their expected outcome will be. However, for all our best efforts, we may be incorrect and consequently, we need to evaluate the impact of architectural design decisions. The challenge is that the technical impact is typically quite easy to assess, but the impact on the business is much harder to establish. It requires close collaboration between business and R&D to find suitable mechanisms to run cheap, fast and yet informative validation experiments.
The Agile paradigm excludes architecture from the key concepts it concerns itself with. This is, in my view, a major omission as architecture is so central and critical for business and R&D success. Product and system architectures aren’t static and can evolve, but the architecture of a system tends to evolve much slower than the features and functionality of the system due to the cross-cutting effects that architectural design decisions tend to have.
Although the word “architecture” is heavily overloaded and often used in vain, many fail to recognize the close, intimate connection between business strategy and system and software architecture. This requires awareness from the business side of the company and close and continuous involvement of architects in the exploration of business strategy options. Executing on a new business strategy often requires architects to have made the right decisions a year or more ago and then to have incorporated the implications in the system and software architecture. As a business leader, if you fail to realize this, you likely end up feeling like you’re flying a plane where the controls aren’t connected to anything. To end with a well-known quote from Jim Rohn: what good things we build end up building us. That’s as true for product companies as it is for society at large.
Want to read more like this? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch) or Twitter (@JanBosch).
