How to Move From Architecture to Production Without Losing Control

A practical delivery workflow for turning approved designs into reliable production outcomes.

A good architecture doesn't create any value until it actually reaches production. That sounds obvious enough, but it's exactly where a lot of technology programmes quietly grind to a halt.

The design gets approved. The roadmap exists. The target architecture is clear on paper. Then execution actually starts, and suddenly the programme turns into a tangle of Jira tickets, dependencies, security reviews, infrastructure changes, release coordination, and a fair amount of operational uncertainty.

The problem is rarely that engineers don't know how to build things. It's usually that delivery was never structured around a repeatable execution model in the first place.

At m-tech1, Build & Deliver is the stage where plans finally become working systems. The goal is simple to state, if not always simple to pull off: deliver changes quickly without sacrificing engineering quality, reliability, or operational control. Here's roughly how we approach it.

Step 1: Turn architecture into delivery-ready work

Handing engineering a 40-page architecture document and calling it a backlog doesn't really work. Architecture needs to be broken down into work that can actually be implemented.

For each capability, we define:

                Architecture decision
        ↓
Engineering standard
        ↓
Implementation task
        ↓
Acceptance criteria
        ↓
Production validation
              

For example, the architecture decision might be that production services must use centralised observability. The engineering standard becomes metrics through Prometheus, traces through OpenTelemetry, and logs through the central logging platform. The implementation task is adding the standard observability module to the application template. The acceptance criteria is that metrics, logs, and traces appear automatically after deployment. And production validation means the dashboard and alerting get tested against a controlled failure.

That structure removes a lot of ambiguity before developers ever start building. Useful tools here include Jira for delivery work, Confluence for architecture and standards, GitHub or GitLab for implementation, and ADRs for the important technical decisions.

Step 2: Build the smallest production-valid slice

Large programmes often try to build the entire target state before even proving the delivery model works. I'd do the opposite.

Pick one representative workload and take it through the whole process:

                Application
    ↓
Git repository
    ↓
Terraform
    ↓
AWS infrastructure
    ↓
CI/CD
    ↓
Kubernetes
    ↓
Observability
    ↓
Production
              

This isn't meant to be a demo. It needs to be a genuinely production-valid slice, which means it has to include the parts that usually get postponed until later: security, identity, networking, logging, monitoring, backup, rollback, and ownership.

Why does that matter so much? Because the hard problems almost always show up between the components, not inside any single one of them. A successful pilot tells you whether the whole operating model actually holds together.

Step 3: Automate the delivery path

Once that first workload works end to end, the process needs to become something repeatable.

A mature delivery workflow might look like:

                Developer commits change
        ↓
Pull Request
        ↓
Build
        ↓
Unit / integration tests
        ↓
Security checks
        ↓
Infrastructure validation
        ↓
Policy validation
        ↓
Deployment
        ↓
Health checks
        ↓
Production monitoring
              

The tooling could include GitHub Actions, GitLab CI, or Azure DevOps for the pipelines, Terraform for infrastructure as code, Argo CD for GitOps-based Kubernetes delivery, Trivy, Checkov, or tfsec for security validation, OPA or Gatekeeper for policy enforcement, and Prometheus, Grafana, or OpenTelemetry for observability.

The exact stack will vary from team to team. What actually matters is that every deployment passes through the same known set of controls, every single time.

Step 4: Shift quality into the workflow

Security, reliability, and governance shouldn't show up at the very end of delivery as some final gate. They need to be baked into the process itself.

                Code
 ↓
Tests
 ↓
Security scan
 ↓
Infrastructure validation
 ↓
Policy check
 ↓
Cost check
 ↓
Deploy
              

This actually changes the relationship between engineering and the control functions. Instead of asking "can security approve this release?", the question becomes "did this change satisfy the policies required for production?" That's a far more scalable way to work.

Some examples of the checks worth automating:

• no public storage buckets
• no critical vulnerabilities
• encryption enabled
• approved regions only
• required tags applied
• resource limits defined
• rollback available
• observability enabled

The platform enforces the standard automatically. Senior engineers get to spend their time on exceptions and architecture, not repetitive manual review.

Step 5: Design rollback before deployment

A deployment workflow that only describes how to move forward is incomplete. Before anything ships, recovery needs to be defined too.

For an application:

                New release
    ↓
Health checks
    ↓
Error rate / latency monitored
    ↓
SLO violated?
   ↙       ↘
 NO       YES
 ↓         ↓
Keep     Rollback
              

For infrastructure:

                Terraform plan
    ↓
Review
    ↓
Apply
    ↓
Monitor
    ↓
Unexpected impact
    ↓
Revert / restore
              

Useful mechanisms here include blue/green deployments, canary releases, feature flags, Argo Rollouts, the previous Terraform state, database backups, and properly tested restore procedures. Rollback shouldn't be treated as some emergency afterthought. It's just part of the delivery design from the start.

Step 6: Make ownership visible in production

The moment something breaks, ownership matters a lot more than any architecture diagram ever will. Every service needs clear answers to a few basic questions: who owns the application, who owns the platform, who responds to incidents, who approves high-risk changes, who owns the SLO, and who handles infrastructure exceptions.

A simple service definition table helps a lot here:

That single table prevents production issues from turning into a coordination exercise every time something goes wrong.

Step 7: Measure delivery, not activity

The number of tickets closed doesn't really tell you much on its own. What matters more are the metrics closer to actual delivery performance: deployment frequency, lead time for changes, change failure rate, MTTR, environment provisioning time, manual interventions, platform tickets, failed deployments, and rollback frequency.

For example:

These numbers are illustrative, obviously, but the point stands: what matters is proving delivery is actually getting faster and safer at the same time.

Step 8: Scale only what works

Once that production-valid slice is working, it's time to turn it into a reusable capability. That could mean Terraform modules, CI/CD templates, service templates, reusable security policies, standard observability, golden paths, or runbooks.

Then the next team gets onboarded, and the one after that.

The rule worth holding onto here is simple: don't scale a delivery workflow that still needs senior engineers to intervene every single time. Remove the friction first. Only scale the pattern once it actually stands on its own.

What Build & Deliver should produce

By the end of this phase, we want production-ready capabilities, automated delivery workflows, security and policy built directly into the process, reliable rollback, clear operational ownership, and measured delivery improvement to show for it.

That's really the difference between implementing a piece of technology and building an actual operating capability.

The final test

There's one question worth asking at the end of all this: can the next engineering team use what we built without needing the original engineers standing right next to them?

If the answer is no, we delivered a project. If the answer is yes, we delivered a capability. At m-tech1, Build & Deliver is built around getting to that second outcome.