Solution Architecture is fundamentally the management of constraints. The ultimate constraints are the ones faced by all projects – time and money. Within the sphere of business technology these constraints have manifest themselves in different ways over the years. As each constraint gets solved the need to manage a particular constraint recedes into the background and other constraints comes forward. Managing a constraint that no longer needs management is not only wasteful, but it also takes our attention away from controlling the new opportunity.
Looking back, I think I’ve lived through four major ages of solution constraint, most organisations have moved from one to the next, but there are many pockets of organisations where people are still managing the constraints of an age long passed.
Age 1: The Hardware Constrained Age
Early in my career I helped a team of people who provided personal computing devices. This service was only offered to a select group who had excessively big budgets. I remember debating with a colleague why anyone would need 20 Megabyte of storage, no one had a budget big enough to buy a Gigabyte of anything, and even if they could there weren’t any systems capable of making that amount of storage available.
I remember being amazed by the capabilities of the very first Macintosh that I saw which I suspect was a 128 Kilobyte version, there weren’t many people that could afford the 512 Kilobyte model.
Where I worked people were doing serious engineering work on MicroVAX 3100 models which had a mind blowing 32MB of memory in them with teams sharing processors that sped along at 25MHz.
Hardware was so expensive that everything had to be built to fit into the footprint that could be afforded.
Solution design was quite straightforward, pick the right hardware for the task at hand, optimise things as much as you could and hopefully, you’d get something that would do the required work in a night. There wasn’t any point in designing too much into the systems because there wasn’t enough hardware available to do anything fancy. Most hardware had one job to do, because that’s all it could do.
Picking the right hardware wasn’t as simple as it might sound today, there was a lot of different hardware to choose from, each UNIX variant was built for specific hardware, each vendor had their own proprietary hardware and operating system. You tended to purchase all the hardware from the same vendor because if you didn’t the integration was your job, and that was a risky business strategy. Evaluating the performance of several types of hardware was serious work that required detailed technical skills.
Age 2: The Connectivity Constrained Age
One of my colleagues in the early days was called Paul and he was famous for the contents of a large wallet that he carried with him everywhere. Inside the contents of this wallet where the entirety of the organisation’s software library. The first version of this folder contained 5″ floppy disks; the wallet evolved through 3.5″ floppy disks and eventually ended up with CDs.
For those of you with a shorter memory than my own, this may seem like a crazy thing to do, why would someone carry a folder of CDs around? Because there was no other way of moving data around. The networks that we use every day, the Internet, home Wi-Fi, 3G/4G/5G cellular networks, didn’t exist. There were a few connections between different computers, but they were slow, and mostly constrained within an organisation. Each of the hardware vendors had their own idea of how a network should work, anyone remember DECLink and token-ring?
Later, organisations created connections between various locations within their organisation, but these were even slower than what you could do within a location. These wide-area networks were supplied by the local telco who were in many locations monopolies that saw this growing trend as a way to make a lot of money.
Teams sprang up whose job it was to make sure that the links between locations were optimised because getting it wrong could be an awfully expensive business. Overcommitting the network pipe between two production locations could have devastating consequences for the production organisation. Much of the time it was still quicker to put the data on a disk and mail it to the other location.
Systems needed to be designed to keep the network connectivity requirements to a minimum. Using devices within the local network was more cost effective than reading the same data across the network multiple times. When I first started working with email systems people regularly deployed small servers all over the network to try and avoid the wide area network costs, these were the days before email was a universally deployed tool.
Small data centres grew up in each location to accommodate the need for local resources.
This was, of course, all changed by the Internet. The availability of a connectivity utility changed things for everyone. The connectivity constraint diminished, and all those local servers disappeared – didn’t they? And all those teams managing the scarce wide-area network capability went on to do more interesting things – didn’t they?
Age 3: The Software License Constrained Age
With the cost of hardware plummeting, and the ability to connect services blossoming we walked into a new constraint – the software license. As the value derived by technology skyrocketed the people providing that technology decided that they needed to get their fair cut from the investments that they were making. How did they protect these investments? Through page-and-pages of license agreements written in legal terms requiring armies of people just to understand them and another army of people to advise people on how to get the best out of the license that they had purchased. We didn’t finish there; we still needed another army to count the number of licences that we were using and to stop the organisation from buying any more.
People designing solutions needed to consider the rules of each individual license to make the best use of the licenses that already existed or minimise the burden of new licenses. Many organisations created central database services just to minimise the license footprint from one database vendor, while at the same time locking themselves into using that vendor for a long time. Other organisations created reporting portals for systems to minimise the people who need a license to use the ERP system.
License vendors created mechanisms to stop customers moving to alternate solutions by signing long-term agreements with significant discounts for those willing to commit.
Some vendors became embedded within the psyche of organisations where significant intellectual capital was invested in a particular technology. Supplanting that technology with a cheaper, better solution was a demanding thing to do and many have failed in their quest.
Although at the latter end of it, we are still in this age. The armies managing licenses still exist, the technology to count the use of the licenses is still being deployed, the vendors are still making good money from the licenses. We still make design decisions on the basis that it constrains the license footprint.
Open source is steadily changing the world of licencing, but it’s going to take a long while for the third age to be completely overtaken by the next one.
Age 4: The Subscription Constrained Age
We used to buy a DVD and keep it forever; we owned the DVD even though we only watched the film once. We don’t do that anymore, we have moved to a subscription model – NetFlix, Disney+, AppleTV+ and on it goes.
The same has happened with technology, you may know it as “The Cloud”. The licensing age was characterised by one-off purchasing decisions, the subscription age is characterised by continuous adjustment of the blend of services being used. Organisations have a growing portfolio of applications and infrastructure they pay for as they use it.
This is where the parallels with media subscriptions gives us some insights into managing this constraint.
Does a single subscription to, say, Netflix give us more content than we could ever consume? Absolutely. So why do we also have a subscription to Disney+? Because we like a show that’s only available on Disney+. Does Netflix have a show that is like the one we like on Disney+? Sure, but it’s not the one on Disney+ and let’s face it the cost of a Disney+ subscription isn’t that big. Is it? But there’s also that new show on AppleTV+ that everyone is talking about.
Most subscription services don’t allow you to just buy the thing you want to buy, and if they can they’ll incentivise over-use of their service. Amazon is the master at this approach with both Amazon Prime and, from a technology perspective with AWS. In the case of Prime it’s all the additional services that you come to depend upon, in the case of AWS it’s the vast array of services blended with the data egress charges creating a huge disincentive to taking data out of AWS.
If subscriptions aren’t going to get out of hand solution designs need to manage the constraints. As a daft example, the best solution for a service may be for the database to be in AWS, the business intelligence to be in Azure, the business logic to be in a SaaS tool like Workday or Salesforce, the search to come from Google and the logging back in AWS. The problem is this service would be expensive and difficult to maintain. Whilst taking all the capabilities from AWS or Google or Azure may be a compromise for each of the individual services, managing this constraint, in this way, will provide a service that is easier to maintain and cheaper. But taking every service from a single cloud provider brings its own problems.
The armies of people managing software licensing in the previous age are rapidly being supplanted by an even larger army of people managing their way through subscriptions.
I used to joke that the best protected asset within software vendors was the licensing algorithm, I now joke that this role has transitioned to the team who create the subscription rules.
It’s Just Evolution
Having written this post, I was struck by parallels with the Wardley Mapping phases of evolution. In each age the constraint is moving up the stack as the elements lower down the stack move into the background as solved problems. The technologies in those lower levels aren’t going anywhere, they’ve just moved out of focus as they shift towards being utilities.
Focussing at the Right Level
I’ve highlighted throughout this post some of the places where people’s legacy practice needs to evolve to keep up with the new age. Teams that are still placing elevated levels of management on hardware in datacentres are likely missing the huge expenditure already taking place with the subscription providers of AWS, Azure and GCP.
Organisations who managed the internal WAN as the primary constraint have, hopefully, realised over the last 18 months how connectivity has moved beyond them.
The software license vendors are busy running around their customers seeking to secure their future revenue. In so doing they are seeking to slow the progress of the subscription providers. Many designs will be constrained by the need to consume these licenses beyond the point where they should have moved into a subscription service.
The subscription providers will continue to evolve at pace, this is the place where we need to be managing our constraints, delivering the best value to our customers for the right price. The model for how to do that is still evolving, but many organisations have already figured most of it out.
I’m not wise enough to know what the next age of design constraint is going to be, but I suspect we are heading into a world where the robots are doing more work and we will need to create systems that work well with the robots. I can also see all sorts of other constraints becoming primary: data sovereignty, privacy, security, cybernetics, skills, emissions. Testing is often a significant constraint on a design. I am glad that my job doesn’t involve predicting the future, many of us still have a hard time staying in the current age.
Header Image: This is a beach in the Outer Hebrides. The Queen used to park the royal yacht in the strait and have the crew row the family over for the day. The locals know it as Queen’s Bay. We also had it to ourselves the day we went.
3 thoughts on “The Four Ages of Solution Constraint”
I really enjoyed this post Graham, although having moved into video as my primary medium I feel as if I’m back in the The Hardware Constrained Age again, with a bit of Age 2, thrown in just to keep me frustrated : All the best – Steve
LikeLiked by 1 person
Thanks for the feedback Steve. I’ve been doing an amount with video also and have had to get used to upload and download speeds being an issue again.