IT Architecture in Business: Why the Most Expensive Decisions Get Made by Developers on Tuesday at 2:30 PM — and the Board Has No Idea

Picture this. Tuesday, 2:30 PM. A developer picks a database for a new, small module. Clicks, reads, searches — 20 minutes. Chooses the one that sounded cool at a conference they went to last month. Four years later, the same company pays $70,000 a year to a consulting firm to handle a migration to a different database, because the first one no longer fits what the business built on top of it. Nobody on the board authorized that first decision, because it was “technical.” They only authorized the second one, because it was financial and showed up in the budget. This is the classic trap most companies fall into. Architecture is a business decision. The business just doesn’t know it yet.

Key Points

• Architecture is not code. It is a set of decisions with a high cost of change. You choose once and live with the consequences for years. You won’t see those consequences for the first 18 months. After that, you’ll see them all too clearly.
• There are no good architectural decisions. Every one is a tradeoff: you gain something, you lose something. The classic: fast, good, cheap — pick two. In IT, there are even more corners to that triangle.
• Dilemmas like monolith vs. microservices, buy vs. build, cloud vs. on-premises data center look technical. They are business decisions. Without knowing the business, you can only guess.
• The main trap: if your architect isn’t asking the business about tradeoffs, they’re probably building architecture for themselves, not for you. Success kills weak architecture faster than failure.

Architecture Is Not Code. It Is Decisions You Can’t Cheaply Undo

The simplest definition you’ll find in books: architecture is the stuff that’s hard to change. Architecture is a set of design decisions with a high cost of change. You choose once and live with them for a long time. They’re hard to change because one change pulls the next. If you swap out your database, you have to change every system that talks to it. That often reaches all the way to the user interface, because everything above is built on those decisions.

The easiest way to show this is with examples from outside IT. A McDonald’s kitchen and a Michelin-star restaurant kitchen. Same industry, same ingredients, same goal: feed the customer. But completely different architecture. Dropping a McDonald’s kitchen into a Michelin-star restaurant won’t work. The reverse won’t either. Or Porsche and an off-road SUV. Both expensive, both “cars.” Porsche is great on straight coastal roads in summer. An SUV is great in the mountains in winter. Swap the roles: disaster. A Porsche won’t get anyone with skis to the lift. These are architectural decisions, and they are not interchangeable.

Software works exactly the same way. Choice of core technology, data model, boundaries between systems, how you communicate with vendors. Each of these things later shows up in code, in contracts, in SLAs with suppliers. Architecture is not code. Architecture is consequences you don’t see for the first 18 months. And then you see them for the next 5 years.

Four Dilemmas That Look Technical but Are Business Decisions

Every architectural decision is a tradeoff. The classic triangle: fast, good, cheap — pick two. In software architecture, that triangle has more than three corners, but the logic is the same: the architect chooses between different kinds of bad, not between good and bad. Their job is to pick the bad that hurts your business the least. Without knowing your business, that’s a shot in the dark. Below are four decisions that at first glance look like developer topics. Each one has a business question at its core.

Monolith vs. Microservices

Microservices sound great. Every team owns its piece, everyone deploys independently, everyone grows at their own pace. The price: three times as many people to maintain it, much more expensive infrastructure, harder to understand the whole system. That setup makes sense with 50 people in IT and millions of users. With five developers, probably not. The business question is: where do we want to be in 6, 12, 18 months? Are those five people the target state, or do we have the money and know we’re growing? Without that answer, it’s a random choice.

Data Consistency vs. Development Speed

On one side: balances always match, every change is auditable, all users see the same version of the data at the same moment. The price: every change in the system takes longer, costs more, is harder to undo. On the other side: fast hypothesis testing and fast development. The price: sometimes a colleague sees an updated name five hours later. On LinkedIn, that’s no big deal. If it were a company account number someone needs to wire money to, that would be a problem. Your specific business decides which side of this dilemma to choose. A bank chooses differently than a startup testing an idea.

Build vs. Buy

Build your own: full control, one-to-one fit, no monthly fees. The price: three months of a developer team now, instead of a working solution in a week. Buy off the shelf: fast, someone else maintains it, recurring cost instead of a one-time investment. The price: vendor lock-in, risk that the vendor goes under or raises prices. The decision is a business one, because it concerns your cash flow, your risk, and your speed to market.

Fast to Market vs. Built to Last

