Organization Refactoring – Inline Architecture

Goal

The goal of the Inline Architecture refactoring is to shift architecture from a phase-gate, upfront-design model to a collaborative, iterative practice embedded within development of a team of teams (for instance ART or TRIBE). This enables faster feedback loops, more adaptive design decisions, and stronger alignment between enterprise direction and team implementation.

Bad Smells

The Inline Architecture refactoring addresses structural and behavioural anti-patterns such as:

“Architecture happens before development and is handed off to us.”
“The Project Start Architecture dictates how we must build everything.”
“Our architects are not available during implementation.”
“We don’t understand the rationale behind some of our architectural constraints.”
“Changing architecture later is slow and bureaucratic.”

Overview

To prepare for inline architecture for this team of teams (e.g. ART, Tribe, or Value Stream), start by assessing the situation.

Based on this assessment, decide with management whether to proceed with this refactoring or explore other solutions. Co-create a compelling change story that explains the purpose, direction, and benefits of the move. Create a backlog of transition activities, estimate the work, and assess risks. Define continuity checks and effect measures. Document a rollback plan in case outcomes are not achieved. Kick off with the teams and stakeholders, iterate toward the new setup, and review effects. Dare to pivot or rollback if needed and explore alternative options to improve alignment and value contribution.

🧭 Assess the situation

Architectural Influence on Development

Check: Where and how does architecture currently influence development practices?
Why: Understanding architectural touchpoints is crucial to determine if architecture enables or constrains team agility.
Precondition: There is clarity on current architecture inputs, decision timing, and influence points.

Timing of Architectural Decisions

Check: Which architectural decisions are made upfront versus during implementation?
Why: A highly front-loaded process may indicate a rigid phase-gate model, reducing responsiveness to learning.
Precondition: Some architectural decisions are allowed to emerge during development based on team insights.

Architect Proximity and Engagement

Check: Are architects embedded in team ceremonies or working from a distance?
Why: Distance from teams leads to misalignment and reduces trust in architectural decisions.
Precondition: Architects are available and willing to participate in Agile team activities.

Collaboration Opportunities

Check: Are there touchpoints where architects and teams regularly collaborate (e.g., PI Planning, reviews, spikes)?
Why: These touchpoints enable continuous alignment and real-time architectural support.
Precondition: A basic rhythm of collaboration exists or can be introduced without disrupting delivery.

Demand for Architectural Input

Check: Where do teams currently need more architectural support—and where is it not needed?
Why: Misalignment between support and need leads to either gaps or unnecessary overhead.
Precondition: Teams can articulate their architectural needs and feel safe doing so.

Governance Purpose and Style

Check: Is architectural governance framed as enabling or as control?
Why: Command-and-control governance stifles innovation and delays decisions.
Precondition: There’s a willingness to redefine governance as facilitative and outcome-oriented.

Fixed vs. Emergent Architectural Elements

Check: Which parts of architecture are treated as fixed, and which can emerge through delivery?
Why: Not distinguishing between stable and flexible aspects increases rigidity or risk.
Precondition: A shared understanding exists (or can be developed) of which architectural elements are negotiable.

Critical Interfaces for Review

Check: Are there known architectural interfaces or components that require formal review or consultation?
Why: Some areas—such as security, shared platforms, or compliance—still need structured involvement.
Precondition: These critical points are identified and integrated into the team’s flow without bottlenecking it.

▶️ Execute the Inline Architecture OrgRefactoring

Communicate the Change Story

Check: Does the team understand why this move is happening and what success looks like? Architecture as enabler, not gatekeeper with benefits of faster learning, better designs, stronger team ownership.
Why: A move without purpose or story creates resistance and anxiety.
Activity: A compelling and relevant change story is co-created with the team and target domain. A first backlog of activities needed for success is created.

Define Exit Strategy with the Team

Check: What are the indicators that the move is working? What if it doesn’t?
Why: You need the ability to course-correct if the move leads to new frictions.
Activity: Indicators for failure are defined and a rollback or mitigation plan is prepared in case of failure.

Clarify Architectural Intent at All Levels

Check: Are new architecture roles, artefacts and practices known to the teams and architects?
Why: Modern architecture should support Agile development practices through collaboration, design simplicity, and balancing intentional and emergent design. It should enable design for testability, deployability, and releaseability, it should supported rapid prototyping, domain modeling, and decentralized innovation.
Activity: Define the role, goal of all relevant architectural practices, artefacts and roles according to the definition. Think of roles, practices and artifacts like:

Enterprise Architecture (EA)
Domain Architecture
Project Start Architecture (PSA)
Architecture Board

Embed Architecture in the team of teams

Check: Do the architects collaborate with the teams and do they participate in the team events and rituals?
Why: In order to balance intentional architecture and emergent design close collaboration with the architects with the teams is essential. Working close with the teams overcomes the need for big designs up-front and architecture boards and improves flow of work.
Activity: Train architects in the teams’ way of working, coach them on taking a different stance.

Form the Architecture “Chapter”

Check: Do the architects collaborate amongst themselves to help eachother grow as an architect and help eachother on challenges that arise working with the teams.
Why: Now architects are places closer to the team, they may loose connections with their own practice. Forming a “chapter” which is a group within the team of teams that has interest in architecture helps to grow the architecture practice.

🔙 Conditionally: Rollback Moving the Architects

Trigger rollback if:

Delivery is negatively impacted beyond the threshold
Team or Architect satisfaction or collaboration deteriorates
Expected benefits are not materialising

Rollback should restore the previous domain setup or pivot into a new improvement track.