{"id":13,"date":"2025-08-12T18:06:57","date_gmt":"2025-08-12T18:06:57","guid":{"rendered":"https:\/\/ojlf26beda.26.sub-site.eu\/?page_id=13"},"modified":"2025-08-15T14:21:26","modified_gmt":"2025-08-15T14:21:26","slug":"inline-architecture","status":"publish","type":"page","link":"https:\/\/ojlf26beda.26.sub-site.eu\/index.php\/inline-architecture\/","title":{"rendered":"Inline Architecture"},"content":{"rendered":"\n

Goal<\/strong><\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

Bad Smells<\/strong><\/h3>\n\n\n\n

The Inline Architecture refactoring addresses structural and behavioural anti-patterns such as:<\/p>\n\n\n\n

    \n
  • \u201cArchitecture happens before development and is handed off to us.\u201d<\/li>\n\n\n\n
  • \u201cThe Project Start Architecture dictates how we must build everything.\u201d<\/li>\n\n\n\n
  • \u201cOur architects are not available during implementation.\u201d<\/li>\n\n\n\n
  • \u201cWe don\u2019t understand the rationale behind some of our architectural constraints.\u201d<\/li>\n\n\n\n
  • \u201cChanging architecture later is slow and bureaucratic.\u201d<\/li>\n<\/ul>\n\n\n\n

    Overview <\/strong><\/h3>\n\n\n\n

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

    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.<\/p>\n\n\n\n

    \n\n\n\n

    \ud83e\udded Assess the situation<\/strong><\/h2>\n\n\n\n

    Architectural Influence on Development<\/strong><\/h3>\n\n\n\n

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

    Timing of Architectural Decisions<\/strong><\/h3>\n\n\n\n

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

    Architect Proximity and Engagement<\/strong><\/h3>\n\n\n\n

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

    Collaboration Opportunities<\/strong><\/h3>\n\n\n\n

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

    Demand for Architectural Input<\/strong><\/h3>\n\n\n\n

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

    Governance Purpose and Style<\/strong><\/h3>\n\n\n\n

    Check:<\/strong> Is architectural governance framed as enabling or as control?
    Why:<\/strong> Command-and-control governance stifles innovation and delays decisions.
    Precondition:<\/strong> There\u2019s a willingness to redefine governance as facilitative and outcome-oriented.<\/p>\n\n\n\n

    Fixed vs. Emergent Architectural Elements<\/strong><\/h3>\n\n\n\n

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

    Critical Interfaces for Review<\/strong><\/h3>\n\n\n\n

    Check:<\/strong> Are there known architectural interfaces or components that require formal review or consultation?
    Why:<\/strong> Some areas\u2014such as security, shared platforms, or compliance\u2014still need structured involvement.
    Precondition:<\/strong> These critical points are identified and integrated into the team\u2019s flow without bottlenecking it.<\/p>\n\n\n\n

    \n\n\n\n

    \u25b6\ufe0f Execute the Inline Architecture OrgRefactoring<\/strong><\/h2>\n\n\n\n

    Communicate the Change Story<\/strong><\/h3>\n\n\n\n

    Check:<\/strong> 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:<\/strong> A move without purpose or story creates resistance and anxiety.
    Activity<\/strong>: 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.<\/p>\n\n\n\n

    Define Exit Strategy with the Team<\/strong><\/h3>\n\n\n\n

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

    Clarify Architectural Intent at All Levels<\/strong><\/h3>\n\n\n\n

    Check: <\/strong>Are new architecture roles, artefacts and practices known to the teams and architects?
    Why: <\/strong>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.<\/em>
    Activity: <\/strong>Define the role, goal of all relevant architectural practices, artefacts and roles according to the definition. Think of roles, practices and artifacts like: <\/p>\n\n\n\n

      \n
    • Enterprise Architecture (EA)<\/strong><\/li>\n\n\n\n
    • Domain Architecture<\/strong><\/li>\n\n\n\n
    • Project Start Architecture (PSA)<\/strong><\/li>\n\n\n\n
    • Architecture Board<\/strong><\/li>\n<\/ul>\n\n\n\n

      Embed Architecture in the team of teams<\/strong><\/h3>\n\n\n\n

      Check:<\/strong> Do the architects collaborate with the teams and do they participate in the team events and rituals?
      Why: <\/strong>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: <\/strong>Train architects in the teams’ way of working, coach them on taking a different stance. <\/p>\n\n\n\n

      Form the Architecture “Chapter” <\/strong><\/h3>\n\n\n\n

      Check:<\/strong> 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: <\/strong>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. <\/p>\n\n\n\n

      \n\n\n\n

      \ud83d\udd19<\/strong> Conditionally: Rollback Moving the Architects<\/strong><\/h2>\n\n\n\n

      Trigger rollback if:<\/p>\n\n\n\n

        \n
      • Delivery is negatively impacted beyond the threshold<\/li>\n\n\n\n
      • Team or Architect satisfaction or collaboration deteriorates<\/li>\n\n\n\n
      • Expected benefits are not materialising<\/li>\n<\/ul>\n\n\n\n

        Rollback should restore the previous domain setup or pivot into a new improvement track.<\/p>\n","protected":false},"excerpt":{"rendered":"

        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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"page-wide","meta":{"footnotes":""},"class_list":["post-13","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/ojlf26beda.26.sub-site.eu\/index.php\/wp-json\/wp\/v2\/pages\/13","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ojlf26beda.26.sub-site.eu\/index.php\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/ojlf26beda.26.sub-site.eu\/index.php\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/ojlf26beda.26.sub-site.eu\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/ojlf26beda.26.sub-site.eu\/index.php\/wp-json\/wp\/v2\/comments?post=13"}],"version-history":[{"count":12,"href":"https:\/\/ojlf26beda.26.sub-site.eu\/index.php\/wp-json\/wp\/v2\/pages\/13\/revisions"}],"predecessor-version":[{"id":160,"href":"https:\/\/ojlf26beda.26.sub-site.eu\/index.php\/wp-json\/wp\/v2\/pages\/13\/revisions\/160"}],"wp:attachment":[{"href":"https:\/\/ojlf26beda.26.sub-site.eu\/index.php\/wp-json\/wp\/v2\/media?parent=13"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}