Delivery slows and nobody can say why
Velocity falls quarter on quarter while headcount rises. The cause is usually structural — coupling that forces coordinated releases, or a data model that makes every feature a migration — not effort.
Enterprise Architecture consulting
Architecture decisions are the ones that are expensive to reverse. We help CIOs, CTOs and engineering leaders make them deliberately, document them defensibly, and sequence the work so delivery keeps moving.
The problems this addresses
Work of this kind is usually commissioned because one of these has become expensive enough to act on.
Technology decisions cannot be defended
Choices were made under delivery pressure and never written down. When the board, an auditor or a prospective acquirer asks why, there is no record of the options considered or the constraints that decided it.
Modernisation stalls at the business case
Everyone agrees the platform needs to change. Nobody can sequence it into increments that deliver value without a freeze, so the programme is deferred another year and the cost of change rises.
Integration cost grows faster than the estate
Each new system is connected point to point. The number of interfaces grows with the square of the number of systems, and eventually most change budget is spent on connections rather than capability.
Cloud spend rises without matching capability
A lift-and-shift preserved the original architecture and added a bill. The elasticity that justified the move is unreachable because the application cannot scale horizontally.
Architecture exists only in people's heads
The design is understood by two engineers. Onboarding is slow, review is impossible, and key-person risk is concentrated in exactly the place the organisation can least afford it.
Business outcomes
What changes commercially once the underlying problems are addressed.
- Structural causes of delivery drag identified and separated from symptoms
- Technology decisions recorded with the options considered and the constraints that decided them
- Modernisation expressed as increments that each stand on their own business case
- Integration cost that grows with the estate rather than with the square of it
- Cloud architecture where the spend buys capability the business can actually use
- Architectural knowledge captured in reviewable artefacts rather than held in individual memory, so review and onboarding are possible
Our approach
The commitments that shape every engagement.
Evidence before opinion
We start from the running system, the delivery metrics and the constraints you actually operate under — not from a reference architecture. A recommendation that ignores your team size, budget or regulatory position is not a recommendation.
Decisions, recorded
Every significant choice is written down with its alternatives, its trade-offs and its expiry conditions — the circumstances under which it should be revisited. Architecture that cannot be re-examined becomes folklore.
Sequenced, not big-bang
Target states are decomposed into increments that can be delivered and measured independently. A roadmap whose first value delivery is eighteen months out will not survive its first budget review.
Built with your team, not around it
Your engineers implement the design and build the proofs of concept. This is deliberate: architecture handed over as a document nobody helped write is architecture that gets quietly abandoned.
Capabilities
What we are engaged to do.
Enterprise architecture strategy
Target-state architecture aligned to business capability rather than to the current org chart, with the transition states needed to get there.
Solution architecture
Architecture for a specific system or programme: component boundaries, data ownership, integration contracts and non-functional requirements made explicit enough to design against.
Architecture review and technology assessment
Independent assessment of an existing design or a proposed one, covering scalability, failure modes, cost trajectory, security posture and maintainability, with findings prioritised by risk and effort.
Modernisation roadmaps
Sequenced plans for moving off constrained platforms — strangler-fig decomposition, data migration ordering and rollback positions at each step.
Integration architecture
Moving an estate off point-to-point coupling: interface contracts, event-driven and request-response patterns applied where each is appropriate, and idempotency and failure semantics specified up front.
Cloud architecture
Target architecture for AWS, Azure or Google Cloud, including whether to re-architect or re-host per workload, landing-zone structure, and the cost model the design implies before it is built.
Architecture governance and standards
Lightweight governance that speeds delivery up rather than slowing it down: decision records, review checkpoints tied to real risk, and standards a team can follow without consulting a committee.
Technology advisory
Independent counsel on build-versus-buy, platform selection and vendor evaluation. We do not resell, and we hold no vendor commissions, so the recommendation is not a sales channel.
How an architecture review runs
A review starts from the running system rather than the documentation, because the two usually differ. We read the code, the deployment configuration and the delivery history, and interview the engineers who maintain it.
Findings are ranked by risk against remediation cost, so the output is actionable in parts rather than as a single programme. A review that produces sixty undifferentiated observations transfers the prioritisation problem back to you.
- Scalability limits identified against stated growth, not against a general standard
- Failure modes traced through the call path, including partial failure
- Cost trajectory modelled where the architecture drives it
- Findings ranked by risk against remediation effort
Integration architecture in practice
Integration is where most estates accumulate irreversible cost. Point-to-point connections grow with the square of the systems involved, and each one encodes an assumption about the other system that becomes expensive to unpick.
We specify contracts before implementation: schema, versioning policy, idempotency, error semantics and retry behaviour. These are the parts that cannot be changed once consumers depend on them, and they are usually the parts left implicit.
- Interface contracts specified before implementation begins
- Event-driven and request-response applied where each genuinely fits
- Idempotency and retry semantics defined per operation
- A stated position on which systems master which data
Modernisation sequencing
The question is rarely what the target should be. It is the order, and specifically which enabling work must complete before the visible work can start.
We decompose the target state into increments that each leave a working estate and each carry an independent business case. Data migration order is usually the binding constraint and is planned first, because it determines what can move and when.
Architecture governance that speeds delivery
Governance fails in two directions: too little and every team invents its own approach; too much and review becomes a queue teams route around, which produces worse outcomes than having none.
We design review that is triggered by risk rather than applied uniformly, decision records that capture reasoning rather than only outcomes, and an exception path quicker to follow than to circumvent.
- Review triggered by risk and irreversibility, not by change size
- Decision records with alternatives considered and expiry conditions
- An exception path faster to follow than to work around
- Standards expressed so a team can apply them without asking
Build, buy and the cost of reversal
Build-versus-buy is usually presented as a cost comparison. The more useful framing is strategic importance against switching cost: build where the capability differentiates the business and you will keep changing it; buy where it is necessary but undifferentiated.
The trap is the middle — a product bought for an undifferentiated need and then customised until it carries the maintenance burden of custom software with none of the control. We assess that explicitly, and we hold no vendor commissions, so the recommendation to buy less carries no cost to us.
- Strategic importance assessed separately from build cost
- Switching cost estimated before commitment, not discovered later
- Customisation depth treated as the signal it usually is
- Integration burden counted as part of the purchase
Non-functional requirements made testable
Availability, latency, throughput and recovery objectives are usually stated as adjectives. An architecture cannot be designed against 'highly available', and a system cannot be tested against it either.
We convert them into numbers agreed with the business — including what the business will accept when they are not met, because a recovery objective nobody has costed is an aspiration.
What you receive
Written artefacts, not a verbal readout. Everything below is designed to be circulated, challenged and revisited after we leave.
- Current-state assessment with the structural findings ranked by risk and remediation cost
- Target-state architecture, with component boundaries and data ownership made explicit
- Architecture decision records covering each significant choice, its alternatives and its expiry conditions
- Sequenced modernisation or implementation roadmap with independent increments
- Integration contracts and interface specifications
- Non-functional requirements stated in measurable terms
- Risk register covering architectural, delivery and operational risk with owners
- Architecture principles and standards your team can apply without us
Principles and standards
The standards we apply, and that we leave your team able to apply without us.
Fit before fashion
Widely used patterns are a starting point, not an answer. Microservices, event sourcing and CQRS each solve specific problems and each impose specific costs. We apply them where the problem is present.
Reversibility has value
Where two options are close, we prefer the one that is cheaper to undo. Most architectural regret comes from decisions that were expensive to reverse and were made with the least information.
Constraints are inputs, not obstacles
Team size, budget, regulatory position and existing skills shape what is buildable. A design that ignores them is an academic exercise.
Operability is a design concern
How a system is deployed, observed, debugged and recovered is decided at design time whether or not anyone decides it deliberately.
Governance and risk management
Governance that speeds delivery up rather than slowing it down, and the risk categories this engagement is accountable for.
- Architectural risk — coupling, single points of failure, and scaling limits identified before they are load-bearing
- Delivery risk — sequencing that avoids long freezes and keeps a working system at every step
- Operational risk — failure modes, recovery positions and observability specified as part of the design
- Cost risk — the spend a design implies modelled before it is committed, not discovered in the first invoice
- Key-person risk — decisions captured in artefacts so understanding is not concentrated in individuals
- Security and data-protection considerations built into the design rather than reviewed after it
Engagement models
Initial project design
Engaged before significant code exists, when structural decisions are still cheap to change. Produces the target-state architecture, the technology selection rationale, and a sequencing plan the delivery team can execute.
Mid-project assistance
Engaged when delivery has slowed, costs are rising, or a design that fitted the original problem no longer fits the current one. Diagnostic first: we establish what is actually causing the drag before recommending change.
Ongoing support
A named architect available as the system evolves, covering design review, technology decisions and course correction. Delivered under a subscription rather than a fixed project scope.
Delivery process
What actually happens, in order.
Free first consultation
An overview of your project, a review of the current system design, and an assessment of compatibility needs. The purpose is to establish whether there is useful work to do. If there is not, we say so.
Scoping
We agree what is in scope, which systems and stakeholders are involved, and what a good outcome looks like in terms you can measure.
Assessment
Review of the running system, its delivery history and its constraints. Interviews with the engineers who maintain it, because the documented architecture and the actual one usually differ.
Design and decision records
Target state, options, trade-offs and the recommendation, written so that someone who was not in the room can follow the reasoning.
Sequencing
The roadmap: increments, dependencies, rollback positions, and what each step delivers on its own.
Implementation support
Your team builds. We stay available for design review, proof-of-concept guidance and course correction as reality meets the plan.
Technology expertise
Platform-informed but not platform-bound. These are the technologies our engagements most often involve.
Cloud platforms
AWS, Microsoft Azure and Google Cloud — including hybrid and multi-cloud topologies where a single provider is not viable.
Containers & orchestration
Docker and Kubernetes, with the operational model that has to exist around them.
Application platforms
.NET, Java, Python and Node.js on the server; React and Flutter on the client.
Data & messaging
Relational and document stores, event streaming, and the integration patterns that connect them.
Infrastructure as code
Declarative provisioning and environment parity, so architecture decisions survive contact with deployment.
Industries served
Sector changes the constraints more than it changes the engineering.
Industry
Healthcare
Interoperability between clinical systems, patient data privacy, and legacy platforms that cannot be taken offline.
IndustryBanking & Financial Services
Core system modernisation, real-time payment flows, and architecture that can evidence regulatory controls.
IndustryInsurance
Claims and policy administration on ageing platforms, and data trapped in systems never designed to talk to each other.
IndustryRetail & E-commerce
Traffic that is seasonal rather than steady, omnichannel inventory accuracy, and catalogue scale.
IndustryManufacturing
Operational technology meeting information technology, supply chain visibility, and ERP estates grown by accretion.
IndustryLogistics
Real-time tracking, partner system integration, and routing systems where latency has a direct cost.
IndustryEducation
Student information systems, hybrid delivery platforms and sharply seasonal load.
IndustryGovernment & Public Sector
Procurement constraints, data residency, accessibility obligations and long-lived legacy estates.
IndustryTelecommunications
OSS/BSS complexity, network-scale data volumes and availability expectations measured in minutes per year.
IndustryEnergy & Utilities
Grid and asset telemetry, regulatory reporting, and operational systems that cannot tolerate an outage window.
Why NG&NR
Architect-level expertise, hourly
A full-time architect is a significant fixed cost, and the need is rarely continuous. We provide the expertise on an hourly basis, so you pay for the time you use.
Independent of vendors
We do not resell software or infrastructure and hold no vendor commissions. A platform recommendation from us is not a sales channel.
Named accountability
Every engagement has a named architect who owns the technical outcome and remains the point of contact for its duration.
Transparent commercials
One-time consultations or subscription-based ongoing support. Pricing is transparent and includes GST, with no hidden charges.
Frequently asked questions
Enterprise architecture works across systems: how the estate is structured, where capabilities live, and how the parts relate. Solution architecture works within one system or programme: its components, data ownership, integration contracts and non-functional requirements.
Most engagements need both. A solution designed without reference to the wider estate tends to create the next integration problem.
Three signals, any one of which is usually sufficient: delivery is slowing while headcount is not falling; a decision is approaching that would be expensive to reverse, such as a platform migration or a rewrite; or the system is about to carry materially more load, users or regulatory obligation than it was designed for.
Scalability limits, failure modes, cost trajectory, security posture, maintainability and delivery friction. Findings are prioritised by risk against remediation cost, so you can act on the top of the list without accepting the whole thing.
The output is written, so it can be circulated, challenged and revisited.
Pricing depends on the work and the seniority required. We offer one-time consultations and ongoing support through subscription plans. Pricing is transparent and includes GST, with no hidden charges.
For comparison, hiring a full-time architect is commonly around $3,500 per month as a fixed cost. The hourly model exists because most organisations need architecture expertise intensively and intermittently rather than continuously.
Usually your team implements and we support: design review, proof-of-concept guidance and course correction. This is deliberate. Architecture handed over as a document nobody helped write is architecture that gets quietly abandoned.
Clear communication, openness to guidance, and developer cooperation in implementing solutions and building proofs of concept. Access to the engineers who maintain the system matters more than access to documentation — the documented architecture and the real one usually differ.
We recommend what fits the constraints. We do not resell software or infrastructure and hold no vendor commissions, so a platform recommendation is independent counsel rather than a sales channel.
That is the normal case rather than the exception, and it is one reason we read the running system rather than working from documents. Establishing the actual current state is usually the first deliverable, and organisations are frequently surprised by it.
Yes, and it is a common engagement. The value is in identifying which decisions are still cheap to reverse and which are now load-bearing, so effort goes where it can still change the outcome rather than into decisions that are effectively fixed.
Both, but the diagram is not the deliverable. A diagram shows structure; it cannot record why a structure was chosen over the alternatives, which is the part that has value when the constraints change. Decision records carry the reasoning, and diagrams illustrate the result.
It depends on the size of the estate and the scope agreed. A focused architecture review of a single system is materially shorter than a modernisation roadmap across an estate. The free first consultation exists to establish which of those you actually need before anyone commits.
Next step
Schedule an architecture review
Start with a free consultation: an overview of your project, a review of the current design, and an assessment of what would actually help.
No cost, no obligation. Pricing is transparent and includes GST.