Delivery Integration

The Parallel Problem

Here's how architecture typically works in most organisations: delivery teams do their thing, architecture does its thing, and occasionally they meet in a review forum where architecture provides feedback on work that's already mostly done.

The architecture review happens. Comments are made. Some changes are requested. The team pushes back — they've already built most of it, the deadline is next week, changing now is expensive. A compromise is reached where everyone agrees to "address it in the next phase" (which never happens). The review is marked complete. Everyone moves on.

This is architecture running parallel to delivery. And it doesn't work.

When architecture operates on its own cadence, separate from sprint planning or project milestones, it becomes a side activity. Delivery teams treat it as optional — a hurdle to clear rather than a resource to leverage. Architecture input arrives too late to influence decisions meaningfully. The relationship becomes adversarial: architecture as police, delivery as rule-avoiders.

The result is predictable: architecture gets bypassed, delivery makes decisions without architectural context, technical debt accumulates, integration issues surface late, and everyone wonders why the architecture function isn't adding value.

Connected Architecture takes a different approach. Architecture doesn't run parallel to delivery — it embeds within delivery. Architecture activities happen at natural decision points, not in separate forums. Architects are part of delivery, not observers of it.

Architecture at Decision Points

The concept is simple: architecture matters when decisions are being made. Not before decisions (too abstract). Not after decisions (too late). At the moment decisions are happening.

Every delivery effort — whether it's a two-week sprint or a two-year programme — has natural decision points where architectural input is valuable:

The specific activities vary by methodology, but the principle is constant: architecture plugs in where decisions happen.

Integration by Methodology

Different delivery methodologies have different rhythms. Architecture integration needs to match those rhythms rather than imposing a separate cadence.

Agile / Scrum

Agile's iterative nature creates frequent, small decision points. Architecture integrates through the existing ceremonies:

Backlog Refinement - Identify stories with architecture implications - Flag items that touch guardrails or might introduce debt - Ensure architectural context is available for estimation - Surface items that need higher-tier oversight

This is where architecture involvement pays off most. Catching architectural implications during refinement — before work enters a sprint — prevents surprises and rework.

Sprint Planning - Confirm approach aligns with guardrails - Identify any deviations being proposed - Agree on decision records needed - Ensure passport updates are scoped if relevant

If a story involves architectural decisions, the sprint plan should account for the work of making and documenting those decisions — not just the implementation.

Daily Standup - Architect attends or is available for questions - Early flag of architectural issues or blockers - Quick clarification of guardrail interpretation

Architects don't need to attend every standup for every team. But for high-tier work or when architectural decisions are in flight, presence matters. Quick questions answered in standup prevent days of delay waiting for a review forum.

Sprint Review - Demo includes architectural decisions made, not just features delivered - Stakeholders see the "how" not just the "what" - Technical debt introduced is acknowledged

This keeps architecture visible to stakeholders. They see that architectural thinking is part of delivery, not a separate concern.

Retrospective - Guardrail feedback: what's working, what's blocking? - Architecture process feedback: is integration helping or hindering? - Identify improvements for next sprint

Guardrails that consistently create friction might need revisiting. The retrospective is where that feedback surfaces.

Architecture-Specific Additions

Some teams add architecture-focused practices alongside standard Scrum:

• Architecture spikes: Time-boxed exploration of architectural options before committing to an approach
• Debt review: Periodic review of accumulated debt, typically monthly, to prioritise remediation
• Guardrail check-in: Quick confirmation that recent work aligns with guardrails, often combined with sprint review

Waterfall / Stage-Gate

Traditional waterfall has fewer, larger decision points. Architecture integrates at stage gates:

Business Case / Initiation - High-level architecture assessment - Tier classification for oversight - Initial guardrail review - Architecture effort and dependencies estimated

Architecture involvement at this stage shapes scope and budget. If the business case doesn't account for architectural work, the project will struggle later.

Requirements - Architecture requirements captured alongside functional requirements - Non-functional requirements (performance, security, scalability) defined - Integration requirements identified - Guardrails translated to specific requirements

Architecture requirements aren't separate from "the requirements" — they're part of them. Security, performance, integration patterns — these are requirements like any other.

Design - Solution architecture defined - Alignment with guardrails confirmed - Deviations identified and approved - Decision records created - Technical approach documented

This is the heavyweight architecture stage in waterfall. The solution architecture document becomes a key deliverable, reviewed and approved before build begins.

