Some of them were great. Some of them were expensive mistakes. The difference had nothing to do with how elegant they were. It came down to one question: did the architecture serve the business?
Here’s the core of what I believe about architecture: great software architecture is only great if it puts the business need first. Technical excellence matters, and I’ll come back to that. But it’s a means to an end, never the end itself.
It’s easy to see how architecture drifts away from the business. Architects and engineers are rewarded, informally at least, for technical sophistication. The interesting problems are technical. The conference talks are technical. The résumé bullet points are technical.
So without anyone meaning to, priorities shift. Teams build for scale they’ll never reach. They adopt patterns because they’re modern, not because they fit. They spend months on a platform migration that changes nothing for a single customer.
Here are some signs your architecture has drifted:
Putting the business first doesn’t mean doing whatever the loudest stakeholder asks. It means the business need is the starting point and the test for every architectural decision. In practice:
Start with the capability, not the technology. Before anyone draws a box, be able to say what the business needs to do, and why it matters. “We need to onboard a new customer in one day instead of two weeks” is a business need. “We need a microservices platform” is not.
Speak the language of the business. Gregor Hohpe describes the architect’s job as riding the elevator between the penthouse and the engine room. If you can’t explain a decision in terms of cost, risk, revenue, or customer experience, you haven’t finished making it.
Tie every significant decision to a business driver. The Architecture Decision Records I’m so fond of have a section called Context. Put the business reason there. If you can’t fill it in, question the decision.
Right-size quality to the need. In There’s More to Quality Than You Think, I argued that quality has many dimensions. Business-first architecture means deciding how much of each one the business actually needs. A trading platform and a cafeteria menu app deserve very different answers.
Measure outcomes. Did order processing get faster? Did the customer complaint rate drop? Did the new product launch on time? Those are the metrics that tell you whether the architecture is working.
In my 2018 post on what enterprise architects do, I wrote that a solution architect’s “loyalty is to the business, not to the technology.” I still believe that, and I’d extend it to everyone who designs systems.
That means being willing to recommend the boring option, the off-the-shelf product, or the option that doesn’t need your team at all. It means being willing to say, “We don’t need to build this.” Some of the best architecture work I’ve seen resulted in less technology, not more.
Now the other half. Putting the business first doesn’t mean ignoring technical health. Technical debt, security weaknesses, and fragile systems are business risks. They just tend to be invisible to the business until it’s too late.
Part of the architect’s job is to make that risk visible in business terms. Don’t say “we need to refactor the billing service.” Say “every change to billing currently takes six weeks and has caused two revenue-impacting incidents this year. Here’s what it would take to cut that to one week.” The first sentence is a technical preference. The second is a business case.
When architects do this well, they stop having to fight for technical investment. The business funds it, because it understands what it’s buying.
This blog is about battling complexity, so I’ll end there. A lot of the complexity I’ve seen in enterprises comes from misalignment. Systems were built for needs that never existed, for scale that never came, or for a strategy that changed three years ago. That’s complexity with no business value behind it, and it’s the most expensive kind.
When architecture stays tightly focused on what the business actually needs, a lot of that complexity never gets built in the first place.
In 2018 I proposed a Product Manifesto. Here’s a companion for architects:
Business outcomes over technical elegance
Capabilities over platforms
Fit for purpose over best in class
Clear trade-offs over hidden costs
There’s value in the items on the right. Elegant, best-in-class platforms are wonderful things. But great architecture always values the items on the left more.
]]>Gregor Hohpe’s Platform Strategy: Innovation Through Harmonization argues that it doesn’t have to be that way. Done right, a platform can standardize and speed teams up at the same time. Hohpe calls this the platform paradox, and the book is about how to get it right.
It’s the follow-up to The Software Architect Elevator, and like that book, it’s practical, full of memorable metaphors, and grounded in real experience. (The print edition credits Michele Danieli and Jean-François Landreau as co-authors.) It covers what platforms are, how to set a strategy for them, how to design and build them, and how to organize teams around them.
Here are Clif’s notes.
Traditional IT standardization works by restricting. You may use these three databases and no others. You must file a ticket to get a server. The standard reduces variety, and it slows people down in exchange for control.
A real platform standardizes by enabling. One of Hohpe’s examples is HTTP. It’s a strict standard, and because everyone follows it, millions of people have built things on top of it that its creators never imagined. The standard didn’t limit innovation. It made innovation possible.
That’s the paradox. When a platform takes care of the common, undifferentiated work, it frees teams to spend their effort where it matters. Harmonize the foundations, and you get more innovation on top, not less.
One of the most useful parts of the book is a contrast between platforms and traditional IT services. Roughly:
| Traditional IT service | Platform |
|---|---|
| Request it with a ticket | Use it yourself, on demand |
| Built for control | Built to enable |
| Usage is mandated | Adoption is earned |
| Resists change to stay stable | Evolves continuously |
| Becomes a bottleneck as it scales | Gets better as it scales |
Run your own “platform” through that table. If it has a ticket queue, a mandate, and a backlog of unhappy users, it’s probably an IT service with a new name.
Hohpe’s most memorable image is the difference between a fruit basket and a fruit salad. A fruit basket is a bundle of separate things: here’s a source repository, a CI tool, a wiki, and a Kubernetes cluster. Good luck. A fruit salad is something new made from those ingredients, with the work of combining them already done.
Lots of organizations call a fruit basket a platform. They’ve bundled tools together, but every team still has to figure out how to wire them up. That’s not a platform. That’s a shopping list.
This is the idea I think architects most need to hear. When teams try to “reduce cognitive load,” they often just hide settings. Default ten of the twenty parameters and call it simpler.
Hohpe points out that this frequently makes things harder. Behind each parameter is a concept. Hide half the concepts, and users are left trying to understand a system with missing pieces, like doing a jigsaw puzzle with half the pieces removed. Real simplification means building a better abstraction: a new, smaller set of concepts that actually makes sense in your domain. And the abstraction has to be honest. A platform that pretends networks never fail isn’t simple. It’s an illusion, and illusions eventually break.
This connects directly to Simple Isn’t Easy. Hiding complexity is easy. Removing it is simple, and much harder.
Because adoption is earned rather than mandated, platform teams have to think like product companies. They need to know their users, prioritize ruthlessly, make trade-offs, and even market what they’ve built. A platform is an indirect value creator: it only produces value when other teams use it to build something.
That’s a different skill set from running infrastructure, and the book is candid that many organizations underestimate how high the bar is.
My favorite line in the book is a test you can apply to any platform:
If your users haven’t built something that surprised you, you probably didn’t build a platform.
Hohpe also warns against the “pyramid” approach to business platforms: a grand design where common functionality sits at the bottom and every business unit’s needs are neatly anticipated above it. It assumes you can predict what everyone will need, and you can’t. As he put it in an interview about the book, we stopped building pyramids thousands of years ago for good reasons. Platforms should grow from real usage, not from a master plan.
I’ve argued that every organization has a complexity budget, and that you should standardize the boring parts so you can spend that budget where it counts. Platform Strategy is the best guide I’ve found to doing that well.
It’s also a warning. A badly built platform is one of the biggest sources of enterprise complexity there is: one more system everyone depends on, that nobody likes, and that can’t change. It’s the “one system to rule them all” I warned about in my vendor warning signs post, built in-house.
The difference between those two outcomes is the thinking in this book.
You can get it as an ebook on Leanpub or in print. Read The Software Architect Elevator first if you haven’t. Then read this one before you build your next platform.
]]>But I’ve been in this industry long enough to recognize a pattern. When something that used to be expensive suddenly becomes cheap, we make a lot more of it. That’s usually good. It isn’t always.
AI has made writing code dramatically cheaper. It has not made understanding code any cheaper. It hasn’t made operating, securing, debugging, or changing code any cheaper either. Those costs are where complexity lives, and they scale with how much code you have, not with how fast you produced it.
None of these are hypothetical. If you’re using AI tools at any scale, you’ve probably seen most of them:
The good news is that the principles that kept systems simple before AI still work. They just matter more now.
The same goes for AI systems themselves. It’s tempting to build a fleet of autonomous agents with elaborate orchestration because the demos are impressive. Even the people building the models suggest otherwise. Anthropic’s guidance on building effective agents comes down to this: start with the simplest thing that works, and add complexity only when it clearly improves the result. That’s good advice for any technology. It’s nice to see it given about the newest one.
People keep asking me whether AI will make architects and senior engineers obsolete. I think it does the opposite. When anyone can generate code, the scarce skill is knowing what not to build, where the boundaries should go, and how to keep a system understandable as it grows.
That was always the job. AI just made it harder to ignore.
]]>Gregor Hohpe answered the same question much better, with one image: an elevator.
His book, The Software Architect Elevator: Redefining the Architect’s Role in the Digital Enterprise (O’Reilly, 2020), grew out of his years as a chief architect in a large enterprise and his earlier collection, 37 Things One Architect Knows About IT Transformation. It’s written as a series of short chapters you can read in any order, which makes it easy to pick up between meetings. If you’re an architect, an IT leader, or an executive who works with architects, it belongs on your shelf.
Here are Clif’s notes.
Picture your organization as a tall building. At the top is the penthouse, where executives set strategy and make investment decisions. At the bottom is the engine room, where engineers build and run the systems that make the business work. In between are a lot of floors full of middle management, process, and translation.
The problem is that the penthouse and the engine room rarely talk to each other directly. Strategy gets watered down on the way down. Technical reality gets filtered on the way up. By the time a message has passed through enough floors, both sides are making decisions based on a version of reality that isn’t quite true.
Hohpe’s answer is that the architect’s job is to ride the elevator. A good architect is comfortable in the engine room, close enough to the technology to know what’s real. A good architect is also comfortable in the penthouse, able to explain technology decisions in terms of business outcomes. And they move between the two often, so both floors stay connected.
That’s it. That’s the job. It’s the best one-sentence description of enterprise architecture I’ve come across.
One of my favorite ideas in the book is that you describe the same decision differently on different floors. In the engine room you might say, “We’re running the database in a multi-zone configuration with standby replicas.” In the penthouse you say, “We chose to spend a bit more so that an outage won’t cost us customer data or a day of sales.”
Both statements are true. Neither one is dumbed down. They’re aimed at what each audience needs to decide. An architect who can only speak one of those languages is only doing half the job.
Hohpe makes a case I’ve found very useful with finance-minded executives: good architecture is like buying options. A financial option gives you the right, but not the obligation, to do something later. Architecture works the same way. A clean interface, a well-placed abstraction, or a decision to avoid lock-in costs something now, and in return gives you the ability to change direction later without starting over.
The value of an option goes up as uncertainty goes up. In a stable, predictable world, you don’t need many options, so you can build things simply and directly. In a fast-changing world, options are worth a lot.
This is a very practical way to fight complexity. Every bit of flexibility you build in costs something. So don’t add flexibility “just in case.” Add it where you’re genuinely uncertain, and be able to explain what option you’re buying and why it’s worth the price.
The book spends a lot of time on why traditional IT organizations struggle to move fast, and why that matters more than it used to. Organizations built for cost efficiency and control tend to treat change as risk to be minimized. Digital companies treat speed itself as a competitive advantage.
One theme I especially like is “if it hurts, do it more often.” Annual releases are painful because so much change piles up between them. Frequent, small releases are less painful because each one is small. The same goes for many things we avoid: deployments, upgrades, migrations. Avoiding them doesn’t remove the pain. It saves it up.
Hohpe treats the organization the same way he’d treat a technical system: it has structure, feedback loops, and behavior that emerges from how it’s put together. That’s why reorganizations often fail to stick and why symptoms like buggy software often have causes far from the code, such as overloaded teams or bad incentives.
For anyone trying to simplify an enterprise, this is a crucial insight. A lot of technical complexity is really organizational complexity in disguise. You can’t fix it with a new framework.
The thread that ties all of this together is alignment. When the penthouse and the engine room are disconnected, complexity grows in the gap. Executives fund initiatives without understanding their technical cost. Engineers build sophisticated solutions to problems the business doesn’t actually have. Nobody sees the whole picture, so nobody can make it simpler.
An architect who rides the elevator closes that gap. They can tell leadership, “This initiative will add three new platforms we’ll have to run forever. Here’s a simpler option.” They can tell engineers, “The business doesn’t need five-nines here. Ninety-nine and a half percent will do, and it’s a much simpler design.”
That’s how architecture becomes a tool for simplicity instead of a source of complexity.
If you enjoy it, Hohpe has continued the series with Platform Strategy and Cloud Strategy, and he writes regularly at architectelevator.com. I’ll have notes on Platform Strategy soon.
]]>Now try to remember the last time a leader was celebrated for removing something.
It’s rare, and that’s a problem. Organizations are very good at adding and very bad at subtracting, so complexity only grows in one direction. Each addition makes sense. Taken together, they bury the teams that have to live with them.
The bias toward adding isn’t a character flaw. It’s built into how organizations work:
Subtraction isn’t just turning off servers. Here are places leaders can take things away:
A word of caution. Before you tear something down, find out why it’s there. This is Chesterton’s Fence: don’t remove a fence until you know why someone put it up. Sometimes the annoying approval step exists because of an audit finding. Sometimes the odd integration is holding up a revenue stream. Subtraction without understanding is just another way to create risk.
So do the homework first. Then, once you understand why something exists and you’ve confirmed the reason no longer applies, remove it fully. Don’t leave behind a half-retired system that still needs care and feeding.
If you lead a technology organization, here are a few ways to make subtraction normal:
Anyone can add. It takes judgment, and a bit of courage, to take away. The leaders I’ve admired most were the ones who left their organizations simpler than they found them.
]]>If I were writing that post today, I’d spend most of it on one practice: the Architecture Decision Record, or ADR.
The idea comes from Michael Nygard’s 2011 post, Documenting Architecture Decisions, and it’s almost embarrassingly simple. Every time your team makes a significant architectural decision, you write a short document, usually a page or less, that records:
That’s it. You store them in the code repository next to the code they describe, number them in order, and never delete them. When a decision changes, you write a new ADR that supersedes the old one.
ADRs succeed where most architecture documentation fails, for a few reasons:
This is the part that matters most for this blog. ADRs are one of the best tools I know for keeping complexity in check.
They make complexity spending visible. Every new database, framework, or integration pattern should come with an ADR. Suddenly you can see your complexity budget being spent, one decision at a time, with a reason attached.
They stop the same argument from coming back. How many hours has your team spent re-debating a decision made two years ago because nobody remembered why it was made? With an ADR, the conversation starts at “here’s what we knew then; has anything changed?”
They make subtraction safer. Chesterton’s Fence says don’t remove something until you know why it’s there. ADRs are the note left on the fence.
They pair well with AI-assisted development. When a growing share of code is written by AI tools, recording the human reasoning behind the architecture becomes more important. An ADR is also great context to give those tools, so they follow your decisions instead of quietly overriding them.
Don’t turn this into a program. That’s how good ideas become evil documentation. Instead:
docs/adr folder in one repository.If you want templates and tools, adr.github.io has a good collection. But honestly, a Markdown file with five headings is all you need.
So, is documentation evil? Not this kind. This kind might be the most useful half hour your team spends all week.
]]>Here’s what I mean. Your organization can only understand, operate, secure, and change so many things at once. Every system, integration, vendor, programming language, deployment pipeline, and “special case” uses up part of that capacity. Spend more than you have, and the effects show up somewhere else: slower delivery, more incidents, longer onboarding, and the same few people who are always on every escalation.
The authors of Team Topologies describe this at the team level as cognitive load. A team can only hold so much in its head, and when you give it more, quality drops. I’d argue the same thing applies to the whole enterprise.
Complexity spending rarely looks like a big decision. It looks like this:
None of these is wrong on its own. That’s the trap. Each spend is reasonable, and the total is what hurts.
You can’t manage a budget you can’t see. Some practical ways to make complexity visible:
The goal isn’t zero complexity. Some complexity is the point. It’s where your competitive advantage lives. Dan McKinley’s idea of innovation tokens is really a complexity budget with a nicer name. You get a few. Spend them on what makes your business different, and choose boring, proven, shared solutions for everything else.
A few rules of thumb I’ve found useful:
If you’re an enterprise architect, this is your job, whether or not it’s in your job description. You’re the one person whose scope covers the whole enterprise. You can see that the budget is overspent when each individual team can only see its own line item.
Making that budget visible, and helping leadership spend it on purpose, may be the most valuable thing an architecture practice can do. It’s certainly more valuable than another reference architecture nobody reads.
]]>“Let’s keep it simple and just use the platform we already have.”
Sometimes that’s exactly the right call. But often, when you dig in, “simple” means “the thing I already know.” The platform we already have is going to be stretched, customized, and wired into places it was never meant to go. It’s easy to start with. It isn’t simple.
Rich Hickey made this point better than anyone in his talk Simple Made Easy. If you haven’t watched it, stop reading and go watch it. I’ll wait.
Hickey’s distinction goes like this:
Simple is objective. You can look at a design and count how many concerns are braided together. Easy is relative. What’s easy for your team may be hard for mine.
The trouble is that we use the words as if they meant the same thing, and in a design review that’s dangerous. “Easy” gets the credit that belongs to “simple,” and complexity sneaks in disguised as convenience.
Once you see the distinction, you’ll see it everywhere:
The Swiss Army platform. The CRM is also the case-management system, the document repository, and the workflow engine. Each extension was easy, since the platform was already licensed and the team knew it. The result is one system tangled up with four business domains, and nobody can upgrade it without a six-month regression effort. (I called this “overloading the switchboard” in my vendor warning signs post.)
The shared database. Letting the new service read straight from the old service’s tables is easy. No API to build, no contract to negotiate. It’s also one of the most complicated things you can do, because now two systems are tied together through a schema neither one owns.
The framework of the month. Adopting the new framework your senior developer is excited about can feel easy. There’s lots of energy and a slick getting-started guide. But you’ve added a new concept to the portfolio that everyone after them will have to learn. Dan McKinley calls this spending an innovation token, and you don’t get many.
The “temporary” integration. The nightly file drop to an FTP server was the easy answer in 2014. It’s still running. It now feeds three downstream systems, and the only documentation is a comment in a cron job.
In every case the easy option was easy at the start, and the costs came later. Easy is something you feel during the decision. Simple is something you benefit from for years afterward.
This is the part people don’t like hearing. Simplicity usually costs more at the start.
Pulling two concerns apart means designing an interface. Building an API instead of sharing a table means agreeing on a contract. Choosing a dedicated tool over extending the platform you already have means a procurement process. Writing the small, focused module means thinking harder about where the boundaries go.
Fred Brooks split complexity into essential complexity, which comes with the problem, and accidental complexity, which we add ourselves. Most accidental complexity comes from choosing easy over simple, over and over, one reasonable decision at a time.
You don’t need a new methodology for this. You need better questions:
None of this means the familiar choice is always wrong. Familiarity has real value. A team that deeply understands a boring tool will often beat a team fighting with a “better” one. Sometimes simple and easy point to the same answer, and that’s a great day.
The goal isn’t to reject easy. The goal is to stop letting easy pass itself off as simple. Call each one by its name, weigh them honestly, and then choose on purpose.
]]>A lot has changed for me since then. I wrote those posts as an enterprise architect. Since then I’ve moved into IT leadership. Today I’m Vice President, Information Technology, and I lead IT, information security, and privacy for my company. That’s a different view of the same problem. As an architect, I saw complexity in the designs. Now I see it in the budget, in the risk register, in audit findings, and in the attack surface. Every system I’m responsible for has to be paid for, secured, and accounted for, and every unnecessary one makes all three jobs harder.
If anything, I believe in simplicity more now than I did then. So I’m bringing the blog back.
Here’s why. Since 2018 nearly everything about how we build technology has changed. We went all-in on the cloud. We split monoliths into microservices, and some of us are now merging them back together. Platform engineering became a job title. And now AI writes a growing share of our code. If you had told me in 2018 that I’d review pull requests written by a machine, I’d have asked which vendor was selling it. (Old habits.)
Through all of that, one thing hasn’t changed: complexity is still the thing that kills us.
It doesn’t happen in a dramatic outage or a failed launch. It happens slowly. It’s the integration nobody remembers building. It’s the approval process that takes three times longer than the change. It’s the platform chosen for the conference talk instead of the problem. It’s the service that “only Dave understands,” and Dave left in 2023.
I’ll put my cards on the table. These are the ideas that run through everything I’ve written and everything I plan to write:
I’ve brought back a handful of the original articles, lightly edited, because I think they’ve held up. Vendors still show up with new-car smell and silver bullets. Developers still claim that Agile means no documentation. And most teams still test only one dimension of quality.
There will be new writing too, about what simplicity looks like now: how to budget for complexity, why leaders should get better at subtraction, how to write documentation that people actually read, how architecture stays tied to the business, and what happens when AI makes producing code nearly free while understanding it stays just as expensive.
I’m calling these posts Clif’s notes. If you’re old enough to remember the yellow-and-black study guides, you know the idea: the short version, the parts that matter, and nothing you don’t need. That seems like the right format for a blog about simplicity.
I’ve also put together a reading list of the people who have shaped how I think about this: Rich Hickey, Fred Brooks, Dan McKinley, Martin Fowler, Gregor Hohpe, and others. Most of what I know about simplicity, I learned by reading people who said it better than I could.
If any of this sounds familiar, welcome back. If it’s new to you, welcome. Let’s go make something simpler.
]]>If you’re making a purchase then you have many different criteria to consider in selecting the right product. Some people look for cheap. Others look for durability. Still others, like me, look for quality. In my opinion, any time you’re looking to purchase a product or service for your enterprise, quality should be your main concern.
But how, exactly, do you measure quality? Thanks to the International Organization for Standardization, we do, in fact, have a way. It’s called ISO/IEC 25010:2011, or, as I like to call it, good old “Twenty-Five Ten.”
Twenty-Five Ten is an international standard for the evaluation of software quality. I have become a huge fan of this standard. It can be an incredibly useful tool both for evaluating software for potential purchase and for evaluating software that you develop for your own customers.
The standard defines quality by dividing it into eight distinct characteristics:
Keep in mind that while the points above focus on determining the suitability of a vendor’s application for purchase by your organization, there are plenty of other ways to use the standard. Software vendors can maintain this information and share it proactively as an assessment of the quality of their offerings.
In the past I have asked potential software vendors to tell me how they maintain compliance with this standard or, if they don’t currently use it, what techniques they use that could be mapped to it. Since all of the considerations above are valid, they should be able to detail what they do to make sure that their offering addresses them.
In one case, a software vendor let me know that they weren’t bound by ISO standards and didn’t have to answer the question. The response I wanted to make was, “Then we don’t have to buy your product.”
Another vendor went to great lengths to map all of their internal practices and methodologies to these characteristics for us. In the end, they were actually quite grateful for the question, as it helped them do a better job of quantifying the quality of their product. We did end up purchasing their product and were very happy with the purchase.
Another potential use of these characteristics was presented to me recently when a peer was sharing the progress of their recent RFP process. They had looked at several different products and had decided on a front runner. The problem with that product, however, was that peer reviews indicated concerns with certain parts of it. The vendor claimed that the new version of the product had addressed all of those issues, and the demonstrations did seem to support their assertion. To confirm this, the purchase could be made contingent on the vendor passing an external quality assessment.
There are external groups that provide this type of service. One such group is CISQ, the Consortium for IT Software Quality. They have used these characteristics to build a quality certification program that includes a metrics-based assessment methodology that can give a potential purchaser peace of mind. If the vendor’s new version and processes achieved an acceptable rating then the purchase could continue and everyone would get what they want. If not, the vendor would know exactly which areas they needed to improve. Again, a win-win.
The use case that I find the most interesting, however, is as a quality assessment tool for internal development. Whether you are an enterprise with many separate development teams or a software vendor with a large product base to maintain, this is a tool that could undoubtedly be used to improve the quality and reliability of the output of those teams. It is your choice whether to use these characteristics as a general guideline and develop your own framework, or to purchase a product like CAST to automate the enforcement of those quality rules.
One final thought for you on quality. The list above gives eight primary characteristics that make up the overall quality of an application or service. Most people test only the first one: functionality. If you’re someone who is concerned with quality and yet you are among those who currently only test functionality, just think about how much you are missing.
2026 update: ISO revised the standard as ISO/IEC 25010:2023. It now has nine characteristics. Safety was added, Usability became Interaction Capability, and Portability became Flexibility. The point of this essay still stands: if you only test functionality, you’re testing one characteristic out of nine.
]]>