IT Architecture and Design for International Businesses

Most business systems were never designed. They accumulated. Every individual decision was reasonable at the time, made under time pressure by someone competent, and the result is an estate nobody fully understands — which is a different problem from an estate that is badly built.

IT architecture work is the practice of making those decisions deliberately and writing them down, before the cost of reversing them gets high. It is the least glamorous service on this list and the one that quietly determines the cost of everything else.

The four layers an IT architecture engagement covers

Identity. Who exists, how they prove it, what that entitles them to, and how access ends when someone leaves. This layer constrains every other one. An estate with a coherent identity model can adopt new systems quickly; one without will bolt each new system on with its own separate login, and the problem compounds.

Network. Sites, links, segmentation, remote access, and what happens when a link fails. Increasingly this is less about hardware and more about which traffic is allowed to reach what — but the physical layer still exists, and it still has opinions about your uptime.

Data. Where information lives, which copies are authoritative, who can reach it, how long it is kept and where it is legally allowed to be processed. Most estates have several answers to "where is the real version of this" and nobody has written down which is correct.

Integration. How systems talk to each other. This is where the fragile, undocumented, business-critical connections live — the scheduled task on a machine under a desk, the account that belongs to a person who left, the export that runs at 02:00 and that nobody knows the purpose of.

Why undocumented architecture is expensive

Undocumented IT architecture does not appear as a line item on any invoice. It appears as friction:

• Every change takes longer because it starts with an investigation.
• Quotes come back high and inconsistent, because suppliers are pricing uncertainty.
• Nobody can safely decommission anything, so old systems are paid for indefinitely rather than risk turning something off.
• Incidents last longer, because diagnosis has to reconstruct the design first.
• One person becomes irreplaceable, which is a business risk dressed up as loyalty.

That last one deserves saying directly. If a single person is the only complete record of how your systems fit together, their resignation is a material event and their leave is a period of elevated risk. Documenting the IT architecture is as much about protecting them as replacing them — being the single point of failure is not a comfortable place to work.

Designing for the business you are becoming

The common failure at both ends. Design for today and you will rebuild in eighteen months; design for a scale you will not reach for a decade and you pay for complexity you never use.

The workable middle is to identify which decisions are cheap to change later and which are not, then spend the thinking time on the second group. Adding storage later is cheap. Changing your identity provider, your data residency, or a naming convention embedded in a hundred places is not. Good IT architecture is largely the discipline of noticing which is which.

The specific questions worth answering early: are you likely to acquire or merge with another business? Will you need staff working from other countries? Is regulated data going to enter the estate? Is anyone going to ask you for an audit trail? Each of those constrains the design and each is much cheaper to accommodate at the start.

What we produce

The deliverable is documentation you own and can hand to anyone, which is the only sensible test of whether it is any good:

• A current-state map. What exists now, including the parts nobody was quite sure about. This is usually the first time anyone has seen the whole estate in one place.
• A target-state design. Where it should get to, with the reasoning recorded — particularly the options rejected and why, which is the part that stops the same debate recurring annually.
• A sequenced path between the two. Ordered by dependency and by risk, not by what is most interesting to build.
• A decision record. Short entries: what was decided, what forced it, what it rules out. Six months later this is the most valuable document of the set.

Written for the business, not for us. If the document only makes sense with us in the room, it has failed.

Where architecture work usually starts

Rarely as an abstract exercise. IT architecture work is normally triggered by something concrete:

• A move to Microsoft 365 that turns out to require identity decisions nobody has made — which is why migration work and architecture work are frequently the same engagement.
• An office move, a new site, or a merger.
• A security assessment or client questionnaire that asks structural questions the estate cannot answer, leading into risk management work.
• Growth that has outrun the original design — usually noticed when onboarding a new employee takes days rather than minutes.
• The departure, or impending departure, of the person who knew how it all worked.

Standards, without the theatre

We use established reference material where it earns its place and ignore it where it does not. Microsoft’s Well-Architected Framework is a genuinely useful checklist for cloud design decisions, and it is public — you can read the same material we do and check our reasoning against it.

What we will not do is produce a formal architecture artefact set for a forty-person business because a methodology says so. The documentation should be the smallest thing that makes the estate legible to a competent stranger. Beyond that it stops being read, and a document nobody reads is worse than none because it is trusted while it silently goes out of date.

For a concrete sense of what that analysis actually looks for, we wrote up the seven decisions a distributed business makes by default — audit log retention, who may consent to applications, the licence floor under Conditional Access — each traced to the vendor’s own published documentation. It is the informational companion to this page, and a reasonable way to check whether you want this work before you ask for it.

How the work is delivered

The bulk of IT architecture work is analysis and writing, which is why it travels well: interviews and reviews happen over scheduled calls, and the deliverable is a document set. Clients across South Africa, the UK and Europe run it entirely remotely.

The exception is anything physical. Comms rooms and cabling reliably contain surprises no inventory tool reports, so a first visit earns its place — free across the Helderberg and greater Cape Town, where we are based, and elsewhere either handled by someone local under our direction or scoped as travel. It is needed less often than people expect.

One thing worth knowing about where the advice comes from: we also build and run business software of our own, in production, with real users. That is a useful corrective. It is easy to recommend an integration when you have never had to maintain one, and easy to draw an IT architecture diagram that falls apart on contact with a bad mobile signal in a depot.

It ends with documents you keep whether or not the implementation goes to us. That is deliberate: an architecture assessment that only has value if you also buy the implementation is a sales exercise, and it produces different advice.