Build - Decisions tracked as implementation reveals reality - Emerging debt logged - Passport maintained - Architecture available for clarification and guidance

Even in waterfall, implementation reveals things that design didn't anticipate. Architecture stays engaged during build to address questions and track decisions made during implementation.

Test - Architecture compliance verified - Non-functional requirements validated - Integration testing includes architectural concerns - Security testing against architectural controls

Testing isn't just "does it work?" but "does it work the way we designed it?" Architecture verification ensures the build matches the design.

Deploy / Transition - Passport handover completed - Debt formally transferred to operations - Decision records archived with the system - Operational architecture documentation confirmed

Handover is a gate. The project doesn't close until the architecture passport is updated and accepted by whoever's receiving the system.

SAFe / Scaled Agile

SAFe introduces additional layers where architecture integrates:

Portfolio Level - Strategic guardrails inform portfolio prioritisation - Architecture runway items in portfolio backlog - Enterprise architecture alignment across value streams

Large Solution / Solution Train - Cross-team architectural coordination - Integration architecture across ARTs - Solution-level guardrails and decision making

Program / ART Level - Architecture runway maintained - Enabler features for architectural work - System architect role embedded in ART

Team Level - Same as Scrum integration above - Plus coordination with ART-level architecture

The key SAFe concept is the Architectural Runway — ensuring sufficient technical foundation exists to support planned features. Connected Architecture's guardrails and passports support runway planning by making architectural state visible.

Kanban / Flow-Based

Kanban's continuous flow model doesn't have sprint boundaries. Architecture integrates through:

Work Item Classification - Architectural implications flagged when items enter the board - Tier classification drives review requirements - Guardrail applicability noted

WIP Limits - Architecture review capacity factored into WIP limits - High-tier items may have dedicated architecture lane - Prevents architecture becoming a bottleneck

Definition of Done - Architecture criteria in DoD (see below) - Items don't move to done without architecture completion

Continuous Review - Ongoing architecture availability rather than scheduled reviews - Pull-based engagement: teams pull architecture in when needed - Async review for lower-tier items

The Solution Architect in Delivery

In most delivery contexts, the Solution Architect is the primary architecture touchpoint. They're embedded in delivery, making architectural decisions in real-time as the work progresses.

The Role

The Solution Architect:

• Translates enterprise guardrails into solution-level decisions
• Makes trade-offs within the boundaries that guardrails define
• Ensures what gets built aligns with broader architectural direction
• Documents decisions and debt as they occur
• Maintains the architecture passport for systems being touched
• Escalates when decisions exceed their authority or when genuinely stuck

Authority and Autonomy

A key principle: decide fast, at the lowest level possible.

Solution Architects have real authority. They're not just documenters or facilitators — they make decisions. The guardrails define the boundaries; within those boundaries, they act.

This is what makes architecture not a bottleneck. Most decisions fall within guardrails or are low-risk deviations. The Solution Architect handles them without waiting for anyone. Only genuinely significant or high-risk decisions escalate.

Embedded vs. Shared

Solution Architects can be:

Embedded: Dedicated to one team or product. Deep context, high availability, strong relationships. Works best for complex, high-change systems.

Shared: Serving multiple teams. Broader perspective, can spot patterns across teams, but less deep context in each. Works for smaller teams or lower-complexity work.

Hybrid: Primarily embedded but with some shared capacity. The embedded architect handles most work; shared architects provide coverage and cross-team perspective.

The model depends on your context. What matters is that architecture capacity is available when decisions are being made — not scheduled two weeks out when the decision moment has passed.

Definition of Done

The Definition of Done is where architecture becomes non-negotiable. If architecture criteria are in the DoD, work isn't done until they're addressed.

Architecture Additions to DoD

Add these to your existing Definition of Done:

For all work:

• Guardrail alignment confirmed (or deviation logged)
• Decision records complete for significant decisions
• Technical debt declared for any shortcuts taken

For work touching systems:

• Architecture passport updated
• Integration points documented
• Debt register updated

For releases/deployments:

• Passport reflects current state
• Handover documentation complete (if applicable)
• Debt ownership confirmed

Making It Stick

Adding to the DoD only works if:

