Is your IT architecture built to fail?

After spending over a decade in IT architecture, and working with various government, healthcare and private organisations, I’ve seen first hand how small design mis-steps can snowball into project failures.

An Architect’s vision should be clear and precise, which is normally to deliver business value through technology simplicity rather than fixating on building the perfect solution.

IT architecture can sometimes feel like walking through a minefield, with any mis-step potentially leading to disaster. If you're not careful, you might find yourself knee-deep in a project that's over-budget, off-schedule, and full of technical debt.

To help you navigate these treacherous waters, here's a guide to the 10 things you absolutely should NOT do when designing IT architecture.

1. Don’t ignore business needs 

A shiny architecture that ignores business needs and business requirements is just an expensive paperweight.

It’s tempting to jump right into the technical details, but ignoring business needs is like designing a mansion without asking the owner if they even want a house. IT architecture must align with business goals, or you’ll end up with a shiny, expensive system that nobody uses. There’s a huge difference between a ‘good to have” and a ‘need to have’ system.

If you don’t capture and lockdown business requirements, designing and building your architecture becomes a bit like baking a cake without a recipe - you might end up with something edible, but it probably won’t be what anyone wanted. It’s crucial to gather clear, detailed requirements before you start building anything. If you don’t, you’ll find yourself constantly reworking and patching your architecture to meet moving targets.

To illustrate the point, a recent project I observed was greenlit based on vague, high-level objectives. As the project progressed, new “must-have” features kept popping up, which led to constant redesigns and a bloated budget. By the time the project was delivered, it was over budget, late, and still didn’t meet all the requirements.

Many businesses have adopted agile as their IT project methodology, and I often hear this used as an excuse for not gathering detailed requirements upfront. Agile doesn’t mean you should skip the requirements stage, it just means that you are gathering your detailed requirements incrementally for the features you are developing in this, or the next, sprint. And all of this should be done in the context of a carefully considered, high level architecture design.

2. Avoid over-complicating the design

Some architects seem to think that the more complex a system, the better. This is the IT equivalent of adding too many spices to a dish. More often than not, less is more.

The objective of IT architecture should always be to “simplify the complex”.

Keep your architecture as simple as possible while meeting the requirements. Simplicity leads to easier maintenance, scalability, and adoption. Adding too many interim solutions to your designs also causes complexity and technical debt which is difficult to mitigate once the project goes live. Avoid it wherever you can.

3. Never forget future scalability

Build for today, but always plan for tomorrow’s traffic jam.

It’s easy to focus on the here and now, but ignoring scalability is a recipe for disaster. What works for a small team might crumble under the pressure of a growing user base.

I learnt this one the hard way. I once worked on a project where the network firewall and switching infrastructure was not adequately designed to cater for increasing demand, which caused chaos when the project went live. Definitely some lessons learnt there!

Scalability is vital in architecture design because it ensures your system can grow alongside your business. As your user base expands and data increases, a scalable architecture allows you to handle the extra load without needing a complete overhaul. This approach not only saves costs by enabling incremental upgrades but also maintains consistent performance, so your users don’t experience slowdowns when demand spikes.

4. Don’t neglect security

Skipping security is like leaving the front door wide open - it’s only a matter of time until an unwanted guest walks through it.

In today’s world, security needs to be a key consideration from the start, whether it’s encryption, access controls, or regular security audits.

True Story: A few years ago, IBM experienced a security failure on the A$10 million IT contract for Australia's first predominantly online census. IBM was the lead contractor for the five-yearly household survey by the Australian Bureau of Statistics (ABS) that went offline the day after it was launched. The website was flooded with clicks due to a simple security configuration that was missed, causing four distributed denial of service attacks.

Security is paramount and should never be treated as an afterthought.

5. You can’t ignore User Experience (UX)

A user-unfriendly system is like a joke with no punchline - nobody’s laughing.

You can have the most technically sound architecture in the world, but if the user experience is poor, nobody will care. Think of your architecture as the backstage of a theatre production - the audience doesn’t see it, but they sure do notice when something goes wrong.

If a Healthcare App with an excellent backend architecture requires users to click through 10 different screens to accomplish a simple task, the users will abandon it.

6. Never choose the ‘cool’ technology over the right technology

We all love shiny new toys, but sometimes the tried-and-true option is better. Don't choose a technology just because it’s trending - make sure it’s the right fit for your project’s requirements and can deliver the actual value. No one is interested in getting a thousand new features when all they’re really interested in is the one feature they actually need to do their job well.

Complexity and overhead should never outweigh the benefits. Choosing a bleeding-edge NoSQL database for a project that really just needed a simple relational database can result in weeks of troubleshooting and a frustrated team while a more traditional database could have matched actual needs.

7. Don't underestimate the importance of documentation

Documentation might not be glamorous, but it’s essential. Without it, you’re building a house of cards. What happens when the original architects leave? Or when you need to update the system in a year?

No documentation or inaccurate documentation leads to knowledge gaps, inefficiencies, errors, compliance issues, increased cost, and can impact overall organisational effectiveness.

8. Failure to test can lead to testing times

Skipping or inadequately testing your solution is a sure-fire way to turn launch day into doomsday.

You wouldn’t buy a car without taking it for a test drive, so why would you deploy architecture without testing it thoroughly? Skipping testing is a fast track to failure. We saw a global-scale example of this recently with the CrowdStrike-Microsoft outage. Every micro-change to your code base needs to be thoroughly tested before you go live. If you don’t take those extra few hours or days, it can create huge problems for your organisation. 

I once worked for a business that launched a new e-commerce platform, and the project team skipped load testing because they were "sure it would handle the traffic." On launch day, the site crashed within minutes, costing the business thousands in lost sales.

Test, test and test again. The one time you don’t do it will be the time you regret it.

9. Avoid overusing the “Swiss Army knife”

A Swiss Army knife is handy—until you try to use all the tools at once.

Every IT architect dreams of building that one system that does it all. But trying to make a system that can solve every problem is like creating a Swiss Army knife with 100 different tools - it becomes unwieldy and ineffective. Instead of building a system that tries to do everything, focus on doing a few things exceptionally well.

A project I once encountered involved a content management system that was also supposed to handle email marketing, customer relationship management, and even payroll. The result? It did none of these well, and the team eventually had to strip it back to its original purpose.

Sometimes, it’s okay to say, “Maybe we should buy another tool for that.”

10. Don’t underestimate Change Management

This is an important one. People naturally resist change because the status quo often feels a lot more comfortable than the new and unknown. Without proper change management employees may resist new systems and processes leading to slow adoption of the solution.

If you don't plan for change management, even the best architecture can fail.

Underestimating change management can lead to resistance, operational disruptions, inadequate training, reduced ROI, and cultural misalignment. Effective change management ensures a smoother transition, enhances user adoption, and maximizes the benefits of new systems or processes.

Avoiding these pitfalls can save you countless headaches and ensure your IT architecture is robust, scalable, and aligned with business goals. Remember, IT architecture isn’t just about technology - it’s about people, processes, and making sure the whole system works harmoniously together.

And hey, if all else fails, at least you’ll have some good war stories to share at the next industry conference.