A startup building a web service can ship fast, get feedback, land a first customer, and survive. The same startup building “properly” for two years may discover someone else won faster, or that nobody needed their idea. On the other hand, “fast” in fintech ends with a regulator audit and a fine. The choice belongs to the business, not the developer.

The conclusion: if your IT vendor, software house, or in-house team isn’t asking about these things, they’re not warning you. They’re building architecture for themselves, for their own habits, or for whatever is trendy on LinkedIn right now. That rarely matches what your business actually needs.

Architecture Drivers: Six Questions You Should Hear from Your Developers

Before an architect makes a decision, they should know the answer to six questions. There is no one global answer, because every business gives a different one. You should recognize these questions, because you’re the ones who have the answers.

• Scalability. How many users, how many transactions, how sudden are the spikes? E-commerce on Black Friday vs. an internal HR tool are two different worlds.
• Availability. What happens if the system goes down for an hour? Duolingo will survive. A dispatch system for ambulances will not.
• Time to market. How fast can we ship a change? A startup searching for a business model needs weeks. A bank needs predictability and audit trails, not weeks.
• Cost. Not just build cost, but total cost of ownership over 5 years. A system deployed for $75,000 that then throws errors and needs six months of patching costs $150,000, not $75,000.
• Security and compliance. GDPR, financial regulation, HIPAA. These constraints land on the architecture before the first line of code. Late compliance means rewriting the system.
• Talent. Who will maintain this system in 2 years, in what job market? Maybe it’s worth spending more now so the technology is easier to maintain with cheaper developers or AI agents later.

Four Businesses, Four Architectures

Here’s how the same questions produce completely different answers across four types of business.

Seasonal E-commerce (think Modivo, Allegro)

What matters: survive Black Friday, run 24/7, fast catalog changes, sales funnel analytics.

Fitting architecture: cloud that scales automatically with traffic, data close to the customer (CDN), infrastructure capacity on standby.

Poor fit: servers in the company basement that you have to drive to on Black Friday to buy more disks. Sounds like a joke. People still do it.

Fintech or Bank

What matters: data integrity, auditability, compliance (financial regulation, PSD2). We cannot afford to send the same transaction twice, or credit one person and fail to debit another.

Fitting architecture: proven, boring technology, strict data consistency, SQL database, every transaction 100% consistent.

Poor fit: a trendy, experimental tech stack from a conference a year ago. An audit won’t pass it.

Early-stage B2B SaaS (3–5 developers)

What matters: land the first paying customer, keep costs low, pivot fast if the market says “not that way.”

Fitting architecture: simple modular monolith, popular tech stack (easy to hire), managed services instead of building your own (chat from Twilio, payments from Stripe).

Poor fit: microservices “because Netflix does it.” Five developers cannot maintain thirty microservices. The board read about it on LinkedIn. Developers should push back at that point. This is one of those moments where technical fads brought in from LinkedIn via management destroy a company faster than competition.

Healthcare

What matters: GDPR, an audit trail for every change, customer data separation (patient A never sees patient B’s data), data retention (sometimes keep for 5 years, sometimes delete right after the visit).

Fitting architecture: encryption everywhere, full operation logs, ability to deploy on-premise in hospital infrastructure.

Poor fit: standard SaaS storing data in US-East-1 on AWS. A GDPR audit arrives and the project is over.

These are four different projects, four different answers. An architect with one recipe for everything is a red flag. A good architect starts with “what do you actually do and for whom,” not “what database are you planning to use.”

Technical Debt: A Loan Whose Interest You Don’t See Until You Do

Every quick shortcut in code is a loan. You pay it back with interest for years, but you won’t see it in the P&L. Until you do. Then you see it far too clearly.

There are two types of debt, and they differ in scale.

Local debt. In some small or medium piece of code, developers took a shortcut: skipped tests, hardcoded a parameter, skipped validation. Relatively easy to fix. A week, two, sometimes a month.

Global debt — architectural debt. This is serious. We built the system around a specific external vendor who is now raising rates by 200%. The team says: “we need six months to rewrite and detach from them.” Or: we chose a database that can’t handle scale and now everything slows down. Or: we have no boundaries between modules, so every change in one place breaks three others.

Fixing local debt when the problem is global is a dead end. Developers put out fires, but the house is still burning for a different reason. That reason is an architectural decision made long ago that nobody consciously reviewed.

And here’s a question worth asking: who in our company handles technical debt, and from what budget? If you don’t know, probably nobody is handling it, and it just keeps growing. If you know your IT director handles it from a separate pool and it works, good. The worst answer is “it’ll probably sort itself out.”