• Teams understand why. Explain the purpose — not bureaucracy, but persistence and traceability.
• The criteria are achievable. If decision records take hours, they won't get done. Keep them lightweight.
• It's consistently enforced. Work that doesn't meet DoD isn't done. No exceptions.
• There's support available. If teams struggle with architecture criteria, help them — don't just reject their work.

The DoD is the enforcement mechanism for the Persist principle. If decisions, debt, and passport updates are in the DoD, they happen. If they're optional extras, they don't.

When Architecture Gets Involved

Not everything needs architecture involvement. Over-involving architecture is as problematic as under-involving — it creates unnecessary overhead and trains teams to expect hand-holding.

Involvement Triggers

High involvement (active architecture participation):

• New system or major new component
• New technology not currently in the landscape
• New integration pattern or external party integration
• Work in Tier 1 (high-risk) systems
• Significant guardrail deviations being considered
• Major architectural decisions with long-term implications

Medium involvement (lightweight checkpoint, available for questions):

• Extensions to existing systems using established patterns
• Work in Tier 2 (medium-risk) systems
• Minor deviations or edge cases
• First time a team uses a pattern they haven't used before

Low involvement (self-service, async review if any):

• Standard work within established patterns
• Work in Tier 3 (low-risk) systems
• Changes within previously-approved architectural boundaries
• Routine maintenance and minor enhancements

Letting Go

Architecture needs to let go of work that doesn't need involvement. This is hard for architects who want to be helpful (or who want control), but essential for scaling.

Signs you're over-involved:

• Teams waiting for architecture input on routine decisions
• Architecture reviews finding nothing significant to discuss
• Teams asking permission for things clearly within guardrails
• Architecture becoming a bottleneck despite having capacity

The goal is architecture involvement that's proportional to risk and novelty. Routine work flows without architecture touch. Novel or risky work gets attention. Teams learn where the boundaries are and self-serve within them.

Avoiding Architecture as Bottleneck

The biggest failure mode for architecture integration is becoming a bottleneck. Teams can't move until architecture reviews. Architecture can't keep up with demand. Work queues. Frustration builds. Teams start working around architecture entirely.

Bottleneck Causes

Approval-centric model: Everything needs architecture sign-off. No decision authority at the team level.

Limited capacity: More review demand than architecture can handle. No scalable model.

Slow feedback: Architecture reviews scheduled days or weeks out. Decisions delayed waiting for a slot.

Unclear scope: Teams don't know what needs review, so they submit everything (or nothing).

Heavy process: Reviews require extensive documentation, preparation, formal presentations.

Bottleneck Solutions

Guardrails over approvals: Most decisions shouldn't need approval. Guardrails define the boundaries; teams operate within them autonomously.

Tiered oversight: High-risk work gets scrutiny. Low-risk work is self-service. Match effort to risk.

Embedded architects: Architecture embedded in delivery can respond immediately. No waiting for a review meeting.

Async review: Not everything needs a meeting. Review materials asynchronously, comment, approve — without scheduling overhead.

Clear scope definition: Teams know exactly what needs architecture involvement and what doesn't. No ambiguity.

Lightweight process: Review should take minutes, not hours. Decision records take 15 minutes, not half a day.

The test: Can a team make a routine architectural decision today without waiting? If yes, you're not a bottleneck. If no, redesign your process.

Architecture Ceremonies

Some organisations formalise architecture integration through specific ceremonies. These can work well but can also become bureaucratic overhead. Use judgement.

Architecture Review Board (ARB)

Purpose: Forum for high-tier decisions, deviation approvals, guardrail changes.

When it works: Clear scope limited to genuinely significant decisions. Efficient meetings with prepared materials. Authority to make decisions, not just discuss.

When it fails: Everything routes through ARB. Meetings become rubber-stamp exercises or prolonged debates. Decisions delayed waiting for the next meeting.

Recommendation: Use for genuinely high-tier decisions only. Most decisions shouldn't need ARB. If your ARB is meeting weekly with a full agenda, you're probably reviewing too much centrally.

Architecture Working Group / Community of Practice

Purpose: Peer discussion, pattern sharing, guardrail development, cross-team coordination.

When it works: Collaborative forum focused on improving architecture practice. Inclusive of solution architects across teams. Generates useful patterns and guidance.

When it fails: Becomes a talking shop with no outcomes. Attendance drops. Decisions made elsewhere.

Recommendation: Focus on enablement, not governance. This is where architects help each other get better, share what's working, develop patterns. Keep it separate from approval/governance forums.

