Planning IT architecture: fewer dependencies, clearer decisions

Architecture describes responsibilities as well as systems

Architecture determines where data lives, how applications communicate and what happens when something fails. Those choices decide whether a new function is straightforward or first requires coordination between five suppliers and three datasets. A diagram full of fashionable products does not answer those questions.

Simple does not mean one server or the least technology at any cost. An extra backup or second application server may be justified. Complexity becomes problematic when its benefit is unclear, no one maintains it or dependencies emerge only during an incident.

Start with three concrete business workflows

Map processes such as handling an enquiry, fulfilling an order and issuing an invoice through applications, identity, storage and external interfaces. Include email attachments, spreadsheets and manual transfers; a server inventory alone misses these sources of delay.

Make requirements concrete. Can an enquiry wait ten minutes during maintenance? Must staff work through an internet outage? How many concurrent users are expected, and which information can arrive later? These answers guide hosting, synchronisation and redundancy more usefully than a blanket cloud-only or office-only rule.

When an extra component earns its operating cost

Each component needs a measurable trigger and an operational owner. A cache saving only a few milliseconds while stale entries repeatedly cause support work deserves reconsideration. Separating an import that blocks the whole application during office hours can have an obvious benefit.

• Cache: justified by measured repeated-read delays; define validity, refresh and failure behaviour.
• Queue: keeps slow background work from blocking requests; handle retries, order and failed jobs.
• Separate service: supports independent releases or substantially different capacity; own its interface, data and monitoring.
• Second site: supports a business requirement to survive site loss; test replication, failover and return regularly.

Monoliths and microservices are not quality levels

A modular application can have sound business boundaries and ship as one deployment. A distributed system can remain tightly coupled. Microservices permit independent development and scaling but introduce communication, consistency and operating requirements, as Microsoft's architecture comparison explains.

A small team releasing together may benefit from a modular monolith with clear interfaces between customers, orders and billing. A separate image-processing service can follow when its load grows independently. Containers can package either design; adopting containers does not require splitting an application into microservices.

Example: customer portal, inventory system and accounting

Giving a new portal direct write access to the inventory and accounting databases creates a shortcut but couples its releases to two external schemas. An update in either product may unexpectedly disrupt the customer workflow.

A clearer design names the inventory system as owner of operational customer records, accounting as owner of posted documents and the portal as owner of login data and display preferences. Agreed interfaces transfer the required information. Show its update time where necessary instead of promising real-time data that is not guaranteed.

This separation also costs effort: version interfaces, surface transfer failures and handle retries unambiguously. For a small internal tool, a simpler documented read interface may be adequate. Decide using change requirements, failure consequences and team capacity.

Record decisions and compare their full operating cost

An Architecture Decision Record captures one decision, its context, alternatives and consequences. It should be possible to supersede it explicitly. The AWS ADR process describes that lifecycle; preserving the reasoning matters more than document length.

A portal record might state that customer information remains in the inventory system because its staff maintain the authoritative record, while the portal displays a synchronised read view with an agreed delay. Revisit that choice when customers must make binding changes themselves.

Compare implementation, infrastructure, licences, support, onboarding and exit over the same period and requirements. Cheap hosting can be expensive if every adjustment needs rare expertise. Managed platforms may reduce work but introduce contractual and export dependencies.

Use concrete evidence in an architecture review

Begin with three views: the user journey across systems, responsibility for important data, and deployment across sites or providers. Label each connection's purpose and direction. Mark unknown transitions as questions instead of hiding missing knowledge behind an apparently complete diagram.

Add recent relevant changes and incidents. Which dependency surprised the team? Where did several teams have to act together? What caused recurring manual work? Derive a few justified changes rather than replacing the entire environment according to personal technology preferences.

Three demonstrations make the target design testable

For changeability, trace a typical business change through the components, people, manual steps and approval time. For recovery, test an important workflow's expected fallback or restoration in a suitable environment. For handover, ask a second person to perform a routine task using only the documentation.

Agree success criteria first: a response time, recovery window or release completed without asking the original developer. Values must fit the business. The objective is progress against observed constraints, not a universal architecture score.

Build a roadmap with triggers

Not every possible extension needs building immediately. Start with stable operation and link later investment to a measured condition. Separate a background task when it repeatedly breaches the response-time target; add a second site when the process needs site-loss tolerance even if traffic is low.

Give each decision an owner and review trigger: changed hours, substantially more users, a new data category, expiring contract or repeated incidents. These triggers justify investment and preserve options more usefully than an arbitrary complete redesign every few years.