Red Flags: How to Tell When Architecture Is Eating Your Business

You don’t need to understand code to spot these signals. You can see them with the naked eye in day-to-day company work.

• We only deploy on Friday evening or only on Monday morning. The team is afraid of its own system. Friday releases so they can escape for the weekend. Monday releases so they have five days to fix things. A healthy team deploys daily, automatically, without human involvement.
• “Nobody understands this except Mark.” Mark goes on vacation and half the company stops. That’s not employment. That’s hostage-taking. There’s a metric called bus factor: how many people would have to get hit by a bus for the company to stop working. Yours is 1.
• The roadmap is stuck because “we have to clean up first.” The whole sprint went to refactoring. The next one too. And the one after that. Technical debt is eating you from the inside, and business conversations about priorities stop making sense because “we have to clean up first anyway.”
• Every new feature breaks three old ones. Classic symptom of missing boundaries between modules. Developers start putting “regression” on the roadmap as a separate task.
• Estimates grow month over month. A feature that cost 5 days a year ago now costs 20. Reason: every change requires working around three things from past compromises.
• Infrastructure bills grow faster than user count. That means a lot of resources are being wasted somewhere inside, and the architecture prevents optimization.

If you have three or more of these symptoms, you’re in a tough spot. It won’t fix itself. You need to form a team, secure budget, and officially say: we have to get our house in order. And after you do, figure out how to make sure you don’t end up here again in a year.

Want to Work Through This Systematically?

The list above is signals you can see with the naked eye. A full technical health self-assessment covers 60 points across 6 areas: architecture, testing, CI/CD, observability, data, security. Each point is one specific practice and the specific risk it prevents.

Download the Technical Health Checklist and go through it with your team.

Scale Kills Weak Architecture Faster Than Failure

Here’s a paradox worth understanding. Weak architectures don’t blow up when a project goes badly. They blow up when it goes unexpectedly well.

Meaning: as long as you have 100 users a day, everything works. Maybe not perfectly, but it works. You get on morning TV, buzz builds, 100,000 users in one day. The architecture that handled a hundred collapses at a hundred thousand. A memorable Polish example is mObywatel — Poland’s official mobile government app. On day one: hundreds of thousands of installs, hundreds of thousands of digital IDs generated in a few hours. The infrastructure crashed and couldn’t recover all weekend. The reason: the architect didn’t plan for what happens when we get flooded with requests and need to recover. Plus a big bang release — changes deployed everywhere at once, with no gradual rollout. Success took them down, not failure.

The same thing happens at smaller scale. An influencer posts about your app, traffic grows 30x in an hour, the business is thrilled that someone famous wrote about you. An hour later the servers go down, users leave, 1-star reviews start rolling in. Most teams don’t know how much their system can handle. Because there’s no time to write load tests, because the business didn’t order them, because “it works for now.” Until it has to work 10 times harder.

This is a question for your CTO or head of IT worth asking once a quarter: how many hours of downtime can our business absorb, how much more traffic can our system handle, and what stops working if our cloud provider goes down for 4 hours? If the answer is a shrug, nobody has checked. That’s not information you can make up in your head.

Three Things to Remember

First. Architecture is a business decision, not a technical one. Technical people should explain tradeoffs to the business, and decisions should be made together. The architect should be an advisor, not the decider (unless they’re a C-level CTO — then it’s fine). The right question for IT isn’t “why did you choose that database,” but “how did you choose and who did you ask.” That’s the only thing you can judge clearly: not the outcome of the decision, but how it was made.

Second. There are no good architectural choices. There are only worse and better tradeoffs. The architect chooses between different kinds of bad. Their job is to pick the bad that hurts your business the least. You can’t do that without knowing the business.

Third. Success kills weak architecture faster than failure. Scale amplifies every problem. Decisions that worked with 5 customers fail at 5,000. The earlier the business starts talking with IT about where we’re headed, the fewer expensive migrations in 4 years.

And a one-liner to remember: if your architect is bothering you with database choices, microservices, and tradeoffs you don’t want to hear about, that’s a good sign. You’re already paying. If they’re not bothering you, you’re paying too — you’ll just find out on a Tuesday at 2:30 PM, four years from now.

Not sure where your architectural decisions stand, or seeing IT make them without you and you only find out when the bill arrives? Contact us for an architecture audit. We’ll help map where your current architecture supports the business, where it limits it, and design the conversation between IT and leadership so the next big decisions get made at the right level.