Architecture Office Hours

Purpose: Drop-in availability for teams to get quick guidance.

When it works: Easy access to architecture support without formal process. Quick answers to quick questions. Relationship-building.

When it fails: Nobody shows up. Or the same people dominate. Or it becomes a de facto review forum without the structure.

Recommendation: Works well as a supplement, not a substitute. Teams should have architecture relationships; office hours shouldn't be their primary touchpoint.

Measuring Integration Success

How do you know if architecture integration is working?

Leading Indicators

Architecture engagement is voluntary and early. Teams involve architecture because it's helpful, not because they have to. They come early (design) not late (review).

Questions flow freely. Teams ask architecture questions without feeling like they're triggering a review process. Architects are approachable.

Decisions are made quickly. Architectural decisions don't wait days or weeks. Teams have the authority to move.

Feedback goes both ways. Teams provide feedback on guardrails. Guardrails evolve based on delivery reality.

Lagging Indicators

Fewer late-discovered architecture issues. Problems surface during design, not during integration testing or production.

Reduced rework. Less throwing away work because it doesn't fit the architecture.

Coherent solutions. Systems built by different teams fit together. Integration isn't heroic effort every time.

Managed debt. Debt is tracked and visible, not discovered during incidents or audits.

Anti-Indicators

Watch for signs that integration is failing:

• Teams avoiding architecture until they have to engage
• Architecture reviews consistently finding significant issues (meaning design-time engagement isn't happening)
• Workarounds and exceptions becoming the norm
• Decision records and passports perpetually out of date
• Architecture capacity backlogged while teams wait

These indicate that architecture is running parallel to delivery, not embedded within it.

Common Pitfalls

Architecture review as gate, not guidance

If architecture is primarily experienced as a gate to pass through, you've created an adversarial relationship. Teams will optimise for passing the gate, not for getting good outcomes.

Fix: Position architecture as a resource. Architects help teams succeed, not catch them failing.

Too much process for low-risk work

If standard, within-guardrail work requires significant architecture process, you're creating overhead without benefit.

Fix: Right-size process to risk. Low-risk work should have minimal architecture touch.

Architects as separate team, not embedded partners

If architects sit in an architecture team that delivery teams interact with through formal channels, integration is already compromised.

Fix: Embed architects in delivery. Even if they report to an architecture function, they should work day-to-day with delivery teams.

Decision authority unclear

If teams don't know whether they can make a decision or need to escalate, they'll either escalate everything (bottleneck) or decide everything themselves (chaos).

Fix: Explicit decision authority at each level. Clear criteria for escalation. No ambiguity.

Handover as afterthought

If architecture handover happens as an afterthought at project end — or doesn't happen at all — knowledge doesn't persist.

Fix: Handover in the Definition of Done. Not optional. Not deferred.

Getting Started

If architecture currently runs parallel to delivery:

Week 1-2: Map the current state

• Where are decisions being made without architecture input?
• Where is architecture creating bottlenecks?
• What ceremonies exist that architecture could integrate with?

Week 3-4: Define integration points

• Which decision points need architecture involvement?
• What tier of work do you have?
• Where can you reduce architecture overhead?

Month 2: Pilot integration

• Pick one team or one methodology as pilot
• Embed architecture in their process
• Add architecture criteria to their DoD
• Learn what works

Month 3+: Expand and refine

• Roll out to additional teams
• Adjust based on feedback
• Build architecture capacity for embedded model
• Evolve guardrails based on delivery experience

The goal is architecture that delivery teams want to engage with — not because they have to, but because it makes their work better. Start small, prove value, expand.

The Delivery Integration Promise

Here's what Connected Architecture promises about delivery integration:

• We will be where you need us. Architecture input at decision points, not weeks later in a review forum.
• We will not slow you down. Guardrails, not gates. Clear authority. Lightweight process.
• We will help you succeed. Architecture as a resource, not as police. We want you to ship good systems.
• We will learn from you. Guardrails evolve based on delivery reality. Your feedback matters.
• We will hold the line on what matters. Some things aren't negotiable. We'll be clear about what and why.

Architecture embedded in delivery isn't about adding architecture overhead to an already busy process. It's about making architecture useful where and when it matters — so that what gets delivered is coherent, sustainable, and aligned with where the organisation needs to go.

Architecture that ships. That's the goal.

XAF Connected Architecture | Developed by InnovateX Solutions