Enterprise Architecture Reflex Area
2026-09-29
Table of Contents
- Defining the Purpose, Scope, and Mandate of Enterprise Architecture
- Designing the Enterprise Architecture Operating Model
- Choosing Between Centralized, Federated, Distributed, Embedded, and Hybrid Architecture Models
- Locating Architects Across Central Functions, Domains, Portfolios, Platforms, and Delivery Teams
- Designing How Central and Embedded Architects Work Together
- Defining the Services the Enterprise Architecture Function Provides
- Matching the Architecture Operating Model to Organizational Scale, Structure, and Maturity
- Coordinating Architecture Across Business Units, Regions, and Semi-Autonomous Organizations
- Scaling Enterprise Architecture Without Creating a Central Bottleneck
- Integrating Enterprise Architecture with Existing Governance and Management Processes
- Changing the Architecture Operating Model as Delivery and Technology Models Evolve
- Diagnosing an Enterprise Architecture Operating Model That Is No Longer Working
- Establishing Architecture Roles, Decision Rights, and Governance
- Framing Architecture Problems, Stakeholders, and Requirements
- Connecting Strategy and Enterprise Architecture
- Using Business Capabilities, Value Streams, and Services to Shape Architecture
- Connecting Business Capabilities to Information, Applications, Technology, and Change
- Reconstructing the Current Enterprise Architecture
- Managing Architecture Evidence, Provenance, and Uncertainty
- Analyzing Cross-Enterprise Dependencies and Change Impact
- Representing and Communicating Architecture for Decisions
- Establishing Architecture Principles, Standards, and Guardrails
- Developing Reference Architectures and Reusable Patterns
- Developing Architecture Vision and Target Architectures
- Evaluating Architecture Options and Tradeoffs
- Designing Transition Architectures and Architecture Roadmaps
- Managing Enterprise Information and Data Architecture
- Defining Enterprise Information Domains and Major Business Concepts
- Establishing Authoritative Ownership for Information Shared Across Domains
- Resolving Conflicting Definitions of a Shared Business Concept
- Deciding Which Semantics, Identifiers, and Classifications Need Enterprise Consistency
- Choosing Whether Important Data Should Be Centralized, Shared, Replicated, Federated, or Kept Local
- Establishing the Enterprise Role of Master Data and Reference Data
- Defining Data Product and Domain Boundaries for Enterprise Reuse
- Tracing Critical Data Flows, Lineage, and Transformations Across the Enterprise
- Applying Privacy, Sovereignty, Security, Retention, and Regulatory Constraints to Data Architecture
- Preparing Enterprise Information Architecture for Analytics, Automation, and AI
- Managing Application and Service Architecture
- Managing Integration and Interoperability Architecture
- Managing Technology, Platform, and Infrastructure Architecture
- Deciding Which Technology Choices Require Enterprise Coordination
- Defining the Boundary of a Shared Enterprise Platform
- Choosing Between Cloud, SaaS, Managed Service, On-Premises, Edge, and Hybrid Deployment
- Establishing Shared Enterprise Foundations for Identity, Connectivity, Management, and Observability
- Evaluating a Platform Against Enterprise Resilience, Security, Scalability, and Operability Needs
- Defining Workload Placement Principles Across Available Environments
- Balancing Shared Platform Consistency Against Workload Autonomy
- Integrating Multiple Shared Platforms into a Coherent Enterprise Technology Architecture
- Evolving a Shared Platform Architecture as Demand and Technology Change
- Preventing a Shared Platform or Platform Team from Becoming an Enterprise Bottleneck
- Integrating Cross-Cutting Architecture Qualities and Constraints
- Managing Application Portfolios and Rationalization
- Managing Technology Portfolios, Lifecycle, and Obsolescence
- Managing Strategic Suppliers, Platform Dependencies, Portability, and Exit
- Governing Architecture Through Investment and Portfolio Decisions
- Governing Architecture Through Procurement and Sourcing
- Shaping Architecture Requirements Before a Technology Procurement Is Fixed
- Challenging a Procurement Request That Prematurely Prescribes a Product or Solution
- Evaluating the Architecture of Competing Supplier Solutions
- Specifying Interoperability, Data, Portability, and Exit Requirements in a Procurement
- Assessing Architectural Lock-In Created by Commercial Terms or Supplier Design
- Aligning a Procurement with Enterprise Standards, Platforms, and Target Architecture
- Handling a Procurement Constraint That Makes the Preferred Architecture Impractical
- Coordinating Architecture Input with Procurement, Security, Legal, Data, and Business Stakeholders
- Reassessing Architecture During Contract Renewal or Recompetition
- Ensuring a Procured Solution Can Be Transitioned, Replaced, and Retired Responsibly
- Governing and Assuring Architecture Through Product, Program, and Delivery
- Managing Architecture Exceptions, Temporary Deviations, and Technical Debt
- Managing Major Modernization and Enterprise Transformation
- Managing Architecture Through Mergers, Acquisitions, Divestitures, and Separations
- Responding to Regulatory, Geopolitical, Supplier, Security, and Technology Change
- Managing Architecture Knowledge, Repositories, and Tooling
- Measuring Enterprise Architecture Value and Outcomes
- Learning, Adapting, and Sustaining the Enterprise Architecture Capability
Defining the Purpose, Scope, and Mandate of Enterprise Architecture
Establishing Why Enterprise Architecture Is Needed
- What recurring enterprise problems are we expecting Enterprise Architecture to help us solve?
- Which decisions are currently being made too locally, too late, or without enough cross-enterprise context?
- Where is the lack of architectural coherence creating material cost, risk, duplication, or change difficulty?
- Which strategic changes are exposing weaknesses in how our capabilities, information, applications, and technologies fit together?
- What evidence shows that these problems require an enterprise-level architecture response rather than better execution within existing functions?
- What would improve if we established a stronger Enterprise Architecture capability?
- What would remain unresolved even if the Enterprise Architecture capability worked well?
Clarifying Which Decisions Enterprise Architecture Should Improve
- Which recurring decisions have consequences that extend beyond a single system, team, domain, or initiative?
- Which decisions are difficult or expensive to reverse once they have been made?
- Where would better visibility of dependencies, alternatives, or future consequences materially improve a decision?
- Which decisions currently suffer because strategic, business, data, application, and technology considerations are assessed separately?
- Which decisions should Enterprise Architecture inform without owning?
- Which decisions are already handled well enough elsewhere that Enterprise Architecture should not become involved?
- How will we know whether Enterprise Architecture is actually improving the decisions within its scope?
- Which parts of the business architecture need to be represented for the decisions Enterprise Architecture must support?
- Which information and data concerns need enterprise-level architectural attention?
- Which application and service concerns belong within the Enterprise Architecture scope?
- Which technology, platform, and infrastructure concerns require enterprise-level coordination?
- Which relationships across business, information, applications, and technology are important enough to manage explicitly?
- Where should detailed specialist architecture begin rather than Enterprise Architecture continuing deeper?
- Is our proposed scope broad enough to expose cross-layer consequences without becoming an attempt to model or govern everything?
Choosing the Organizational and Architectural Boundaries of the Enterprise Architecture Practice
- Which business units, regions, legal entities, portfolios, or shared functions should fall within the Enterprise Architecture boundary?
- Where do architectural decisions cross organizational boundaries often enough to require common coordination?
- Which semi-autonomous areas need enterprise constraints, and which can remain architecturally independent?
- What external partners, suppliers, platforms, or ecosystems need to be considered even though they sit outside our formal organization?
- Where would drawing the boundary too narrowly hide important dependencies or externalities?
- Where would drawing the boundary too broadly create unnecessary governance or modeling effort?
- What events should cause us to reconsider the organizational or architectural boundary?
Distinguishing Enterprise Architecture from Adjacent Practices
- Which parts of this problem belong to Enterprise Architecture rather than business strategy?
- Which decisions belong to Business Architecture rather than Enterprise Architecture?
- Where should Solution Architecture take over from enterprise-level architectural direction?
- Which questions belong to Systems Engineering, Software Architecture, Data Management, Cybersecurity, or Technology Operations instead?
- Which organizational questions should remain with Organizational Design rather than Enterprise Architecture?
- Which investment and commercial decisions should remain with Portfolio Management and Procurement?
- What interface do we need between Enterprise Architecture and each adjacent practice so that important issues do not fall between them?
- What authority does Enterprise Architecture actually need to fulfill its intended purpose?
- Which architecture decisions should the Enterprise Architecture function be able to make directly?
- Which decisions should Enterprise Architecture only advise, assess, or escalate?
- Who should formally sponsor the Enterprise Architecture mandate?
- What happens when an initiative or business unit rejects an enterprise architecture direction?
- How should the mandate distinguish architecture approval from business, funding, delivery, and risk acceptance authority?
- What would make the mandate credible in practice rather than merely formal on paper?
Defining the Stakeholders and Value Expected from Enterprise Architecture
- Who relies on Enterprise Architecture to make better decisions?
- What does each major stakeholder group need from Enterprise Architecture?
- Which stakeholders experience the costs of poor architectural coherence even if they do not currently engage with architects?
- What value should senior leadership expect from Enterprise Architecture?
- What value should portfolio, product, delivery, platform, data, security, and procurement teams expect?
- Where do stakeholder expectations conflict with one another or with the intended EA mandate?
- Which expected benefits are realistic for Enterprise Architecture to influence, and which are outside its control?
Setting the Scope of Enterprise Architecture During Organizational Growth or Change
- Which new parts of the enterprise now need to be brought within the architecture scope?
- What architectural dependencies have emerged because the organization has grown or changed?
- Which previously local decisions now have enterprise-wide consequences?
- Where has decentralization, expansion, acquisition, or restructuring created inconsistent architecture that now needs coordination?
- Which existing architecture standards or governance mechanisms still fit the enlarged or changed organization?
- What should remain locally autonomous despite the broader enterprise scope?
- How should we expand the EA scope without creating unnecessary central control or documentation burden?
Resetting an Enterprise Architecture Mandate That Has Drifted
- How has the current Enterprise Architecture mandate drifted from the problems it was originally meant to address?
- Which EA activities now consume effort without materially improving enterprise decisions?
- Has Enterprise Architecture become too focused on documentation, approval, technology control, or strategy abstraction?
- Which important enterprise decisions currently fall outside the effective EA mandate?
- Which responsibilities should be stopped, transferred, strengthened, or newly added?
- What authority and stakeholder relationships need to change for the reset mandate to work?
- What evidence would show that the reset has changed EA behavior rather than merely rewritten its charter?
Reassessing the Enterprise Architecture Mandate After Major Strategic or Organizational Change
- Which assumptions behind the existing EA mandate are no longer true?
- How has the strategic or organizational change altered the decisions Enterprise Architecture needs to support?
- Have new domains, business models, technologies, suppliers, or regulatory conditions expanded the necessary architecture scope?
- Which existing EA responsibilities are now less important or should move elsewhere?
- Does the current governance authority still match where consequential architecture decisions are being made?
- What should remain stable in the EA mandate despite the organizational change?
- When should the revised mandate be reviewed again to confirm that it fits the new operating reality?
Designing the Enterprise Architecture Operating Model
Choosing Between Centralized, Federated, Distributed, Embedded, and Hybrid Architecture Models
- Which architecture decisions need consistent enterprise-wide direction, and which are safe to distribute?
- How much local autonomy do our business domains and delivery teams genuinely require?
- Where does scarce architecture expertise need to be concentrated rather than replicated?
- What coordination problems would a centralized model solve, and what bottlenecks could it create?
- What fragmentation risks would a distributed model introduce?
- Would a federated or hybrid model better match the different decision categories we need to govern?
- What evidence would tell us that the chosen operating model is producing the right balance of coherence and autonomy?
Locating Architects Across Central Functions, Domains, Portfolios, Platforms, and Delivery Teams
- Which architecture responsibilities require an enterprise-wide vantage point?
- Which architecture roles need to sit close to business domains or product teams to remain effective?
- Where should architects be embedded to influence decisions early rather than review them later?
- Which shared platforms or portfolios need dedicated architectural ownership?
- How can architects remain connected to enterprise direction when they sit inside decentralized teams?
- Where would placing an architect create duplicate responsibility rather than useful capability?
- What organizational placement would give each architecture role the access, authority, and context it needs?
Designing How Central and Embedded Architects Work Together
- What decisions should embedded architects make without central approval?
- Which enterprise concerns must embedded architects bring back to the central architecture function?
- How should central architects communicate principles, standards, roadmaps, and cross-domain dependencies to embedded architects?
- What shared forums or working mechanisms are needed to resolve issues that cross domains?
- How should disagreements between central and embedded architects be resolved?
- How can local delivery evidence feed back into enterprise architecture direction?
- How do we prevent central and embedded architects from producing parallel architectures or conflicting guidance?
Defining the Services the Enterprise Architecture Function Provides
- Which recurring services would materially improve enterprise decisions?
- Who are the consumers of each proposed architecture service?
- Which services should focus on strategic direction, portfolio support, standards, assurance, dependency analysis, or architecture knowledge?
- Which proposed services duplicate work already performed by other functions?
- What should stakeholders be able to request from Enterprise Architecture?
- Which services should be proactive rather than request-driven?
- Which architecture services should we stop if their effort consistently exceeds their decision value?
Matching the Architecture Operating Model to Organizational Scale, Structure, and Maturity
- How does the size of the enterprise affect the amount of architecture coordination we need?
- Which parts of the organization are mature enough to make delegated architecture decisions responsibly?
- Where does the organization still need stronger central architectural support or control?
- How do geographic, legal, business-unit, or product boundaries affect the operating model?
- Does our delivery model favor project-based governance, product-based ownership, or a mixture of both?
- Which parts of the operating model should differ between mature and less mature domains?
- What changes to the operating model should occur as architecture capability becomes more distributed and mature?
Coordinating Architecture Across Business Units, Regions, and Semi-Autonomous Organizations
- Which architectural concerns genuinely need consistency across business units or regions?
- Where do local regulatory, market, operational, or customer conditions justify architectural variation?
- Which shared capabilities or platforms create dependencies between otherwise autonomous units?
- How should cross-unit architecture decisions be made when benefits and costs fall on different organizations?
- What common information, standards, or reference architectures are necessary for coordination?
- How should legitimate local exceptions be represented without losing enterprise visibility?
- What mechanism will resolve architecture conflicts that cannot be settled within one business unit or region?
Scaling Enterprise Architecture Without Creating a Central Bottleneck
- Which architecture decisions are currently waiting unnecessarily for central review?
- Which decisions could safely move to teams if clearer standards or guardrails existed?
- Where could self-service reference architectures, patterns, or decision guidance replace manual review?
- Which architecture checks can be automated or embedded in delivery workflows?
- Which high-consequence decisions still warrant direct enterprise architect involvement?
- How should escalation work when a delegated decision exceeds local authority?
- What measures would show whether EA has scaled without sacrificing architectural coherence?
Integrating Enterprise Architecture with Existing Governance and Management Processes
- Which existing strategy, investment, risk, procurement, security, data, and delivery processes already touch architecture decisions?
- Where should Enterprise Architecture enter those processes to influence decisions before commitments become difficult to reverse?
- Which existing governance body can handle an architecture concern instead of creating another forum?
- Where are architecture responsibilities duplicated across governance processes?
- What architecture information should flow into portfolio, procurement, risk, and delivery decisions?
- What decisions or evidence should flow back from those processes into Enterprise Architecture?
- How can we integrate EA into existing processes without turning every initiative into a separate architecture approval exercise?
Changing the Architecture Operating Model as Delivery and Technology Models Evolve
- Which parts of the current architecture operating model were designed for ways of working that no longer dominate?
- How should the operating model change as teams move from projects to long-lived products?
- What architecture responsibilities change when shared platforms become more important?
- How should cloud, SaaS, automation, low-code, or AI-enabled delivery affect architecture governance?
- Which central approvals can become delegated or automated under the new delivery model?
- What new coordination mechanisms are needed as technology decisions become more distributed?
- How can we change the operating model without losing accountability for existing architecture decisions?
Diagnosing an Enterprise Architecture Operating Model That Is No Longer Working
- What evidence shows that the current operating model is failing?
- Are architecture decisions too slow, too centralized, too inconsistent, or too disconnected from delivery?
- Where are responsibilities unclear or duplicated?
- Which stakeholders routinely bypass the architecture process, and why?
- Are central architects too distant from operational reality, or are embedded architects too disconnected from enterprise direction?
- Which governance mechanisms generate effort without changing outcomes?
- What is the smallest operating-model change likely to address the underlying problem?
Establishing Architecture Roles, Decision Rights, and Governance
Clarifying Responsibilities Across Enterprise, Domain, Specialist, Platform, and Solution Architects
- What should each architecture role be accountable for?
- Which decisions should enterprise architects own because they span several domains?
- Which decisions should domain or specialist architects make within their bounded area?
- What should platform architects own for shared platforms and their interfaces?
- What should solution architects own for a specific product, project, or initiative?
- Where do the current role definitions overlap or leave important responsibilities unowned?
- How should the roles collaborate when a decision crosses enterprise, domain, platform, and solution boundaries?
Assigning Ownership for Consequential Architecture Decisions
- Who has the authority to make this architecture decision?
- Who will live with the consequences if the decision proves wrong?
- Does the proposed decision owner have enough visibility across all materially affected domains?
- Which stakeholders must contribute evidence without becoming joint decision owners?
- Who owns the business tradeoff if architecture alternatives have materially different business consequences?
- Who owns any residual risk created by the decision?
- How should ownership be recorded so it remains clear after people or organizational structures change?
Delegating Local Architecture Decisions Within Enterprise Guardrails
- Which decisions can this team make safely without further architecture approval?
- What enterprise principles, standards, patterns, or constraints define the boundary of that authority?
- What level of consequence or dependency should trigger escalation?
- How reversible are the decisions being delegated?
- What evidence should the team retain to show that its decision remained within the guardrails?
- What happens when the team believes a guardrail is inappropriate for its situation?
- How will we know whether delegation is reducing unnecessary governance without increasing architectural drift?
Defining When an Architecture Decision Must Be Escalated
- Does this decision affect more than one domain, portfolio, platform, or business unit?
- Does it create a new shared dependency or enterprise precedent?
- Would it be expensive or difficult to reverse later?
- Does it depart materially from an established architecture principle, standard, target state, or roadmap?
- Does it create significant security, resilience, regulatory, supplier, or data consequences?
- Which governance level has enough authority and context to resolve the issue?
- What information must accompany the escalation so the receiving body can make the decision efficiently?
Establishing an Architecture Board or Design Authority
- What kinds of decisions genuinely require this board or design authority?
- What authority should the body have, and what should remain outside its remit?
- Who needs to participate for the body to understand both enterprise and delivery consequences?
- What evidence should be required before a decision comes to the board?
- How should routine or low-consequence matters be kept out of the board?
- How will decisions, conditions, exceptions, and unresolved issues be recorded and followed through?
- What measures would reveal that the board has become a bottleneck or is no longer adding enough value?
Resolving Conflicting Architecture Decisions Across Roles or Domains
- What exactly is in conflict between the architecture positions?
- Are the conflicting positions based on different requirements, assumptions, evidence, or optimization boundaries?
- Which enterprise constraints are genuinely mandatory?
- Which aspects of the disagreement are local preferences rather than enterprise concerns?
- What are the consequences of each option for the affected domains?
- Can the conflict be resolved through bounded variation, explicit interfaces, or a controlled exception?
- Who should make the final decision if the disagreement cannot be resolved by the architects involved?
Separating Architecture Authority from Business, Investment, and Risk Authority
- Which part of this decision is an architecture judgment?
- Which part requires a business owner to choose between outcomes or tradeoffs?
- Which part requires portfolio or investment authority?
- Which risks need explicit acceptance by an accountable risk owner rather than an architect?
- Is architecture approval being mistaken for funding, business, security, or operational approval?
- What recommendation should architects provide when the final decision belongs elsewhere?
- How should the different decisions be recorded so responsibility does not become blurred?
Resolving Gaps and Overlaps in Architecture Responsibility
- Which architecture decisions currently have no clear owner?
- Where are two or more roles making decisions over the same territory?
- Which responsibilities are being assumed informally because formal ownership is unclear?
- What problems have the gaps or overlaps created in recent initiatives?
- Should responsibility move to an enterprise, domain, platform, specialist, or solution level?
- Which interfaces between architecture roles need to be made explicit?
- How will we verify that the revised responsibilities work in real decisions rather than only on an organizational chart?
Recording Who Made an Architecture Decision and Who Owns Its Consequences
- Who made this architecture decision?
- What authority allowed that person or body to make it?
- Which stakeholders contributed evidence or advice?
- Who owns implementation of the decision?
- Who owns the business, operational, security, financial, or other consequences that remain?
- Under what conditions should the decision be reviewed or superseded?
- Where should this information be recorded so later teams can understand the decision and its accountability?
Revising Architecture Decision Rights When Governance Is Not Producing Good Outcomes
- Which architecture decisions are currently being made at the wrong organizational level?
- Where is central governance delaying decisions without materially improving them?
- Where has excessive delegation produced fragmentation or unrecognized enterprise risk?
- Which recurring escalations indicate that local decision rights are unclear or too narrow?
- Which repeated exceptions indicate that governance authority no longer matches operating reality?
- What decision rights should move upward, downward, or sideways?
- What evidence should we monitor after the change to determine whether the new decision-rights model is better?
Framing Architecture Problems, Stakeholders, and Requirements
Determining Whether a Problem Actually Requires Enterprise Architecture
- Does this problem cross organizational, capability, information, application, or technology boundaries?
- Would solving it locally create meaningful consequences elsewhere in the enterprise?
- Does the problem involve a durable dependency, shared capability, enterprise standard, or difficult-to-reverse commitment?
- Is the primary question about enterprise coherence or about executing within an already agreed architecture?
- Which existing specialist or management function could address the problem without Enterprise Architecture involvement?
- What would Enterprise Architecture contribute that a local architecture or delivery team cannot?
- What is the risk of treating this as an enterprise architecture problem when it is actually local?
Scoping an Architecture Problem Before Detailed Analysis Begins
- What decision are we actually trying to make?
- Which part of the enterprise is materially affected by that decision?
- Which business, information, application, and technology concerns are relevant?
- What time horizon does the decision need to address?
- Which dependencies and adjacent domains must be considered?
- What is explicitly outside the scope of this architecture work?
- What evidence would tell us that the scope is too narrow or too broad?
Identifying the Stakeholders and Concerns That Should Shape the Architecture Work
- Who is materially affected by the architecture decision?
- Who owns the business outcomes the architecture is intended to support?
- Who operates, secures, finances, supplies, governs, or depends on the resulting architecture?
- Which stakeholders hold evidence that could materially change our understanding of the problem?
- Which stakeholder concerns are mandatory constraints and which are preferences?
- Which affected groups are easy to overlook because they are downstream or outside the initiating organization?
- How should conflicting stakeholder concerns be represented without prematurely resolving them?
Separating Requirements, Constraints, Preferences, and Assumptions
- Which stated needs are true requirements for the architecture?
- Which conditions are externally imposed constraints that cannot simply be traded away?
- Which requested characteristics are preferences rather than necessities?
- Which parts of the problem statement depend on assumptions that have not been validated?
- Are any preferred solutions being presented as requirements?
- What changes if one of the key assumptions proves false?
- Which distinctions need to be made explicit before architecture options can be compared fairly?
Reconciling Conflicting Requirements from Different Stakeholders
- Which requirements are actually in conflict?
- Are the requirements based on different outcomes, constraints, assumptions, or risk tolerances?
- Which requirements are mandatory and which can be negotiated?
- What architectural options satisfy the most important concerns without pretending all requirements can be maximized?
- What does each stakeholder give up under the available options?
- Can the conflict be reduced through segmentation, different service levels, or bounded variation?
- Who has the authority to decide the remaining tradeoff if no architecture satisfies all requirements?
Identifying Important Requirements That the Initial Request Has Missed
- What business outcomes or capabilities would be affected beyond the scope described in the initial request?
- Which information, integration, security, resilience, regulatory, or operational requirements have not yet been considered?
- What enterprise standards or platform constraints apply?
- Which lifecycle, support, portability, or exit requirements could become important later?
- What downstream consumers or dependencies could impose requirements that the initiating team does not see?
- Which transition requirements matter while old and new architecture coexist?
- What future changes should the architecture preserve room for even if they are not immediate requirements?
Determining the Level of Architectural Detail the Decision Requires
- What level of detail is necessary to make this decision responsibly?
- Which architectural relationships must be understood before the decision can be made?
- What detailed information belongs with domain, solution, data, security, or engineering specialists instead?
- What additional detail could realistically change the decision?
- Where would more modeling create precision without additional decision value?
- Does the consequence or irreversibility of the decision justify deeper evidence?
- What can remain unresolved until a later design or implementation decision?
Working with Requirements That Are Incomplete, Uncertain, or Still Changing
- Which requirements are sufficiently stable to guide architecture now?
- Which requirements remain uncertain or are likely to change?
- What architecture choices would become unsafe if those uncertain requirements changed?
- Which decisions can be deferred until uncertainty is reduced?
- Where should we preserve options rather than commit prematurely?
- What assumptions should be made explicit in the meantime?
- What trigger should cause the architecture to be reassessed as requirements become clearer?
Reframing the Architecture Problem When New Evidence Changes the Original Understanding
- What new evidence contradicts or materially changes the original problem statement?
- Which original assumptions are no longer credible?
- Has the real problem moved to a different architectural layer or organizational boundary?
- Does the new evidence change which stakeholders or dependencies matter?
- Which architecture work already completed remains valid?
- Which options should be reconsidered because the problem has changed?
- How should the revised problem be stated before further design or decision-making continues?
Confirming the Architecture Question Before Committing to a Solution Direction
- What exact architecture question must be answered before we choose a solution direction?
- Are we solving the underlying problem or merely evaluating the first proposed solution?
- What outcome would a successful architecture decision enable?
- Which constraints and requirements must any viable direction satisfy?
- What materially different solution directions are still open?
- What important evidence is still missing before commitment?
- What would make us conclude that the question has been framed well enough to proceed?
Connecting Strategy and Enterprise Architecture
Translating a Strategic Objective into Architectural Implications
- What capabilities must change for this strategic objective to be achievable?
- What information must become available, better governed, or more widely shared?
- Which applications, services, or platforms would need to change?
- What new dependencies or enterprise constraints would the strategy create?
- Which parts of the current architecture would help or hinder the objective?
- What architectural enablers need to exist before the strategy can be executed?
- Which architectural consequences are durable enough to influence enterprise direction now?
Testing Whether a Strategic Priority Actually Requires Architectural Change
- What would prevent us from achieving this priority with the current architecture?
- Is the gap primarily architectural, organizational, process-related, commercial, or capability-related?
- Which current architecture elements already support the required outcome adequately?
- Does the priority create new cross-enterprise dependencies or structural requirements?
- Would local delivery changes be sufficient without changing enterprise architecture?
- What architectural change would materially improve the probability of achieving the priority?
- What evidence would justify leaving the enterprise architecture unchanged?
Reconciling Strategic Priorities That Imply Conflicting Architectural Directions
- Which architectural directions are implied by the competing strategic priorities?
- Where do those directions genuinely conflict?
- Which constraints or outcomes are non-negotiable?
- Can the conflict be resolved through segmentation, different architectural tiers, or bounded autonomy?
- What enterprise-wide consequences follow from prioritizing one direction over the other?
- Which tradeoff belongs to business leadership rather than architecture?
- What architecture direction preserves the most important strategic options while the conflict remains unresolved?
Identifying Architectural Constraints That Limit a Strategic Option
- Which parts of the current architecture constrain this strategic option?
- Are the constraints technical, informational, contractual, regulatory, operational, or organizational?
- Which constraints are temporary and which are structural?
- What would it take to remove or reduce each material constraint?
- How long would the necessary architectural change take relative to the strategic opportunity?
- Which constraints cannot reasonably be removed and therefore need to shape the strategy?
- What alternative strategic option becomes more attractive once the architectural constraints are made explicit?
Exposing Architectural Prerequisites for a Strategic Initiative
- Which shared capabilities must exist before this initiative can succeed?
- What data, integration, platform, identity, security, or infrastructure foundations are required?
- Which legacy dependencies must be changed or retired first?
- What enterprise standards or reference architectures need to be established?
- Which other initiatives does this strategy depend on?
- Which prerequisites are currently unfunded or lack a clear owner?
- What happens to the strategic initiative if a prerequisite is delayed or never delivered?
Distinguishing Temporary Strategic Initiatives from Durable Architectural Direction
- Which parts of this strategic initiative represent a lasting enterprise need?
- Which requirements are specific to a temporary program, market condition, or leadership priority?
- What architecture would still make sense after the initiative ends?
- Are we creating permanent shared infrastructure for a short-lived requirement?
- Which architectural choices preserve flexibility if the strategy changes?
- What temporary architecture should have explicit exit or retirement conditions?
- Which enduring capability or structural change should remain after the initiative is complete?
Keeping Architecture Direction Aligned When Strategy Changes
- Which parts of the current architecture direction were based on the old strategy?
- Which target-state assumptions are no longer valid?
- Which planned architecture changes remain useful under the new strategy?
- Which roadmaps, standards, investments, or platform directions now need reconsideration?
- What architecture commitments are already difficult or expensive to reverse?
- Which new strategic requirements need architectural support?
- How much of the architecture direction should change now versus remain stable until the new strategy proves durable?
Using Architecture Evidence to Compare Strategic Options
- How well can the current architecture support each strategic option?
- What major capability gaps would each option create?
- Which option requires the largest or most difficult architectural transition?
- What existing assets or shared capabilities could each option reuse?
- What new dependencies, supplier commitments, or concentration risks would each option introduce?
- Which architectural assumptions create the greatest uncertainty in the comparison?
- What architecture evidence materially changes the relative feasibility, cost, speed, or flexibility of the strategic options?
Challenging a Technology Solution That Has Been Prematurely Attached to a Strategic Goal
- What strategic outcome is the proposed technology actually intended to enable?
- What capability requirement exists independently of the proposed solution?
- What evidence shows that this technology is necessary rather than merely familiar or available?
- Which materially different architectural approaches could achieve the same outcome?
- What existing capabilities, platforms, or services could be reused?
- What long-term dependencies or constraints would the proposed technology create?
- What would we choose if we started from the required outcome rather than the preferred technology?
Tracing Architecture Change Back to the Strategic Outcome It Is Intended to Enable
- Which strategic outcome is this architecture change intended to support?
- What capability change connects the architectural work to that outcome?
- Which part of the architecture change is essential to realizing the benefit?
- What assumptions connect the architecture change to the expected strategic result?
- What other organizational or operational changes must occur for the architectural benefit to materialize?
- How would we know that the architecture change succeeded technically but failed strategically?
- What evidence should we monitor to determine whether the architecture is actually enabling the intended outcome?
Using Business Capabilities, Value Streams, and Services to Shape Architecture
Identifying the Capabilities Required to Deliver a Strategic Outcome
- What must the enterprise be able to do for this strategic outcome to become achievable?
- Which existing capabilities are directly involved in delivering the outcome?
- What new capabilities are required that the enterprise does not currently possess?
- Which capabilities need to become stronger rather than simply exist?
- What level of performance, scale, resilience, or reach does each required capability need?
- Which apparent capability gaps are actually caused by process, organization, information, application, or technology weaknesses?
- Which capability changes are important enough to drive architectural investment or target-state design?
Creating a Capability View That Crosses Organizational Boundaries
- What capabilities exist independently of the organizational units that currently perform them?
- Where are similar capabilities distributed across several functions, regions, or business units?
- Which capability boundaries remain meaningful even if reporting lines or organizational structures change?
- Where have organizational structures caused us to define duplicate or artificially fragmented capabilities?
- Which capabilities depend on contributions from several parts of the enterprise?
- What level of capability decomposition is useful for enterprise architecture decisions without becoming a process inventory?
- How should we validate the capability view with business stakeholders who see the enterprise through different organizational structures?
Using Value Streams to Expose How Capabilities Must Work Together
- What stakeholder outcome does this value stream ultimately produce?
- Which capabilities contribute at each important stage of the value stream?
- Where does value depend on capabilities owned by different organizational units?
- Which handoffs, dependencies, or delays reveal architectural weaknesses between capabilities?
- What information must move across the value stream for the capabilities to work together?
- Which applications, services, or platforms create important dependencies along the value stream?
- Where would an architectural change improve the value stream rather than optimize only one participating capability?
Using Business Services to Clarify Consumers and Outcomes
- What business service is actually being provided, and to whom?
- What outcome does the consumer expect from the service?
- Which capabilities must work together to provide that service?
- Where is responsibility for the service unclear because several organizational units contribute to it?
- What information, applications, and shared platforms does the service depend on?
- Which service expectations materially affect the architecture, such as availability, responsiveness, security, or geographic reach?
- Would defining the service more clearly change how we divide responsibilities or architecture boundaries?
Distinguishing Capabilities from Processes, Organizational Units, and Systems
- Are we describing what the enterprise must be able to do, or how it currently performs the work?
- Would this capability still exist if the process used to deliver it changed completely?
- Would this capability still exist if the organizational unit responsible for it were reorganized?
- Are we accidentally naming an application or technology as though it were a business capability?
- Which processes realize this capability today without defining the capability itself?
- Which organizational units contribute to the capability without individually owning the entire capability?
- How should we rename or restructure the model where process, organization, system, and capability concepts have been mixed together?
Assessing a Capability Gap Before Choosing an Intervention
- What capability level is actually required for the intended business outcome?
- What evidence shows how well the capability performs today?
- Where is the meaningful gap between current and required capability?
- Is the gap caused by process, organization, skills, authority, information, applications, integration, technology, governance, or some combination?
- Which weaknesses are symptoms rather than causes of the capability gap?
- What would happen if we addressed the technology without correcting the other causes?
- Which interventions should be considered before assuming that a new system or platform is necessary?
Prioritizing Architectural Attention Across Capabilities with Different Importance, Criticality, Maturity, Cost, and Risk
- Which capabilities are strategically important even if their current maturity is already high?
- Which capabilities are operationally critical even if they do not differentiate the enterprise?
- Where is low maturity actually below the level required for the capability?
- Which capabilities create disproportionate cost or architectural complexity?
- Which capabilities expose the enterprise to material risk because of weak architectural support?
- How should we compare importance, criticality, maturity, cost, and risk without collapsing them into a misleading single score?
- Which capabilities warrant architectural attention first once these dimensions and their dependencies are considered together?
Distinguishing Differentiating Capabilities from Commodity Capabilities
- Which capabilities genuinely contribute to strategic differentiation?
- Which capabilities are necessary but provide little advantage from being unique?
- What evidence shows that a supposedly differentiating capability actually matters to customers, users, mission, or competitive position?
- Where are we customizing commodity capabilities without a clear business benefit?
- Where would excessive standardization weaken a capability that genuinely differentiates the enterprise?
- Which architectural layers could be standardized even when the business capability itself remains differentiated?
- How should the distinction between differentiating and commodity capabilities influence reuse, sourcing, platform, and investment decisions?
Using the Operating Model to Decide Where Standardization or Autonomy Is Appropriate
- Which parts of the enterprise need to operate in a highly integrated way?
- Which capabilities need common processes, information, or technology across business units?
- Where does local autonomy create meaningful business value?
- Where does unnecessary variation create cost, risk, duplication, or interoperability problems?
- Which architectural layers should be common even when business execution remains locally differentiated?
- Where would enterprise standardization impose a lowest-common-denominator solution on materially different operating contexts?
- What combination of shared foundations and local variation best matches the operating model?
Revising Capability, Value Stream, or Service Models When the Business Changes
- Which parts of the current model no longer reflect how the enterprise creates or delivers value?
- Have new capabilities emerged or existing capabilities materially changed?
- Have reorganizations changed responsibility without actually changing the underlying capabilities?
- Have new products, channels, regulations, or operating models altered important value streams?
- Do existing service definitions still match their consumers and intended outcomes?
- Which historical elements should be preserved for continuity, and which now distort architecture decisions?
- What downstream architecture maps, roadmaps, or investment views need updating when the business model changes?
Mapping Business Capabilities to the Applications and Services That Enable Them
- Which applications and services materially support this capability?
- Does each application support the whole capability or only a specific part of it?
- Which capabilities depend on the same application or service?
- Where are several applications providing substantially similar support to the same capability?
- Which critical capability relies on applications with weak ownership, lifecycle, resilience, or strategic fit?
- Where does the mapping reflect declared support rather than actual operational dependence?
- What architectural decisions become possible once capability-to-application relationships are visible?
- What information does this capability need to operate effectively?
- Which information domains supply that information?
- What sources are authoritative for the most important information?
- Where does the capability depend on duplicated, inconsistent, delayed, or poorly governed information?
- Which information dependencies cross organizational or domain boundaries?
- What information must be shared with other capabilities for end-to-end outcomes to work?
- Which architecture changes would most improve the reliability or usability of information supporting this capability?
- Which shared platforms are necessary for this capability to function?
- Which foundational technologies create important dependencies for the capability?
- Does the capability depend on a platform directly or through the applications and services that support it?
- Which supposedly independent capabilities share the same critical platform dependency?
- What would happen to the capability if a key platform became unavailable, constrained, or obsolete?
- Where is a capability relying on technology that conflicts with future architecture direction?
- Which shared-platform investments would improve several capabilities at once?
Mapping Active Initiatives and Investments to the Capabilities They Change
- Which capabilities is each active initiative intended to improve, create, or retire?
- What specific capability outcome is expected from each investment?
- Are several initiatives changing the same capability without sufficient coordination?
- Which strategically important capabilities have no meaningful investment attached to them?
- Which investments cannot be traced to a required capability change?
- What dependencies exist between initiatives because they affect related capabilities?
- Does the combined investment portfolio support the capability changes implied by strategy?
Identifying Capabilities That Are Under-Supported or Over-Supported by the Current Architecture
- Which capabilities lack the applications, information, services, or platforms needed to perform at the required level?
- Which capabilities are supported by disproportionate numbers of applications or technologies?
- Where does excess architectural support reflect duplication rather than legitimate variation?
- Are strategically important capabilities relying on fragile or obsolete architecture?
- Are low-value capabilities consuming significant architectural cost or complexity?
- Which apparent support gaps are really process, organizational, or skill problems rather than architecture problems?
- Where would reducing, consolidating, or strengthening architectural support create the greatest enterprise benefit?
Finding Strategically Important Capabilities That Depend on Weak Architecture
- Which strategically important capabilities rely on obsolete, unsupported, or fragile systems?
- Where do critical capabilities depend on poorly understood integrations or data flows?
- Which important capabilities rely on single suppliers, platforms, or technologies with high concentration risk?
- Where are important capabilities dependent on architecture with weak resilience or recovery characteristics?
- Which dependencies would be hardest to replace under time pressure?
- What strategic outcomes are at risk if the architectural weakness is not addressed?
- Which weaknesses require near-term remediation versus longer-term architectural replacement?
Identifying Investments That Do Not Clearly Support Required Capability Change
- Which investments cannot be traced to a strategic or operational capability requirement?
- Are we funding technology modernization without a clear capability outcome?
- Which investments mainly preserve existing architecture without addressing an identified need or risk?
- Are several investments justified by vague claims of transformation rather than specific capability changes?
- What business outcome would be lost if this investment did not proceed?
- Could the same capability need be addressed through reuse, process change, organizational change, or a smaller architectural intervention?
- Should the investment be reframed, reduced, redirected, or stopped based on its weak capability linkage?
Assessing the Cross-Layer Effects of Changing a Business Capability
- What information requirements change if this capability changes?
- Which applications and services would need to be modified, replaced, or newly introduced?
- Which shared platforms or technologies would be affected?
- What integrations and upstream or downstream dependencies would change?
- Which organizational owners or operating responsibilities would need to change with the architecture?
- What existing standards, roadmaps, contracts, or supplier relationships constrain the change?
- Which effects are temporary transition concerns and which represent permanent architecture change?
- Which changes are technically or operationally inseparable?
- What information changes must occur before dependent application changes can succeed?
- Which application changes require new platform capabilities first?
- Which technology migrations would break applications that cannot yet move?
- Where can temporary interfaces or coexistence reduce the need for synchronized change?
- Which changes can safely proceed independently without creating costly rework?
- How should the dependency groups influence sequencing, funding, and transition planning?
Maintaining Capability-to-Architecture Traceability as the Enterprise Evolves
- Which capability-to-architecture relationships need to stay current because they support recurring decisions?
- Who is best placed to validate each important relationship?
- Which changes to applications, platforms, information, or capabilities should trigger an update?
- How can we distinguish current relationships from planned or transitional ones?
- What evidence should support relationships that have significant investment or risk implications?
- Where can relationships be derived automatically from authoritative systems rather than maintained manually?
- How do we detect when the traceability model has become stale enough to mislead decisions?
Reconstructing the Current Enterprise Architecture
Establishing the Current Architecture Needed for a Specific Decision
- What decision must the current-state architecture support?
- Which architecture elements could materially affect that decision?
- What relationships and dependencies must be understood before deciding?
- Which parts of the enterprise can remain outside the current-state scope?
- How recent does the information need to be for this decision?
- What level of detail would change the decision, and what detail would merely add documentation effort?
- What minimum current-state view would allow us to proceed responsibly?
Reconciling Conflicting Application, Technology, and Architecture Inventories
- Which inventories disagree about what exists?
- Are the conflicts about existence, ownership, lifecycle, usage, technology, or relationships?
- Which source is authoritative for each type of fact?
- What operational evidence can confirm whether an asset is actually in use?
- Are different inventories describing the same thing at different levels of abstraction?
- Which conflicts materially affect current architecture decisions and therefore need resolution now?
- How should unresolved discrepancies be represented rather than silently choosing one source?
Discovering the Application and Service Landscape That Actually Exists
- Which applications and services are demonstrably active in the enterprise?
- Which systems appear in formal inventories but show little or no evidence of current use?
- Which active services exist outside the official architecture repository?
- What evidence from identity, network, cloud, source, finance, procurement, or operational systems can reveal the real landscape?
- Which business owners can validate the purpose and importance of discovered applications?
- Where are local variants or duplicate services hidden behind common labels?
- What gaps remain after comparing declared architecture with observed operational evidence?
- Which tools or systems are being used outside the formally approved architecture?
- What business need caused users to adopt or create them?
- Which shadow systems hold important data or support critical work?
- What security, resilience, compliance, integration, or continuity risks do they create?
- Are they evidence that approved enterprise capabilities are missing or inadequate?
- Which should be incorporated, replaced, constrained, tolerated, or retired?
- What architectural or governance change would prevent the same workaround from reappearing elsewhere?
- Which systems appear to exchange data despite having no documented integration?
- What network, API, messaging, database, file-transfer, or operational evidence can reveal the connection?
- What information actually moves through each undocumented exchange?
- Which system is the producer, consumer, and authoritative source?
- How critical is the exchange to business operations?
- What security, data, lifecycle, or ownership issues arise because the integration is undocumented?
- Which undocumented integrations need formal ownership or redesign rather than merely documentation?
Distinguishing Current, Planned, Transitional, and Retiring Architecture
- Which architecture elements are operating in production today?
- Which elements are approved or planned but not yet operational?
- Which components exist only to support a transition?
- Which elements are still active but formally scheduled for retirement?
- Are diagrams or repository views accidentally mixing future and current states?
- What date, milestone, or condition defines the movement from one state to another?
- How should uncertain or delayed transitions be represented so stakeholders do not mistake intention for reality?
Confirming Ownership, Usage, and Criticality of Existing Architecture Elements
- Who is accountable for this application, service, platform, or information asset?
- Who operates or technically maintains it?
- Which users, capabilities, and business processes actually depend on it?
- What evidence confirms that it is actively used?
- How critical is it to business or mission outcomes?
- What would happen if it became unavailable or were retired unexpectedly?
- Which elements remain materially important despite having unclear or disputed ownership?
Reconstructing the Current Architecture When Documentation Has Become Unreliable or Fragmented
- Which existing architecture sources can still be trusted, and for what kinds of information?
- What important areas have no reliable documentation at all?
- Which operational, administrative, financial, contractual, and technical evidence can rebuild the missing picture?
- Where do interviews and owner knowledge need to supplement system-generated evidence?
- Which inconsistencies reveal that planned architecture and actual architecture have diverged?
- What should we reconstruct first based on current decision needs and risk?
- How can the recovered current-state view avoid immediately becoming another stale documentation set?
Deciding When the Current-State View Is Sufficiently Complete for the Decision
- Have all architecture elements that could materially reverse the decision been investigated?
- Are critical dependencies understood well enough to assess consequences?
- Are major contradictions between sources resolved or explicitly visible?
- Are the most important ownership, lifecycle, and criticality facts confirmed?
- What remaining unknowns could still materially change the outcome?
- Would additional discovery produce decision-relevant knowledge or merely greater completeness?
- What uncertainty are we consciously accepting by proceeding with the current view?
Refreshing the Current Architecture Before a High-Consequence Decision
- Which current-state information is too old to rely on for this decision?
- What has materially changed since the architecture was last validated?
- Which dependencies deserve fresh verification because the decision is difficult to reverse?
- Have new systems, suppliers, platforms, integrations, or organizational changes altered the landscape?
- Which assumptions from the previous architecture view need to be retested?
- What evidence can confirm the most consequential facts quickly?
- What unresolved uncertainty should decision-makers see before committing?
Managing Architecture Evidence, Provenance, and Uncertainty
Choosing the Right Authoritative Source for an Architecture Fact
- What specific architecture fact are we trying to establish?
- Which system, role, or record is formally authoritative for that type of information?
- Does the authoritative source describe intended state, operational state, or both?
- What observed evidence could reveal that the authoritative record is outdated or incorrect?
- Are several sources authoritative for different aspects of the same architecture element?
- How should conflicting authoritative and observed evidence be handled?
- Where should the source of the fact be recorded so future users can judge its reliability?
- Which parts of this architecture view come directly from observed evidence?
- Which facts have been reported by owners or stakeholders but not independently verified?
- Which relationships have been inferred from incomplete evidence?
- Which elements are assumptions made so that analysis can proceed?
- Does the decision depend materially on any inferred or assumed information?
- What additional evidence could move an important item from assumption or inference to confirmed knowledge?
- How should these different evidence states be shown so users do not mistake them for equal certainty?
Reconciling Conflicting Evidence About the Current Architecture
- What exactly do the sources disagree about?
- Are they describing different points in time or different levels of abstraction?
- Which source is more authoritative for the disputed type of information?
- What observed technical or operational evidence can test the competing claims?
- Who can validate the intended state versus the actual state?
- Does the conflict itself reveal a governance, ownership, or documentation problem?
- If the conflict cannot be resolved now, how should it be represented in the decision?
Recording Material Uncertainty That Cannot Yet Be Resolved
- What important fact or relationship remains unknown?
- Why can the uncertainty not be resolved with the evidence currently available?
- Which architecture decisions could be affected by it?
- What range of plausible conditions should we consider instead of assuming one answer?
- What decision can safely proceed despite the uncertainty?
- What trigger, investigation, or future evidence should resolve it?
- Who needs to know that this uncertainty remains open?
Determining How Much Evidence Confidence a Decision Requires
- How consequential is the decision if our understanding proves wrong?
- How reversible is the decision after implementation or contractual commitment?
- Which facts are most important to the outcome?
- What level of confidence do we currently have in those facts?
- What would it cost or delay to obtain stronger evidence?
- Is the residual uncertainty proportionate to the decision's consequence and reversibility?
- Which facts need human confirmation before commitment even if technical evidence appears strong?
- Which architecture information changes frequently enough to require regular refresh?
- Which information is structurally stable and can tolerate longer review intervals?
- What business or technical events should trigger an immediate update?
- Which records should carry explicit last-validated dates?
- How quickly does stale information become dangerous for the decisions it supports?
- Can freshness be derived automatically from authoritative operational sources?
- How should users be warned when architecture information has exceeded its reliable review interval?
Validating Important Architecture Assertions with Accountable Owners
- Which architecture assertions are important enough to require explicit owner validation?
- Who has enough authority and knowledge to validate each assertion?
- What evidence should accompany the assertion before asking for confirmation?
- Is the owner confirming intended architecture, actual operational reality, or both?
- What should happen when accountable owners disagree with observed evidence?
- How should validation status and date be recorded?
- When should the assertion be revalidated because conditions have materially changed?
Handling Architecture Decisions When the Available Sources Are Outdated or Incomplete
- Which missing or outdated information is relevant to the decision?
- What can we establish from alternative authoritative or observed sources?
- Which assumptions would we need to make if we proceed now?
- How sensitive is the decision to those assumptions?
- Can the decision be structured so that uncertain elements remain reversible?
- Is delaying the decision to improve the evidence justified by the consequence?
- What uncertainty should be explicitly presented to the final decision-maker?
Deciding When Further Investigation Is Worth the Delay
- What unresolved question could materially change the architecture decision?
- How likely is additional investigation to produce better evidence?
- What is the cost of delaying the decision?
- What is the cost of proceeding with the wrong assumption?
- Can we reduce uncertainty through a bounded experiment or reversible step instead?
- Are we seeking decision-relevant evidence or merely greater completeness?
- At what point would additional investigation no longer be expected to change the decision?
- What source supports each material architecture fact or relationship?
- When was the source last observed, reported, or validated?
- Who supplied or confirmed the information?
- Has a later update replaced the fact without preserving its previous basis?
- How should conflicting historical evidence be retained when it explains a past decision?
- Which transformations or aggregations make it difficult to trace repository information back to its source?
- What provenance information is necessary for future users to judge confidence without creating excessive maintenance burden?
Analyzing Cross-Enterprise Dependencies and Change Impact
Assessing the Enterprise Impact of a Proposed Architecture Change
- Which capabilities, applications, services, information domains, platforms, and technologies would this change affect?
- Which organizational units, products, or users depend on the affected architecture?
- What direct and indirect dependencies could transmit the effect beyond the initiating domain?
- Which existing initiatives or roadmaps interact with the proposed change?
- What enterprise risks, costs, or constraints could increase even if the local outcome improves?
- Which consequences are temporary transition effects and which would become permanent?
- What parts of the proposed change should be modified, sequenced, or escalated because of its wider impact?
Tracing Upstream and Downstream Dependencies Across Several Systems or Domains
- What does this system, service, or capability depend on upstream?
- Which downstream systems, services, processes, or users depend on it?
- Which dependencies cross domain or organizational boundaries?
- Are any important dependencies indirect enough that owners may not recognize them?
- Which dependencies involve data, identity, integration, infrastructure, suppliers, or operational processes?
- Which links are critical enough to affect sequencing or resilience decisions?
- Where is dependency evidence weak enough that further investigation is necessary?
Identifying Common-Mode Dependencies Hidden Behind Apparently Independent Services
- Which supposedly independent services rely on the same underlying platform, provider, region, network, identity service, or control plane?
- Are multiple suppliers themselves dependent on a common upstream provider?
- Do separate recovery arrangements rely on the same people, facilities, credentials, or communication channels?
- Which shared software libraries, runtime components, or data services create hidden coupling?
- Could one failure event disable several services that are currently treated as independent?
- Does the current resilience design account for these common-mode dependencies?
- What architectural changes would reduce the most consequential shared failure paths?
- Which business capabilities depend on this platform?
- Which applications, services, and teams consume it directly or indirectly?
- What happens if the platform is degraded rather than completely unavailable?
- Which business activities could continue through alternative mechanisms?
- How quickly would the loss become unacceptable for different consumers?
- What replacement, fallback, or migration options actually exist?
- Does the breadth of business impact justify stronger resilience, portability, or governance for the platform?
Testing Whether a Local Improvement Creates Costs or Risks Elsewhere
- What local benefit is the proposed change intended to create?
- Which costs or responsibilities would move to other teams or domains?
- Does the change create a new enterprise dependency, supplier, platform, data copy, or integration?
- Could the local simplification increase complexity in shared services or downstream systems?
- Does the proposal improve one risk while increasing another elsewhere?
- Who bears the long-term operating and change costs after the initiating team has delivered its objective?
- Would the proposal still look beneficial if evaluated against the whole enterprise rather than the local optimization boundary?
- Which known consumers still depend on the component proposed for retirement?
- What indirect dependencies exist through interfaces, data feeds, reports, batch jobs, identity, or operational processes?
- Are there seasonal, infrequent, or emergency uses that normal usage data might miss?
- What data, records, or regulatory obligations must survive after retirement?
- What replacement capability exists for every required dependency?
- Which dependent changes must occur before retirement is safe?
- What reversible shutdown or monitoring step can confirm that hidden consumers have not been missed?
Identifying Initiatives Whose Architecture Changes Interact
- Which active initiatives are changing the same applications, platforms, information domains, or integrations?
- Does one initiative depend on architecture another initiative is expected to deliver?
- Could two initiatives make incompatible decisions about a shared architecture component?
- Are several projects independently creating similar capabilities or platforms?
- Which sequencing conflicts could create rework or temporary complexity?
- Who has the cross-initiative authority to resolve architectural conflicts?
- What combined architectural view is needed before portfolio decisions are made?
Determining the Blast Radius of Changing an Enterprise Standard or Shared Capability
- Which systems, teams, and domains currently rely on the standard or shared capability?
- Would the change affect existing implementations or only future adoption?
- What migration work would consumers need to perform?
- Which contracts, supplier products, or external interfaces assume the current standard?
- Could the change unintentionally invalidate existing exceptions, patterns, or reference architectures?
- How much enterprise cost and disruption would the change create relative to its benefit?
- Should the change be immediate, phased, optional for existing consumers, or introduced through a new version?
Investigating Hidden Dependencies Before Making an Irreversible Commitment
- What architecture assumptions would become expensive to correct after this commitment?
- Which dependencies have been confirmed rather than merely assumed?
- What external suppliers, contracts, platforms, data sources, or shared services could constrain the decision later?
- Are there downstream consumers that the initiating team may not know about?
- What evidence exists from operational systems rather than only documentation?
- Which unresolved dependency could materially change the preferred option?
- What additional investigation is proportionate before we make the commitment irreversible?
Updating Enterprise Dependency Knowledge After Significant Change
- Which dependencies were added, removed, or materially altered by the change?
- Did any temporary migration dependency become part of the steady-state architecture?
- Which existing repository relationships are now incorrect?
- Did the change reveal previously undocumented upstream or downstream dependencies?
- Which owners need to validate the updated dependency information?
- What new concentration, coupling, or resilience concern became visible after implementation?
- How should the new dependency evidence influence future architecture, roadmap, or retirement decisions?
Representing and Communicating Architecture for Decisions
Choosing the Architecture Viewpoint Needed for a Particular Decision
- What decision does this architecture view need to support?
- Which stakeholders will use the view, and what concerns do they need to understand?
- Which architecture elements and relationships are material to the decision?
- What information can be omitted without hiding an important consequence?
- What level of abstraction will make the decision clearer rather than merely make the model more detailed?
- Do we need to show current state, target state, transition state, or a comparison between them?
- How can we test whether the chosen viewpoint actually helps stakeholders answer the decision question?
Explaining the Current Architecture to Senior Decision-Makers
- Which features of the current architecture materially affect the decision senior leaders need to make?
- What business capabilities, dependencies, risks, costs, or constraints should be visible at this level?
- Which technical details can be removed without distorting the architectural reality?
- Where does the current architecture create strategic options or limitations?
- Which weaknesses are established facts, and which remain uncertain or disputed?
- What consequences of keeping the current architecture should senior leaders understand?
- How can we explain the current state without turning the discussion into a technical inventory review?
Communicating Target Architecture to Product and Delivery Teams
- What parts of the target architecture directly constrain or enable this team's work?
- Which target-state elements are mandatory, and which allow local design variation?
- What architectural outcomes matter more than the exact implementation mechanism?
- Which shared platforms, interfaces, information standards, or dependencies must the team plan around?
- What transition assumptions should the team understand before committing to its design?
- Which decisions remain delegated to the team?
- How can the target architecture be expressed so that delivery teams can use it during everyday design decisions?
Representing Competing Architecture Options and Tradeoffs Clearly
- What are the materially different architecture options under consideration?
- Which decision criteria matter enough to compare across all options?
- What does each option improve, and what does it make worse?
- Which costs, risks, dependencies, and transition consequences differ between the options?
- Which assumptions make one option appear stronger than another?
- Where are tradeoffs being hidden by diagrams or terminology that make the options look more similar than they are?
- What representation would allow decision-makers to compare the options without implying a predetermined answer?
Showing Assumptions, Uncertainty, and Unresolved Questions in Architecture Material
- Which parts of this architecture are confirmed facts rather than assumptions?
- What important uncertainties could materially change the architecture direction?
- Which unresolved questions are being deferred rather than answered?
- What confidence should stakeholders place in different parts of the model?
- Which assumptions need owners, validation dates, or explicit review triggers?
- How can uncertainty be shown without making the architecture material unreadable?
- What would change in the architecture if the most important assumption proved false?
Making Cross-Domain Dependencies Understandable to Non-Specialists
- Which cross-domain dependencies matter to the decision being discussed?
- What business outcome or consequence makes each dependency important?
- Can the dependency be explained in terms of who relies on whom rather than technical implementation detail?
- Which dependencies create sequencing, concentration, resilience, or ownership concerns?
- Where would simplifying the explanation risk hiding an important architectural consequence?
- What visual or narrative representation would make the dependency chain easiest to understand?
- How can we confirm that non-specialists have understood the dependency rather than only the individual components?
Tailoring Architecture Views to Different Stakeholders Without Creating Contradictory Stories
- What does each stakeholder group genuinely need to understand about the architecture?
- Which underlying architecture facts must remain consistent across every view?
- Which details can legitimately differ because stakeholder concerns differ?
- Are any views describing different architecture states without making that distinction explicit?
- Where could simplification for one audience create a misleading impression when compared with another view?
- How can all stakeholder views be generated from or reconciled with the same underlying model?
- What should happen when two audience-specific views appear to imply different architecture decisions?
Avoiding Architecture Diagrams That Imply False Precision or Completeness
- Which elements in this diagram are actually known with sufficient confidence?
- Does the diagram imply that omitted elements or relationships do not exist?
- Are uncertain or inferred relationships being displayed as established facts?
- Does the visual notation make approximate boundaries look exact?
- Are current, planned, and target-state elements clearly distinguished?
- What caveats or supporting information are necessary for responsible interpretation?
- Would a simpler representation communicate the known architecture more accurately than a highly detailed diagram?
Keeping Multiple Architecture Views Consistent as the Underlying Model Changes
- Which architecture views depend on the elements or relationships being changed?
- Are the views generated from shared underlying information or maintained independently?
- Which views have become inconsistent with the current architecture model?
- What update should happen automatically when the underlying architecture changes?
- Who owns validating views that cannot be generated automatically?
- How can we identify contradictory representations before they influence a decision?
- Which obsolete views should be retired rather than continually reconciled?
Deciding Whether a Diagram, Model, Table, Narrative, or Combination Best Supports the Decision
- What does the audience need to understand or compare?
- Are relationships, quantities, sequences, responsibilities, or reasoning most important to the decision?
- Would a diagram clarify the structure or oversimplify important detail?
- Would a table make alternatives or attributes easier to compare?
- What reasoning or context requires narrative explanation rather than visual representation?
- Which combination of formats communicates the necessary evidence with the least cognitive burden?
- What information should be omitted because it does not contribute to the decision?
Establishing Architecture Principles, Standards, and Guardrails
Deciding Whether an Architecture Issue Needs a Principle, Standard, Guardrail, Policy, or Rule
- What behavior or decision are we actually trying to influence?
- Does the issue require directional guidance, a mandatory requirement, a bounded freedom, or a precise implementation constraint?
- Who has the authority to make the guidance mandatory if that is necessary?
- How much contextual judgment should teams retain when applying it?
- What would happen if different teams made different choices in this area?
- Is an existing policy, principle, standard, or guardrail already sufficient?
- Which form of guidance would achieve the intended consistency with the least unnecessary constraint?
Writing an Architecture Principle That Can Actually Guide Decisions
- What recurring architectural choice should this principle influence?
- What clear statement captures the intended direction without prescribing unnecessary implementation detail?
- Why does the enterprise benefit from following this principle?
- What practical implications should architects and teams derive from it?
- What tradeoffs or limitations does the principle intentionally accept?
- In what situations should the principle not apply or require interpretation?
- How could we test whether the principle changes real architecture decisions rather than merely sounding desirable?
Selecting an Architecture Decision Area for Enterprise Standardization
- What variation currently exists in this decision area?
- What enterprise costs, risks, or interoperability problems does that variation create?
- What benefits would greater consistency provide?
- What useful local variation would standardization remove?
- Is the decision repeated often enough for a standard to create meaningful value?
- Could a guardrail, pattern, or shared service solve the problem with less restriction?
- Does the expected enterprise benefit of standardization outweigh the loss of autonomy and migration cost?
Distinguishing Mandatory Requirements from Preferred Architectural Guidance
- Which parts of this guidance are genuinely non-negotiable?
- What authority or risk justifies making those elements mandatory?
- Which elements represent preferred practice rather than required conformance?
- What should teams be free to vary when context warrants it?
- How will people know whether a statement is mandatory, recommended, or illustrative?
- What happens when a preferred pattern conflicts with a local requirement?
- Are we labeling preferences as requirements because the governance model lacks another way to influence decisions?
Defining Guardrails That Allow Safe Local Autonomy
- Which decisions should teams be able to make without central approval?
- What boundaries must they remain within to protect enterprise concerns?
- Which outcomes or constraints matter more than prescribing a specific implementation?
- How can the guardrail be stated so teams can determine compliance themselves?
- Which parts of the guardrail can be automatically tested or enforced?
- What conditions should trigger escalation or an exception request?
- How will we know whether the guardrail is enabling autonomy without allowing harmful architectural drift?
Publishing a Standard with Clear Scope, Rationale, Ownership, and Lifecycle
- What exact decision or technology area does this standard cover?
- Where does the standard apply, and where does it not apply?
- Why has the enterprise chosen this standard?
- Which parts are mandatory, preferred, or context-dependent?
- Who owns the standard and is accountable for keeping it current?
- How are exceptions, versions, related patterns, and migration guidance handled?
- When and under what conditions should the standard be reviewed, deprecated, or retired?
Reviewing an Established Standard for Continued Fitness
- What problem was this standard originally intended to solve?
- Does that problem still exist in the same form?
- What evidence shows that the standard is producing the intended enterprise benefit?
- What legitimate exceptions or workarounds have emerged since it was introduced?
- Have technology, regulation, operating models, or business requirements changed enough to alter its usefulness?
- What cost or constraint does continued enforcement of the standard create?
- Should the standard remain unchanged, be revised, narrow its scope, become guidance, or be retired?
Using Repeated Exceptions as Evidence About the Quality of a Standard
- What types of exceptions are repeatedly being requested?
- Are the exceptions driven by genuine contextual differences or by weak compliance discipline?
- Do repeated exceptions cluster around a particular domain, technology, requirement, or operating condition?
- What benefits are teams gaining by departing from the standard?
- What risks or costs are those exceptions creating?
- Is the standard too broad, too restrictive, obsolete, or insufficiently supported by shared capabilities?
- What change to the standard or its implementation environment would reduce justified exceptions without weakening necessary control?
Deprecating and Retiring an Architecture Standard
- What evidence shows that the standard should no longer guide new decisions?
- Should new use stop immediately or after a defined transition period?
- Which existing systems or teams still depend on the standard?
- What replacement standard, pattern, or direction should apply to future decisions?
- What migration expectations should apply to existing implementations?
- How should active exceptions and related reference architectures be handled?
- What condition will indicate that the standard can be considered fully retired rather than merely deprecated?
Resolving Conflicts Between Architecture Principles, Standards, or Policies
- Which requirements or guidance are actually in conflict?
- Do the conflicting sources have different levels of authority?
- Are they intended for different scopes or contexts that have been incorrectly combined?
- What enterprise outcomes or risks was each rule designed to protect?
- Can the conflict be resolved through clearer applicability or precedence?
- What tradeoff remains if both requirements cannot be satisfied simultaneously?
- Who has authority to resolve the conflict and update the governing guidance so it does not recur?
Developing Reference Architectures and Reusable Patterns
Identifying a Recurring Architecture Problem Worth Solving Reusably
- How often does this architecture problem recur across teams or domains?
- Are teams currently solving substantially the same problem in different ways?
- What costs, risks, or delays result from repeatedly designing the solution from scratch?
- Which parts of the problem are genuinely common across contexts?
- Which parts vary enough that a reusable solution could become misleading?
- Would a reference architecture, design pattern, standard, shared platform, or simple guidance best address the recurrence?
- What evidence would justify investing in a reusable architectural solution?
Defining the Scope and Purpose of a Reference Architecture
- What recurring problem is this reference architecture intended to address?
- Which business or technical contexts are within its scope?
- Which architecture concerns does it deliberately leave to local design?
- What outcomes should implementations derived from it achieve?
- Which components, relationships, and constraints are essential to its architectural intent?
- Which assumptions must be true for the reference architecture to remain appropriate?
- How will teams know when they should use this reference architecture and when they should not?
Separating Required Elements from Legitimate Variation Points
- Which elements are essential to achieving the intended architecture outcomes?
- Which constraints must remain consistent across implementations?
- Where can teams choose different technologies, products, or structures without undermining the reference architecture?
- What context should influence each variation point?
- Are any implementation examples being mistaken for mandatory architecture?
- Which variations would require an exception rather than ordinary adaptation?
- How can the reference architecture communicate required elements and variation points unambiguously?
Adapting a Reference Architecture to a Different Domain or Operating Context
- Which assumptions of the reference architecture hold in this domain?
- Which business, regulatory, scale, resilience, or data requirements are materially different?
- Which required elements should remain unchanged despite the contextual differences?
- Which variation points can accommodate the new context?
- What adaptations would change the architecture so substantially that it should no longer be treated as the same reference architecture?
- What new risks or dependencies arise from the adaptation?
- What learning from this adaptation should feed back into the reference architecture for future users?
Choosing Between Alternative Architecture Patterns for the Same Problem
- What context and requirements does each pattern assume?
- Which quality attributes does each pattern optimize?
- What dependencies, complexity, and operating burden does each pattern introduce?
- How do the patterns differ in scalability, resilience, security, coupling, and changeability?
- What skills and platform capabilities does each pattern require?
- Which tradeoffs are most relevant to the situation we are addressing?
- What evidence from previous implementations supports choosing one pattern over the alternatives?
Validating a Pattern Through Real Implementation Experience
- Where has this pattern been implemented in a comparable context?
- Did the implementation achieve the architectural outcomes the pattern promised?
- What unexpected costs, constraints, or failure modes emerged?
- Which assumptions held and which proved incorrect?
- What local modifications were necessary during implementation?
- Did the pattern remain understandable and usable by delivery teams?
- What should be changed in the pattern before it is recommended more broadly?
Preventing a Reference Architecture from Becoming a Rigid Universal Template
- Which contexts was the reference architecture actually designed for?
- Where are teams applying it despite materially different requirements?
- Which parts are architectural intent and which are merely example implementations?
- Are teams requesting exceptions because legitimate variation was not designed into the reference architecture?
- What evidence would justify allowing a different pattern or architecture entirely?
- Has organizational convenience turned a reference model into an unofficial mandatory standard?
- How should the guidance make its limits and alternative paths clearer?
Updating a Reference Architecture When Technology or Requirements Change
- Which assumptions behind the current reference architecture have changed?
- What new technology or requirement materially affects its structure?
- Which parts remain valid and should be preserved?
- What implementation experience indicates that the current architecture needs revision?
- Would the update break existing implementations or only affect future adoption?
- Should the reference architecture be versioned rather than silently replaced?
- What related standards, patterns, documentation, and roadmaps must change with it?
Retiring a Pattern or Reference Architecture That No Longer Fits
- What evidence shows that this pattern or reference architecture is no longer useful?
- Has its underlying problem disappeared or changed materially?
- Are teams routinely choosing better alternatives?
- Does continued use create risk, complexity, lock-in, or unnecessary constraint?
- What should teams use instead for new implementations?
- What happens to existing implementations that still follow the retired guidance?
- What historical rationale should be retained after the pattern or reference architecture is withdrawn?
Making Reusable Architecture Easy for Teams to Discover and Apply
- Where do teams currently look for approved patterns and reference architectures?
- Can users tell which guidance applies to their problem and context?
- Is the material written at a level that delivery teams can act on?
- Are required elements, options, examples, and limitations easy to distinguish?
- Can teams find implementation examples or reusable platform capabilities linked to the guidance?
- How can feedback from users be captured when the guidance is difficult to apply?
- What obsolete or duplicate reusable architecture should be removed to improve discoverability?
Developing Architecture Vision and Target Architectures
Establishing an Architecture Vision for a Significant Change
- What business or strategic change is the architecture vision intended to enable?
- What is materially wrong or insufficient about the current architecture?
- What should be meaningfully different in the future state?
- Which capabilities, information, applications, platforms, or relationships are central to the vision?
- What principles or constraints should guide later target architecture development?
- What major outcomes should stakeholders be able to understand before detailed architecture begins?
- What uncertainty should remain explicit rather than being hidden behind a prematurely detailed vision?
Deriving a Target Architecture from Strategic, Capability, Operational, and Regulatory Requirements
- Which strategic outcomes must the target architecture enable?
- What capability levels must the enterprise achieve?
- What operational requirements must the architecture satisfy in steady state?
- Which regulatory, policy, security, privacy, or sovereignty constraints are mandatory?
- What existing architecture constraints or commitments must the target account for?
- Which target-state elements can be traced directly to these requirements?
- Are any proposed target elements present mainly because of technology preference rather than an established requirement?
Defining the Scope and Time Horizon of a Target Architecture
- What decision or transformation does this target architecture need to guide?
- Which parts of the enterprise should the target explicitly cover?
- What should remain outside the target because it is unrelated or insufficiently understood?
- What time horizon is realistic for the target state?
- Which assumptions become less reliable as the time horizon extends?
- What level of detail is appropriate for the near term versus the distant future?
- When should the target architecture be revisited rather than treated as a fixed end state?
- What business capabilities and services must the target architecture support?
- What information domains, ownership, and sharing relationships are required?
- What application and service structure should enable the business capabilities?
- What shared platforms and technologies should underpin the target?
- Which integrations and cross-domain dependencies are essential?
- How do the business, information, application, and technology layers constrain one another?
- Does the proposed target form a coherent enterprise architecture rather than four independently designed layers?
Choosing How Specific a Target Architecture Should Be at Different Time Horizons
- Which near-term decisions require concrete architectural specificity?
- Which distant decisions can safely remain directional?
- What elements must be fixed early because later change would be expensive or disruptive?
- Which technology choices are likely to become obsolete before the long-term horizon is reached?
- What capability, principle, dependency, or boundary can be specified without choosing an implementation prematurely?
- Where should the target preserve multiple viable options?
- How can the target become more specific over time without creating apparent contradiction with earlier versions?
Tracing Major Target Architecture Elements Back to Their Requirements
- What requirement or constraint justifies each major target-state element?
- Which target elements support multiple requirements or capabilities?
- Are any requirements not represented in the target architecture?
- Are any major architectural elements unsupported by an explicit need?
- Which assumptions connect the requirement to the proposed architectural response?
- How would the target change if a major requirement were removed or altered?
- How should this traceability be maintained as requirements and architecture evolve?
Reconciling Conflicting Target Architecture Directions Across Domains
- Which domain target architectures are in conflict?
- What requirements or assumptions are driving the different directions?
- Does one domain's preferred target create cost, coupling, or constraint for another?
- Which enterprise principles or strategic priorities should guide the resolution?
- Can common foundations be standardized while allowing legitimate domain variation?
- What tradeoff remains after architectural alternatives have been explored?
- Who should decide when the conflict reflects a business choice rather than an architecture judgment?
Representing Assumptions, Options, and Unknowns in the Target Architecture
- Which parts of the target architecture are committed decisions?
- Which elements are directional rather than final?
- What assumptions does the target depend on?
- Which architecture options remain deliberately open?
- What important unknowns could materially change the target?
- What decision points or triggers will resolve the remaining options and unknowns?
- How can the representation prevent stakeholders from mistaking provisional elements for committed architecture?
Aligning Domain Target Architectures into a Coherent Enterprise Direction
- Where do domain target architectures share capabilities, information, platforms, or technologies?
- Are different domains assuming incompatible enterprise foundations?
- Which duplicate target capabilities or platforms should be reconciled?
- Where should enterprise standards or reference architectures create consistency?
- Which domain-specific differences are legitimate and should remain?
- What cross-domain dependencies must be reflected in each roadmap?
- Does the combined target architecture form a viable enterprise state rather than a collection of locally optimized futures?
Reopening a Target Architecture When Its Founding Conditions Materially Change
- Which assumption, requirement, or constraint underlying the target architecture has changed?
- Would the new condition have materially affected the original target decision?
- Which parts of the target remain valid despite the change?
- What investments or commitments have already been made against the current target?
- What is the cost and consequence of retaining the existing target versus revising it?
- Does the change require a local adjustment or a fundamental redesign?
- How should the revised target and the reason for reopening it be communicated to affected teams?
Evaluating Architecture Options and Tradeoffs
Developing Materially Different Architecture Options Before Selecting a Direction
- What distinct architectural approaches could satisfy the core requirements?
- Are the options genuinely different or merely variations of the same preferred solution?
- What assumptions does each option make?
- Which architecture boundaries, dependencies, technologies, or operating models differ between the options?
- What option would we consider if the currently preferred technology or supplier were unavailable?
- Have we included options that reuse or simplify existing architecture rather than always introducing something new?
- What minimum set of alternatives is sufficient to expose the important tradeoffs before selection?
Eliminating Architecture Options That Fail Mandatory Requirements
- Which requirements are genuinely mandatory for every viable option?
- Which architecture options fail one or more of those requirements?
- Is the failure inherent to the option or correctable through modification?
- Are we treating a preference or existing standard as mandatory when an exception could be justified?
- Does an option meet the stated requirement but undermine its underlying purpose?
- What evidence supports excluding the option from further consideration?
- Should any rejected option be retained as a contingency if the mandatory requirement later changes?
Comparing Architecture Options Across Value, Risk, Cost, and Changeability
- What business or capability value does each option enable?
- What material risks does each option create, reduce, or transfer?
- What whole-lifecycle costs differ between the options?
- How easily can each architecture adapt to future requirements?
- What dependencies and operational burdens does each option introduce?
- Which comparison factors are based on evidence and which remain uncertain?
- How do the options compare without collapsing materially different criteria into a misleading single score?
Evaluating the Target State and Transition Path Together
- How attractive is each target architecture when its migration path is included?
- What temporary architecture is required to reach each target?
- Which option creates the greatest coexistence, sequencing, or migration burden?
- What risks arise during transition that are absent from the final target state?
- How long would the enterprise need to operate in intermediate states?
- Does an elegant target depend on a transition that is financially, operationally, or organizationally unrealistic?
- Which option provides the best combination of viable destination and manageable path?
Making the Accepted Downsides of an Architecture Choice Explicit
- What disadvantages are we knowingly accepting with the preferred architecture?
- Which stakeholders bear those downsides?
- What risks or constraints remain after mitigation?
- Which rejected option performed better on those dimensions?
- Why are the accepted disadvantages justified by the overall decision?
- Under what future conditions would the accepted downside become unacceptable?
- How should the tradeoff be recorded so later teams do not mistake the consequence for an accidental design flaw?
Balancing Enterprise Standardization Against Local Autonomy
- What enterprise benefit would greater standardization create in this area?
- What legitimate local needs would standardization constrain?
- Which architectural layers genuinely need consistency across domains?
- Where can teams vary implementation while still meeting shared contracts or outcomes?
- What cost or risk does current variation create?
- What cost or loss of differentiation would stronger standardization create?
- What boundary between common enterprise foundations and local autonomy produces the best overall result?
- What duplication, cost, or inconsistency would platform consolidation remove?
- How many critical capabilities would become dependent on the consolidated platform?
- What common-mode failure or operational blast radius would consolidation create?
- How difficult would it be to replace or recover the consolidated platform?
- What supplier or commercial concentration would result?
- Which layers can be consolidated without creating unacceptable dependency concentration?
- What resilience, portability, or fallback measures are proportionate to the benefits of consolidation?
- Does an existing enterprise capability already meet the need well enough to reuse?
- What would a commercial solution provide that internal development would not?
- What strategic advantage, control, or differentiation would justify building?
- Could a shared platform solve the need for several domains rather than only the initiating team?
- What integration, operating, supplier, and lifecycle burden accompanies each option?
- How do the options differ in time to value, flexibility, lock-in, and total enterprise cost?
- Which choice remains strongest when impacts outside the initiating domain are included?
Preserving Future Options When Important Uncertainty Remains
- What important uncertainty makes an irreversible decision risky today?
- Which architectural choices would close off future alternatives?
- What decisions can safely be deferred without blocking current progress?
- Can interfaces, modular boundaries, portability, or staged commitments preserve multiple options?
- What cost are we willing to pay now to retain future flexibility?
- Which future options are genuinely plausible rather than merely theoretical?
- What event or evidence should trigger a later commitment among the preserved alternatives?
Recording Why an Architecture Option Was Selected and Why Alternatives Were Rejected
- What problem and requirements were the architecture options evaluated against?
- Which alternatives were seriously considered?
- What evidence and assumptions informed the comparison?
- What tradeoffs led to the selected option?
- Why were the main alternatives rejected?
- What downsides and residual risks were accepted with the selected option?
- Under what future conditions should this decision be reconsidered?
Designing Transition Architectures and Architecture Roadmaps
Determining Whether a Major Change Needs an Explicit Transition Architecture
- Can the enterprise move directly from the current state to the target state without an extended intermediate operating condition?
- Which systems, capabilities, data, platforms, or organizations must coexist during the change?
- Will the transition create temporary interfaces, duplicated capabilities, or split sources of authority?
- How long is the intermediate state likely to remain in operation?
- What business, security, regulatory, or resilience risks arise specifically during the transition?
- Would treating the transition only as a project plan leave important architectural decisions unresolved?
- What evidence would justify managing the intermediate state as an explicit transition architecture?
- What must continue functioning while the enterprise is between the current and target states?
- Which old and new architecture elements need to coexist in this intermediate state?
- Which system or source is authoritative for each important capability or information domain during coexistence?
- What temporary integrations, controls, or operating arrangements are required?
- What resilience, security, support, and recovery requirements must the intermediate architecture meet?
- What risks arise if the intermediate state lasts substantially longer than planned?
- What conditions must be true before the enterprise can safely move from this intermediate state to the next one?
Sequencing Architecture Changes Around Hard and Enabling Dependencies
- Which architecture changes cannot begin until another change is complete?
- Which enabling capabilities should be delivered early because several later changes depend on them?
- Which dependencies are technical, informational, contractual, operational, regulatory, or organizational?
- What sequence minimizes rework and unnecessary temporary architecture?
- Which changes can proceed independently without increasing transition risk?
- Where would changing the sequence create a materially faster or safer path to value?
- What dependency assumptions should be monitored because their failure would require resequencing the roadmap?
Managing Temporary Duplication and Coexistence During Transition
- Which capabilities, applications, platforms, or data stores need to exist in parallel temporarily?
- Why is the duplication necessary rather than avoidable?
- Which version or system is authoritative for each function or data set during coexistence?
- What synchronization, reconciliation, or operational controls are required between the duplicate environments?
- What cost, risk, and support burden does the temporary duplication create?
- How long can coexistence continue before its temporary architecture becomes an unacceptable permanent condition?
- What explicit exit condition will allow one side of the duplication to be retired?
Grouping Architecture Changes into Realistic Migration Waves
- Which systems or capabilities need to move together because of hard dependencies?
- Which changes should be separated to reduce operational or migration risk?
- What business calendars, release windows, regulatory deadlines, or operational constraints affect wave design?
- Which foundational platforms or services must be ready before later waves begin?
- How should complexity, readiness, and organizational capacity influence the size of each wave?
- What temporary architecture is created between successive waves?
- What evidence from completed waves should be used to adjust the composition or sequence of later waves?
Linking Roadmap Items to Capability and Architecture Outcomes
- What capability or business outcome is each roadmap item intended to enable?
- What architecture element or relationship will materially change when the item is completed?
- Which roadmap items exist primarily to remove risk, debt, or obsolete architecture rather than add new capability?
- Are any roadmap items present without a clear architecture or capability outcome?
- Which outcomes depend on several roadmap items being completed together?
- What evidence would show that the intended architectural outcome has actually been achieved?
- How should roadmap items change if the underlying capability need or target architecture changes?
Incorporating Contract, End-of-Support, Regulatory, and Operational Deadlines into the Roadmap
- Which external deadlines constrain the architecture transition?
- What contracts expire, renew, or become materially more expensive during the roadmap period?
- Which technologies or products reach end of support before the target state is expected?
- What regulatory or policy dates require architectural change by a fixed point?
- Which operational windows limit when migrations or cutovers can occur?
- What earlier enabling work is necessary to meet each non-negotiable deadline safely?
- Where do conflicting deadlines require a deliberate tradeoff or escalation?
Defining Exit Conditions for Temporary Transition Components
- What specific purpose does this temporary component serve?
- Which dependency prevents it from being removed today?
- What event or capability must exist before retirement becomes possible?
- Who owns the responsibility for removing the temporary component?
- What evidence will confirm that consumers no longer depend on it?
- What happens if the expected exit condition is delayed or never occurs?
- At what point should continued use trigger a new architecture decision rather than another informal extension?
Adjusting the Architecture Roadmap When Funding, Dependencies, or Evidence Change
- What assumption or condition underlying the current roadmap has changed?
- Which roadmap items are directly affected by the change?
- What downstream sequencing or dependency consequences follow?
- Which target outcomes remain mandatory despite the changed conditions?
- What can be delayed, resequenced, simplified, or removed without undermining the architecture direction?
- Does the change reveal that the target architecture itself needs reconsideration rather than only the roadmap?
- How should the revised roadmap and its consequences be communicated to investment and delivery stakeholders?
- Which investments are prerequisites for other architecture changes?
- Which roadmap items create shared enterprise capabilities that several initiatives depend on?
- What investments should be sequenced differently because of architecture dependencies?
- Which proposed investments duplicate or conflict with the roadmap direction?
- What legacy costs or risks continue if a roadmap item is not funded?
- Which investments create irreversible commitments that should wait until key uncertainty is reduced?
- What portfolio decision would change if architecture dependencies and transition consequences were considered explicitly?
Defining Enterprise Information Domains and Major Business Concepts
- What major business concepts does the enterprise need to manage consistently enough for cross-domain decisions and interactions?
- Which concepts naturally belong together because they share meaning, ownership, rules, or lifecycle?
- Where are information domains currently being defined by systems or organizational charts rather than business meaning?
- Which domain boundaries reduce ambiguity without forcing unrelated information into one model?
- What relationships between information domains are important enough to represent explicitly?
- Where do overlapping domain definitions create unclear responsibility or duplicated data?
- What evidence would justify changing an established information-domain boundary?
Establishing Authoritative Ownership for Information Shared Across Domains
- Which information requires an authoritative business owner because several domains depend on it?
- Who has the authority to define the meaning and acceptable use of that information?
- Who is responsible for stewardship, technical custody, and system operation without owning the business meaning?
- Where do several functions currently claim authority over the same information?
- What decisions require a clearly identified authoritative source?
- How should ownership work when information is legitimately created or maintained by more than one domain?
- What escalation path is needed when domains cannot agree on ownership or authority?
Resolving Conflicting Definitions of a Shared Business Concept
- What different meanings are currently being assigned to the same business term?
- Are the differences genuine contextual distinctions or inconsistent definitions of one shared concept?
- Which business processes and decisions depend on each definition?
- Does the enterprise need one common definition, explicit qualified definitions, or mappings between different concepts?
- What identifiers or classification schemes are affected by the semantic conflict?
- What would be disrupted if one definition were imposed universally?
- How should the agreed semantic relationship be represented so future systems do not recreate the conflict?
Deciding Which Semantics, Identifiers, and Classifications Need Enterprise Consistency
- Which concepts must be understood consistently across several domains?
- Where do inconsistent identifiers prevent reliable integration, reporting, or customer or entity recognition?
- Which classifications need common meaning because they drive policy, regulation, analytics, or automation?
- Where would enterprise standardization erase legitimate domain-specific distinctions?
- Can interoperability be achieved through mapping rather than universal standardization?
- What governance is necessary to keep shared semantics and identifiers stable over time?
- What is the minimum level of consistency required for the enterprise use case?
Choosing Whether Important Data Should Be Centralized, Shared, Replicated, Federated, or Kept Local
- Who needs to use the data, and for what purposes?
- Where should authoritative control of the data remain?
- What consistency and latency requirements apply across consumers?
- What privacy, sovereignty, security, or regulatory constraints affect placement and movement?
- What availability or resilience requirements argue for replication or distribution?
- What operational complexity and synchronization risk would each topology introduce?
- Which architecture best balances shared use with appropriate domain autonomy and control?
Establishing the Enterprise Role of Master Data and Reference Data
- Which business entities require consistent identity or core attributes across several domains?
- Which code sets or classifications need common reference values?
- What problems are currently caused by multiple competing versions of the same master or reference data?
- Which source or process should determine authoritative values?
- What information should remain domain-specific rather than being absorbed into enterprise master data?
- How should changes to master and reference data propagate to dependent systems?
- What governance and lifecycle controls are necessary to prevent the shared data from becoming another inconsistent copy?
Defining Data Product and Domain Boundaries for Enterprise Reuse
- What business information is this data product intended to make reusable?
- Which domain has the knowledge and authority to own it?
- Who are the intended consumers, and what do they need from the product?
- What interface, semantic, quality, metadata, and lifecycle commitments should the product provide?
- What information should remain internal to the domain rather than being exposed as a shared product?
- How will changes be versioned or communicated so consumers can evolve independently?
- When does a proposed data product duplicate another enterprise data source or create unnecessary coupling?
- Where does this critical information originate?
- Which systems, transformations, and intermediate stores modify it before it reaches important consumers?
- Which steps change the meaning, structure, aggregation, or quality of the information?
- What downstream decisions or services depend on the resulting data?
- Where are lineage links uncertain, undocumented, or dependent on manual processes?
- Which transformations create material privacy, regulatory, or audit implications?
- What level of lineage detail is necessary for the enterprise decision without attempting to model every field?
Applying Privacy, Sovereignty, Security, Retention, and Regulatory Constraints to Data Architecture
- Which legal, regulatory, privacy, security, or sovereignty requirements apply to this information?
- Where may the data be stored, processed, transferred, or accessed?
- What purposes are permitted for collecting and using the data?
- How long must or may the information be retained?
- Which copies, replicas, analytical stores, backups, or derived data are subject to the same constraints?
- What architectural options become unavailable because of these requirements?
- How can the architecture satisfy the constraints without creating unnecessary duplication or preventing legitimate reuse?
- Which information must be discoverable and reusable for analytics, automation, or AI use cases?
- Are important concepts and identifiers consistent enough to combine data across domains?
- Can users determine the origin, lineage, ownership, and permitted use of relevant data?
- What quality information is available to judge whether the data is fit for a particular analytical or AI use?
- Are access, privacy, security, and retention rules machine-readable or operationally enforceable?
- How will data products and interfaces evolve without silently breaking downstream analytical or AI consumers?
- Which information architecture weaknesses should be addressed before investing heavily in new analytics or AI capabilities?
Managing Application and Service Architecture
Designing the Application and Service Landscape for a New or Significantly Changed Business Domain
- What capabilities and business services must the new landscape support?
- Which functions belong together within the same application or service boundary?
- What existing enterprise applications or shared services can be reused?
- Which information domains and external services must the landscape interact with?
- Where should responsibilities be separated to support independent change and clear ownership?
- What shared platforms or standards should constrain the design?
- How can the landscape avoid creating unnecessary applications, interfaces, or long-term coupling?
Defining Appropriate Boundaries Between Applications, Services, and Domains
- What business responsibility should each application or service own?
- Which data and behavior should remain inside that boundary?
- Where do current boundaries force unrelated concerns to change together?
- Where have boundaries become so fragmented that coordination and integration dominate delivery effort?
- Which business-domain boundaries provide useful guidance for application and service ownership?
- What interfaces are necessary for independently owned areas to collaborate?
- How would the proposed boundaries affect future changeability, ownership, and operational responsibility?
Deciding Whether a Capability Should Use a Shared Service or a Domain-Specific Solution
- How common is the underlying need across different domains?
- Would a shared service create meaningful economies of scale, consistency, or reuse?
- What domain-specific requirements would a shared service struggle to satisfy?
- How much coupling would consumers acquire to the shared service?
- Can a shared foundation support local extensions without becoming a lowest-common-denominator solution?
- What operating model and service ownership are needed for a shared service to remain responsive to consumers?
- Which option creates the better enterprise outcome after both local fit and shared dependency are considered?
Defining Ownership for Applications and Services Shared Across Multiple Business Domains
- Who should own the shared application or service as an enterprise capability?
- Which domains are consumers rather than owners?
- Who has authority over its roadmap, interfaces, service levels, and lifecycle?
- How should competing priorities from different consuming domains be resolved?
- Who funds shared maintenance and major change?
- What decisions remain with the platform or service team versus enterprise architecture or business leadership?
- How should ownership change if one domain becomes disproportionately dependent on or responsible for the service?
Assessing the Architectural Fit of a Proposed New Application or Service
- What capability or business need does the proposed application or service address?
- Does an existing enterprise capability already satisfy the need sufficiently?
- How does the proposal fit the intended application and service architecture?
- What new data, integration, platform, supplier, or operational dependencies would it create?
- Does it conform to relevant standards and reference architectures?
- What duplication, coupling, or future retirement difficulty could result from adoption?
- Would the enterprise still consider the proposal attractive after its full lifecycle and cross-domain consequences are included?
Establishing Enterprise Principles for Application Modularity and Coupling
- What kinds of application dependencies are creating the greatest enterprise change friction?
- Which responsibilities should be isolated so they can evolve independently?
- What forms of coupling are acceptable because the underlying business responsibilities genuinely belong together?
- Which interfaces or contracts need greater stability across applications?
- Where would excessive decomposition create unnecessary operational and integration complexity?
- What principles can guide modularity without prescribing one technical architecture everywhere?
- How will we know whether the resulting application landscape is becoming easier rather than harder to change?
Managing the Dependencies Created by a Widely Shared Service
- Which capabilities and applications depend on the shared service?
- How critical is the service to each consumer?
- What changes to the service could create widespread downstream impact?
- How should interfaces, versions, service levels, and deprecation be governed?
- What resilience and recovery expectations are justified by its enterprise dependency footprint?
- What alternatives or fallback options exist if the shared service is unavailable or must be replaced?
- At what point does the value of sharing become outweighed by concentration, coupling, or delivery constraints?
Revising Application and Service Boundaries as Business Domains Change
- Which business-domain boundaries have materially changed?
- Which current application boundaries still reflect an organizational structure that no longer exists?
- Where have new capabilities or responsibilities crossed old application boundaries?
- What ownership conflicts or duplicated functions have emerged?
- Which applications should be split, combined, or repositioned to match the changed domain structure?
- What migration and integration consequences would boundary changes create?
- How can boundaries be revised without coupling the architecture too tightly to another potentially temporary reorganization?
Planning the Architectural Replacement of a Major Application or Service
- What business capabilities and dependencies does the existing application support?
- Which parts of its functionality should be retained, replaced, consolidated, or eliminated?
- What target application or service boundaries should replace the current structure?
- How will data, integrations, users, and downstream consumers migrate?
- What coexistence or temporary interfaces will be required during replacement?
- What conditions must be met before the existing application can be safely retired?
- How will the replacement avoid reproducing the architectural weaknesses of the system it replaces?
Keeping the Application and Service Landscape Coherent Across Decentralized Teams
- Which application and service decisions can decentralized teams make autonomously?
- What enterprise boundaries, standards, or shared capabilities should constrain local choices?
- Where are teams independently creating overlapping applications or services?
- How can shared application and service knowledge remain visible across domains?
- What cross-team dependencies require coordination before local changes proceed?
- When should a local architecture decision escalate because it creates enterprise precedent or shared dependency?
- How can enterprise coherence be maintained without requiring central approval for every application decision?
Managing Integration and Interoperability Architecture
Choosing an Integration Style for a Cross-System Need
- What interaction is required between the participating systems?
- Does the interaction need synchronous response, asynchronous delivery, event notification, bulk transfer, or shared access?
- What consistency, latency, availability, and reliability requirements apply?
- How independently do the participating systems need to evolve?
- What coupling does each integration style introduce?
- What enterprise integration capabilities or standards already exist?
- Which style best satisfies the need without creating unnecessary dependency or operational complexity?
Standardizing Interaction Contracts Without Standardizing Internal Implementations
- What information and behavior must systems agree on to interoperate reliably?
- Which parts of the interaction contract require enterprise consistency?
- What internal implementation choices can safely remain local?
- How should schemas, semantics, identifiers, error behavior, and service expectations be defined?
- What compatibility obligations should providers maintain for consumers?
- How can the contract evolve without forcing coordinated internal redesign across all participants?
- Are we standardizing only the boundary, or unintentionally dictating internal system architecture as well?
Establishing Enterprise Governance for APIs
- Which APIs need enterprise visibility because they are shared or strategically important?
- Who owns each API's purpose, contract, lifecycle, and consumer relationships?
- What minimum standards should apply to security, versioning, documentation, observability, and reliability?
- How should duplicate APIs exposing the same capability or data be identified and resolved?
- What discoverability mechanisms should help teams find existing APIs before creating new ones?
- How should breaking changes and deprecations be governed?
- Which API decisions should remain with individual teams and which require enterprise coordination?
Establishing Enterprise Governance for Events and Messaging
- Which business events require stable meaning across several systems or domains?
- Who owns the definition and lifecycle of each shared event?
- What messaging technologies or shared infrastructure need enterprise standardization?
- How should event schemas, identifiers, ordering, delivery guarantees, and versioning be governed?
- What risks arise when many consumers depend on an event the producer does not know about?
- How should sensitive or regulated information be handled in event-driven interactions?
- What evidence would show that event governance is enabling loose coupling rather than creating another centralized bottleneck?
Resolving Semantic Mismatches Between Systems That Must Interoperate
- Which concepts are represented differently by the participating systems?
- Are the differences accidental inconsistency or legitimate domain-specific meaning?
- Which system or domain has authority for each concept?
- Can mappings preserve distinct meanings without forcing one universal model?
- Where would a canonical representation reduce repeated translation?
- What information could be lost or distorted during transformation?
- How should mappings and semantic decisions be governed as the systems evolve?
Reducing Uncontrolled Point-to-Point Integration
- Where has point-to-point integration created significant coupling or operational burden?
- Which interfaces are duplicated across several system pairs?
- What business interactions justify direct integration despite the general complexity concern?
- Could shared APIs, events, messaging, or integration services reduce repeated custom connections?
- What migration path would reduce coupling without replacing functioning integrations unnecessarily?
- Which integrations should be removed when applications are rationalized?
- How will we verify that a new integration approach actually reduces complexity rather than adding another layer beside the old one?
- How many domains or systems have recurring integration needs that could share common capability?
- What duplication or operational burden would a shared platform remove?
- Which protocols, transformations, routing, security, or observability capabilities are genuinely common?
- What coupling or central dependency would the platform introduce?
- Can the platform support heterogeneous consumers without forcing every interaction into one pattern?
- What product ownership and service model would keep the platform responsive to its users?
- Would standardized contracts and decentralized tooling solve the problem without introducing a shared runtime platform?
Managing Interface Versioning and Backward Compatibility Across Consumers
- Which consumers depend on the current interface version?
- What change requires a new version rather than a compatible extension?
- How long should older versions remain supported?
- What evidence confirms that consumers have migrated before deprecation?
- How should breaking changes and migration deadlines be communicated?
- What cost and complexity arise from supporting too many versions simultaneously?
- When is coordinated migration preferable to indefinite backward compatibility?
Making Enterprise Interfaces Discoverable, Owned, and Reusable
- Where can teams discover existing APIs, events, messages, and other enterprise interfaces?
- Does each interface have a clearly identified owner?
- Is its purpose and intended consumer context understandable?
- Can users determine whether the interface is active, supported, deprecated, or experimental?
- What documentation and examples are necessary for responsible reuse?
- How should duplicate or overlapping interfaces be detected?
- What feedback mechanism helps owners improve interfaces based on consumer experience?
Retiring an Integration Without Breaking Hidden Consumers
- Which known systems or processes consume the integration?
- What operational evidence can reveal consumers that are not documented?
- Are there seasonal, batch, emergency, or infrequent consumers that recent usage data might miss?
- What replacement interaction will each required consumer use?
- How should deprecation and shutdown dates be communicated?
- Can the integration be disabled reversibly before permanent removal?
- What evidence will confirm that retirement has not broken an unknown dependency?
Deciding Which Technology Choices Require Enterprise Coordination
- Does this technology choice affect more than one team, product, domain, or business unit?
- Would adoption create a long-lived enterprise dependency or significant switching cost?
- Does the technology affect interoperability, identity, security, data, resilience, or shared operations?
- Would widespread independent selection create unnecessary skills, support, or tooling diversity?
- Is the choice easily reversible if local adoption proves unsuccessful?
- Can the decision remain local within existing standards and guardrails?
- What consequence or scale threshold should trigger enterprise-level coordination?
- What common capability should the platform provide?
- Which responsibilities belong inside the platform rather than with consuming teams?
- What interfaces separate platform ownership from workload or domain ownership?
- Which concerns should remain local because they depend on domain-specific requirements?
- Does the proposed platform boundary reduce repeated complexity or merely centralize it?
- What dependencies will consumers acquire on the platform?
- How should the boundary evolve as usage grows without allowing the platform to absorb unrelated responsibilities?
Choosing Between Cloud, SaaS, Managed Service, On-Premises, Edge, and Hybrid Deployment
- What business and operational requirements drive the deployment decision?
- What control, data locality, sovereignty, or regulatory constraints apply?
- What latency, connectivity, or disconnected-operation requirements exist?
- Which option provides the required resilience and recovery characteristics?
- What operational responsibility and skills would each deployment model require?
- What supplier dependence, portability, and exit difficulty would each option create?
- Which deployment model provides the best whole-lifecycle fit rather than simply following an enterprise technology preference?
Establishing Shared Enterprise Foundations for Identity, Connectivity, Management, and Observability
- Which foundational capabilities should every workload be able to rely on?
- Where would separate implementations create unnecessary cost, risk, or inconsistency?
- What minimum identity, network, management, logging, monitoring, and security capabilities should be shared?
- Which workloads require legitimate variation from the common foundation?
- How should consumers access the foundation without becoming tightly coupled to its internal implementation?
- What resilience and support levels are justified by the number of dependent services?
- Who owns the lifecycle and evolution of these foundational capabilities?
- What enterprise workloads and capabilities would depend on the platform?
- What failure modes and blast radius would platform adoption introduce?
- Does the platform meet required security and isolation expectations?
- Can it scale technically and operationally as adoption grows?
- What observability, support, recovery, and maintenance capabilities are required?
- What hidden dependencies on providers, regions, control planes, or specialist skills exist?
- Which weaknesses are acceptable for limited use but unacceptable for strategic enterprise dependence?
Defining Workload Placement Principles Across Available Environments
- What characteristics should determine where a workload is placed?
- Which data, sovereignty, latency, security, resilience, or connectivity requirements materially constrain placement?
- What operational and skill capabilities exist in each environment?
- When should workloads use shared enterprise platforms rather than dedicated environments?
- What portability or exit requirements should influence placement?
- Which exceptions to the placement principles are legitimate?
- How can the principles guide decisions without becoming a rigid rule that ignores workload context?
- What value does platform consistency provide to the enterprise?
- Which workload needs genuinely require local variation?
- What parts of the platform should be standardized for security, support, interoperability, or cost reasons?
- Where should workload teams retain freedom over tools, runtimes, or implementation?
- What friction are teams currently experiencing because the shared platform is too restrictive?
- What enterprise cost or risk is being created where autonomy is too broad?
- What platform contract best separates common responsibilities from team-owned choices?
- What role does each shared platform play in the enterprise architecture?
- Where do platform responsibilities overlap or compete?
- Which identity, network, data, observability, and security capabilities need to work consistently across them?
- What dependencies exist between the platforms themselves?
- Are teams being forced to integrate several platforms manually because enterprise boundaries are unclear?
- Which interoperability standards or common services would reduce cross-platform friction?
- What platform consolidation or boundary changes would improve coherence without creating excessive concentration?
- How have consumer needs changed since the platform architecture was established?
- Which platform constraints are now limiting workloads unnecessarily?
- What new technology could improve the platform without destabilizing existing consumers?
- Which parts of the platform have accumulated architectural debt?
- What interfaces or contracts need to remain stable while internals evolve?
- How should migration be handled when platform changes require consumer action?
- What evidence should determine whether to evolve the existing platform or replace it more fundamentally?
- Which consumer decisions currently require unnecessary platform-team involvement?
- Where are provisioning, onboarding, approval, or support queues slowing delivery?
- Which common actions can become self-service or automated?
- What guardrails would let consumers operate safely without central intervention?
- Are platform interfaces and documentation clear enough for teams to use independently?
- Which requests indicate that the platform boundary or service model is poorly designed?
- How can the platform team focus on shared capabilities and evolution rather than becoming the execution point for every consumer change?
Integrating Cross-Cutting Architecture Qualities and Constraints
Identifying Which Cross-Cutting Qualities Materially Constrain an Architecture Decision
- Which quality requirements could materially change the architecture options available to us?
- What resilience, security, privacy, performance, accessibility, safety, sovereignty, sustainability, or regulatory concerns apply?
- Which qualities are mandatory constraints and which represent desirable improvements?
- What business or mission consequence justifies the required level of each quality?
- Which qualities apply across several architecture domains rather than only within one solution?
- Where are important quality requirements currently assumed rather than explicitly established?
- Which cross-cutting concerns need to be resolved before we can responsibly select an architecture direction?
Balancing Resilience and Availability Against Cost and Complexity
- What business consequence would result from different durations or forms of service disruption?
- What availability and recovery levels are actually required rather than simply desirable?
- Which resilience measures provide the greatest reduction in consequential failure risk?
- What additional architecture complexity would higher resilience introduce?
- What ongoing cost would greater redundancy, diversity, or recovery capability create?
- Where could resilience measures introduce common dependencies that undermine the intended protection?
- What level of resilience is proportionate once business consequence, cost, complexity, and recovery options are considered together?
Incorporating Security and Privacy Requirements Before the Architecture Is Fixed
- What security and privacy requirements materially constrain the architecture choices?
- Which information, identities, trust boundaries, and privileged capabilities require particular protection?
- What data collection, use, sharing, minimization, or retention requirements must shape the design?
- Which security or privacy controls are difficult or expensive to add after the architecture is established?
- How do the requirements affect platform, integration, data, deployment, and supplier choices?
- What tradeoffs with usability, interoperability, performance, or cost need explicit resolution?
- What security and privacy decisions must be settled before major architectural commitments are made?
Designing Around Sovereignty, Locality, and Jurisdictional Constraints
- Which data, systems, processing activities, or operational capabilities are subject to geographic or jurisdictional restrictions?
- What laws, regulations, contracts, or policies create those restrictions?
- Do the constraints apply to storage, processing, administration, support access, backup, or all of them?
- Which suppliers or cloud regions can satisfy the required locality conditions?
- What cross-border integrations or shared services could unintentionally violate the constraints?
- Where can architecture remain globally shared despite local restrictions?
- What design provides the necessary jurisdictional compliance without creating avoidable fragmentation?
Establishing Recovery and Continuity Expectations Across Shared Architecture
- Which business capabilities depend on this shared architecture during disruption?
- What recovery time and recovery point expectations are justified by the consequences of failure?
- Which consumers require degraded operation rather than complete restoration?
- What dependencies could prevent the shared architecture from recovering within those expectations?
- Are recovery arrangements independent enough from the failure modes they are meant to address?
- How should different consumer recovery requirements be reconciled on one shared platform or service?
- What testing evidence is necessary to show that the recovery expectations are achievable in practice?
Incorporating Accessibility, Safety, or Sustainability Where They Materially Affect Architecture
- Which accessibility, safety, or sustainability requirements have architectural rather than purely implementation consequences?
- What users, environments, or operating conditions make these qualities material?
- Which architecture options would make later compliance difficult or disproportionately expensive?
- What shared platforms, interfaces, devices, facilities, or suppliers are affected by these requirements?
- Where do these qualities conflict with cost, performance, security, resilience, or other constraints?
- What evidence is needed to determine the appropriate level of architectural response?
- How should these requirements be represented so they remain visible throughout later design and delivery?
Reconciling Cross-Cutting Quality Requirements That Pull the Architecture in Different Directions
- Which quality requirements are creating incompatible architecture pressures?
- What business consequence or external obligation supports each requirement?
- Are the apparent conflicts caused by different assumptions about required levels?
- Which requirements are mandatory and which can be traded?
- Can the conflict be reduced through segmentation, differentiated service levels, or separate architectural zones?
- What downside is accepted under each viable compromise?
- Who should decide the remaining tradeoff when it reflects business or risk appetite rather than architecture alone?
Applying a Cross-Cutting Constraint Consistently Across Several Architecture Domains
- Which architecture domains are affected by this constraint?
- What does compliance mean for business, information, application, integration, and technology architecture respectively?
- Which domain-specific implementations can vary while preserving the same enterprise outcome?
- Where could inconsistent interpretation create gaps between domains?
- What shared control, pattern, standard, or evidence would support consistent application?
- Who is responsible for resolving conflicts between domain interpretations?
- How will we verify that the constraint remains effective across the combined architecture rather than only within individual domains?
Deciding Which Quality Requirement Needs an Enterprise Standard or Shared Control
- How widely does this quality requirement recur across the enterprise?
- What risk or inefficiency results when teams address it independently?
- Would a common standard create meaningful consistency or interoperability?
- Could a shared platform control address the requirement more effectively than repeated local implementation?
- What legitimate local variation must remain possible?
- What implementation and migration burden would an enterprise-wide control create?
- Is the enterprise benefit strong enough to justify standardization or shared enforcement?
Reassessing Cross-Cutting Requirements After Incidents, Regulatory Change, or New Evidence
- What new evidence challenges the quality requirements currently embedded in the architecture?
- Did the incident or change reveal an incorrect assumption about consequence, likelihood, or control effectiveness?
- Which existing architectures are affected by the revised requirement?
- Does the change require stronger controls, different architecture, or only better implementation?
- What previously acceptable tradeoffs are no longer acceptable?
- Which standards, reference architectures, roadmaps, or exceptions need to be reconsidered?
- How quickly must the revised requirement be applied to existing and future architecture?
Managing Application Portfolios and Rationalization
Establishing a Reliable Baseline of the Application Portfolio
- Which applications are actually active across the enterprise?
- What business capabilities and user populations does each application support?
- Who owns, operates, funds, and supports each application?
- What lifecycle, cost, usage, technical condition, and criticality information is reliable enough for portfolio decisions?
- Which formal records conflict with operational, financial, contractual, or usage evidence?
- What shadow, local, or externally provided applications are missing from the official portfolio?
- What minimum information must be reliable before rationalization decisions begin?
Identifying Duplicate, Overlapping, and Redundant Applications
- Which applications provide substantially the same business functionality?
- Where do applications overlap only partially because they serve different users or requirements?
- Which apparently duplicate applications are justified by regulation, geography, resilience, scale, or differentiation?
- Which applications could be removed without losing a required capability?
- What data, integration, workflow, or contractual differences complicate consolidation?
- What evidence distinguishes true redundancy from legitimate variation?
- Which overlaps create enough cost or complexity to warrant deeper rationalization analysis?
Assessing Functional Fit and Technical Fit Across the Portfolio
- How well does each application support the business capability it is meant to enable?
- Which important user or operational needs are poorly supported?
- What technical condition, supportability, security, resilience, or maintainability concerns exist?
- Which applications are functionally strong but technically weak?
- Which applications are technically healthy but no longer fit business needs?
- How well does each application align with the intended future architecture?
- Which applications require action because functional fit and technical fit together make the current position unsustainable?
Choosing Whether to Retain, Modernize, Consolidate, Replace, Rebuild, Externalize, or Retire an Application
- What business capability would be affected by changing this application?
- How well does the application meet current and expected future needs?
- What technical, security, support, cost, or lifecycle problems need to be solved?
- Could consolidation with another application address the problem more effectively than modernization?
- Would replacement, rebuilding, or external sourcing create better long-term architectural fit?
- What transition cost, dependency, and business disruption accompanies each disposition option?
- Which disposition solves the actual problem without undertaking more transformation than necessary?
Prioritizing Application Modernization Across Competing Candidates
- Which applications create the greatest current business, technical, security, or operational exposure?
- Which modernization candidates support strategically important or critical capabilities?
- Where would modernization unlock other planned architecture changes?
- Which applications are approaching contractual, support, or regulatory deadlines?
- What dependencies make some modernization work more urgent or more difficult?
- Which candidates offer meaningful simplification or retirement benefits beyond improving one system?
- What sequencing produces the strongest portfolio outcome given available funding and delivery capacity?
Rationalizing Applications Across Business Units with Different Local Needs
- Which business units are using different applications for substantially similar capabilities?
- What genuine local requirements explain the current variation?
- Which differences are historical or organizational rather than necessary?
- What enterprise benefit would consolidation create?
- Where would one common application fail to meet materially different local needs?
- Could a shared core with local configuration or extensions preserve necessary variation?
- What rationalization approach reduces unnecessary diversity without forcing inappropriate uniformity?
Coordinating Portfolio Decisions for Applications That Must Change Together
- Which applications are coupled strongly enough that their portfolio decisions cannot be made independently?
- What data, integration, workflow, platform, or contractual dependencies link them?
- Would retiring or replacing one application force changes in the others?
- Which applications should be treated as a dependency group for modernization planning?
- What sequence minimizes temporary complexity and repeated migration work?
- Which portfolio decisions should wait until shared dependencies are resolved?
- How should funding and ownership be coordinated when the applications belong to different business areas?
Managing Rationalization When Business Units Resist Consolidation
- What reasons are business units giving for retaining their existing applications?
- Which objections reflect legitimate capability or operating-model differences?
- Which objections are driven mainly by local preference, sunk cost, or loss of autonomy?
- What enterprise costs and risks does continued fragmentation create?
- What service, migration, governance, or product shortcomings make the proposed shared solution unattractive?
- Could a different consolidation boundary preserve necessary local autonomy?
- Who should resolve the tradeoff when enterprise simplification and local optimization remain in conflict?
Confirming That a Legacy Application Is Ready for Retirement
- Which business capabilities still depend on the legacy application?
- What current usage evidence confirms whether people or processes still rely on it?
- Which integrations, reports, batch jobs, data feeds, or external parties still consume it?
- Has all required data been migrated, archived, retained, or disposed of appropriately?
- Does the replacement capability cover every requirement that must survive?
- Can the application be disabled reversibly and monitored before permanent shutdown?
- What evidence is sufficient to authorize final retirement?
Checking Whether Application Rationalization Actually Removed Complexity and Cost
- Were the applications selected for retirement actually decommissioned?
- Did integrations, infrastructure, licences, contracts, support arrangements, and specialist skills disappear with them?
- Were temporary migration components removed after the rationalization?
- Did the remaining landscape become easier to understand and change?
- Did consolidation create new concentration, resilience, or supplier risks?
- Did operating costs decline after transition costs ended?
- Has complexity genuinely left the enterprise, or has it merely moved into new platforms and integrations?
Managing Technology Portfolios, Lifecycle, and Obsolescence
Classifying Technologies by Enterprise Adoption and Lifecycle Posture
- What enterprise posture should apply to each significant technology?
- Is the technology being assessed, trialed, preferred, approved, tolerated, restricted, deprecated, unsupported, or retired?
- What evidence justifies its current posture?
- Which use cases are appropriate or inappropriate for the technology?
- Who owns the enterprise lifecycle decision for it?
- What review date or event should trigger reconsideration of the posture?
- Can teams understand from the classification whether they may start, continue, expand, or stop using the technology?
Assessing an Emerging Technology Before Wider Enterprise Use
- What enterprise problem or opportunity could this technology address?
- What evidence exists beyond vendor claims or early market enthusiasm?
- Which use cases are appropriate for a bounded trial?
- What security, data, integration, operational, legal, or supplier risks need investigation?
- What skills and supporting platform capabilities would adoption require?
- What would constitute enough evidence to expand, restrict, or stop experimentation?
- How can the enterprise learn from trials without creating uncontrolled production dependence?
- What implementation evidence shows that the technology performs well in relevant enterprise contexts?
- Which use cases have been validated, and which remain uncertain?
- What support, security, operational, and lifecycle arrangements are mature enough for broader adoption?
- What existing technologies would the new preferred technology complement or replace?
- What migration or skills investment would wider adoption require?
- Should the technology become preferred guidance or a mandatory standard?
- What conditions should trigger review if broader adoption reveals new limitations?
Stopping New Adoption of a Technology That Should No Longer Expand
- What evidence shows that new use of this technology should stop?
- Is the concern supportability, security, strategy, cost, supplier direction, skills, or architectural fit?
- Which new initiatives are currently considering or planning to use it?
- What approved alternatives should be used instead?
- Can existing implementations continue safely for a defined period?
- What exception criteria should apply if a team believes new adoption remains necessary?
- How should the stop-new-use decision connect to the longer-term migration and retirement plan?
Finding Where an Approaching End-of-Support Technology Is Still Used
- Which applications, services, platforms, and infrastructure still depend on the technology?
- What versions are deployed, and when does support actually end for each?
- Which uses are critical to business or mission operations?
- What systems are missing from the formal technology inventory?
- What discovery evidence can confirm actual use?
- Which dependencies make replacement difficult or time-consuming?
- What migration scope and urgency become visible once the complete usage footprint is understood?
Planning Enterprise Migration Away from Obsolete or Unsupported Technology
- Which business capabilities are exposed by continued use of the obsolete technology?
- What supported alternatives are viable for different types of workloads?
- Which applications can migrate directly, and which require deeper modernization first?
- What dependencies determine migration sequencing?
- What temporary exceptions or compensating controls are needed during the transition?
- What skills, funding, supplier, and platform capacity are required to complete the migration?
- What end condition will demonstrate that the technology has actually left the enterprise?
Managing Exceptions for Continued Use of Deprecated Technology
- Why can this use not migrate within the expected timeline?
- What business or technical dependency requires continued use?
- What additional security, operational, or support risk does the exception create?
- What compensating controls can reduce the risk temporarily?
- Who accepts the residual risk and owns the migration?
- What expiry date or exit condition should apply?
- What should happen if repeated exceptions show that the enterprise migration plan is unrealistic?
Prioritizing Technology Lifecycle Risk Across the Estate
- Which technologies create the greatest combination of business criticality and lifecycle exposure?
- Where is vendor support ending soonest?
- Which technologies have severe security, skills, reliability, or maintainability concerns?
- What scale of enterprise usage increases the consequence of delay?
- Which migrations have the longest lead times or hardest dependencies?
- Where can one remediation action remove risk across many systems at once?
- How should lifecycle priorities be sequenced when urgency, consequence, feasibility, and dependency point in different directions?
Responding When a Supported Technology Becomes Strategically Unsuitable
- What has changed to make the technology strategically unsuitable despite continued vendor support?
- Does it conflict with target architecture, operating-model, interoperability, resilience, cost, or supplier-dependency goals?
- Which existing uses remain acceptable in the short term?
- Should new adoption stop before existing deployments are migrated?
- What alternative technologies or architectures better fit future direction?
- What cost and disruption would earlier migration create compared with waiting for normal lifecycle replacement?
- What evidence would justify accelerating, delaying, or narrowing the transition?
Retiring a Technology from the Enterprise Portfolio After Its Final Uses End
- Has every known production use of the technology ended?
- Are there dormant, disaster-recovery, development, archive, or specialist uses that remain?
- Have licences, contracts, support arrangements, tooling, and operational procedures been closed?
- Can related standards, patterns, skills requirements, and exceptions now be retired?
- What historical architecture information should remain available after retirement?
- Are replacement technologies fully supported and operational?
- What evidence is sufficient to mark the technology as retired rather than merely deprecated?
- Which enterprise capabilities now depend materially on this supplier or platform?
- How broadly is the dependency distributed across applications, data, operations, and business units?
- What would happen if the supplier or platform became unavailable or materially changed its terms?
- How quickly could the enterprise substitute or replace the dependency?
- What contractual, technical, data, skill, or ecosystem factors make switching difficult?
- Is the dependency explicitly recognized in architecture and risk decisions today?
- What additional governance is justified by its strategic importance?
Tracing Hidden Upstream Dependencies Behind a Critical External Service
- What infrastructure, cloud, network, software, identity, data, or subcontractor dependencies sit behind the service?
- Which upstream providers are shared with other supposedly independent enterprise services?
- What control-plane or administrative dependencies could affect service availability?
- Are critical support or recovery processes dependent on additional third parties?
- What evidence can the supplier provide about relevant supply-chain tiers?
- Which hidden dependency could create a common-mode failure or geopolitical exposure?
- How should the discovered upstream dependencies affect architecture, resilience, or sourcing decisions?
Assessing Vendor Lock-In Before Making a Long-Lived Architecture Commitment
- What proprietary technology, interfaces, data formats, or operating models would the commitment create?
- How much application logic or data would become dependent on provider-specific capabilities?
- What contractual or licensing terms would make switching difficult?
- What specialist skills or processes would become provider-specific?
- How expensive and time-consuming would realistic exit be?
- What value do the provider-specific capabilities create compared with the loss of optionality?
- What portability or exit measures are proportionate before making the commitment?
Determining How Much Portability a Critical Capability Actually Requires
- How plausible is it that the enterprise will need to move this capability?
- What events could make relocation or provider substitution necessary?
- Which parts of the capability need portability: code, runtime, data, configuration, operations, skills, or contracts?
- What cost and architectural constraint would high portability impose today?
- Which provider-specific benefits would be sacrificed to preserve portability?
- Could a tested exit path provide sufficient protection without full runtime portability?
- What level of portability is proportionate to the capability's criticality and switching risk?
- What circumstances could trigger exit from this provider or platform?
- Which applications, data, integrations, identities, and operational processes would need to move?
- What viable destination or substitution options exist?
- What contractual rights, data-export capabilities, and transition support are available?
- What skills, time, capacity, and funding would exit require?
- Which dependencies make exit hardest and should be reduced in advance?
- What evidence or exercises should confirm that the exit strategy remains realistic?
- How much critical enterprise capability depends on the same supplier or platform?
- Which apparently different services share a common upstream provider?
- What business consequence would result from a provider-wide disruption?
- Would diversification meaningfully reduce risk or merely add complexity?
- Which capabilities justify independent alternatives or fallback arrangements?
- How does supplier concentration affect commercial leverage and exit difficulty?
- What degree of concentration is acceptable given the value, resilience, cost, and substitution options available?
Reviewing Strategic Supplier Dependencies Before Renewal, Expansion, or Deeper Adoption
- How has enterprise dependence on the supplier changed since the original decision?
- What new capabilities, data, or workloads are proposed for the supplier?
- Has the supplier's technology direction, financial position, ownership, pricing, or support model changed?
- What switching cost would further adoption add?
- Are portability and exit arrangements still proportionate to the expanded dependency?
- What alternative suppliers or architectures remain credible?
- Should the enterprise renew, expand, constrain, diversify, or begin reducing the dependency?
Balancing Provider-Specific Value Against Future Switching Difficulty
- What meaningful capabilities or efficiencies are available only through deeper provider-specific use?
- How much future flexibility would be lost by adopting them?
- What migration effort would be created if the enterprise later needed to exit?
- Can provider-specific components be isolated behind stable architectural boundaries?
- Which parts of the architecture genuinely benefit from portability?
- What future scenarios make switching difficulty materially important?
- Does the value gained justify the additional dependency when whole-lifecycle consequences are considered?
Testing Whether Critical Exit, Recovery, or Substitution Assumptions Are Realistic
- Which assumptions in our exit or substitution plan have never been tested?
- Can required data actually be exported completely and within the expected time?
- Are alternative platforms technically and operationally capable of taking the workload?
- Do we have the skills, credentials, documentation, and tooling needed to execute the plan?
- How long would contractual and procurement steps take during a real exit?
- What dependencies would continue to tie us to the existing provider after migration?
- What test or exercise would give us credible evidence that the plan is executable rather than theoretical?
- What is driving the decision to leave the existing supplier or platform?
- Which components, data, integrations, and processes are most tightly coupled to it?
- What target architecture should replace the current dependency?
- Which parts can move incrementally and which must transition together?
- What temporary coexistence or data synchronization will be required?
- How will service continuity and contractual obligations be managed during migration?
- What conditions confirm that the enterprise can terminate the old dependency without leaving residual lock-in behind?
Governing Architecture Through Investment and Portfolio Decisions
Assessing an Initiative Architecturally Before Significant Funding Is Committed
- What capability or business outcome is the initiative intended to change?
- What existing applications, services, platforms, or investments already address some of the need?
- How does the initiative fit the enterprise target architecture and relevant roadmaps?
- What important data, integration, platform, supplier, or organizational dependencies would it create?
- What major standards, security, resilience, regulatory, or lifecycle constraints apply?
- What materially different architecture options remain open at this stage?
- What architectural uncertainty should be resolved before significant funding or contractual commitment occurs?
Testing Whether a Proposed Investment Fits the Target Architecture
- Which elements of the target architecture does the investment advance?
- Does the proposal create architecture that the target state is intended to eliminate?
- Which target-state principles, platforms, information domains, or application boundaries are relevant?
- Is any apparent misalignment justified by changed evidence or a legitimate transition need?
- What future migration burden would be created if the investment proceeds outside the target direction?
- Could the investment be reshaped to deliver its business outcome while improving architectural fit?
- Should the target architecture itself be reconsidered before rejecting the proposal?
Identifying Duplicate or Conflicting Investments Across the Portfolio
- Which initiatives are funding similar capabilities, platforms, applications, or data solutions?
- Are the apparent duplicates serving genuinely different business contexts?
- Which investments make incompatible assumptions about shared architecture?
- Where are multiple initiatives independently solving the same foundational problem?
- Could one investment provide a shared capability that removes the need for others?
- What sequencing or ownership conflicts exist between overlapping proposals?
- What portfolio action would reduce duplication without creating an inappropriate one-size-fits-all solution?
Exposing Cross-Initiative Architecture Dependencies Before Portfolio Prioritization
- Which initiatives depend on capabilities or platforms another initiative is expected to deliver?
- What data, integration, identity, infrastructure, or migration dependencies link the initiatives?
- Which initiatives must be sequenced together or in a particular order?
- What happens to dependent initiatives if an enabling investment is delayed or rejected?
- Are several initiatives competing to change the same architecture component?
- Which dependencies are currently invisible in financial or project portfolio views?
- How should these architectural relationships affect prioritization and funding decisions?
Connecting Investment Proposals to Required Capability and Architecture Change
- What capability change does this investment proposal fund?
- What architecture change is necessary to produce that capability outcome?
- Which part of the proposal is business change, which is architecture change, and which is delivery work?
- What existing architecture can be reused rather than funded again?
- What legacy architecture could be retired if the investment succeeds?
- What other investments are required for the capability outcome to materialize?
- Is the proposed spending proportionate to the architecture change actually required?
- Which investments create prerequisites for later portfolio changes?
- What hard dependencies prevent some investments from delivering value independently?
- Which shared architecture enablers should be funded before dependent initiatives?
- Where would premature investment create stranded assets or temporary duplication?
- What contract, regulatory, lifecycle, or operational deadlines constrain the sequence?
- Which investments can proceed in parallel without increasing architectural risk?
- What sequencing produces the strongest combination of early value and long-term architectural coherence?
Identifying Shared Architecture Enablers That No Single Initiative Is Funded to Deliver
- Which shared capability or platform is required by several funded initiatives?
- Why is no individual initiative currently accountable for delivering it?
- What happens if each initiative creates its own local substitute?
- What enterprise value would a shared enabler provide beyond the immediate projects?
- Who should own and operate the shared capability after delivery?
- How should its cost be funded when benefits span several portfolios?
- What portfolio decision is needed to prevent the shared dependency from becoming an unfunded assumption?
Managing a Portfolio Decision That Knowingly Diverges from the Preferred Architecture
- What business reason justifies proceeding against the preferred architecture direction?
- Which specific architecture principles, standards, targets, or roadmap assumptions are being departed from?
- What short-term benefit does the divergence create?
- What long-term cost, debt, dependency, or migration burden does it introduce?
- Can the divergence be bounded and given an explicit exit condition?
- Who owns the consequences and any additional funding required later?
- What should cause the portfolio to revisit or reverse the decision?
Reassessing Portfolio Priorities When Architecture Assumptions Materially Change
- Which architecture assumption underlying current portfolio priorities has changed?
- Which investments are most affected by the new evidence?
- Do any initiatives now depend on capabilities or platforms that will not exist as expected?
- Which investments have become more urgent because of lifecycle, risk, or dependency changes?
- Which planned investments no longer support the revised target architecture?
- What commitments are already difficult to reverse?
- How should the portfolio be reprioritized while preserving the most important business outcomes?
Checking Whether the Funded Portfolio Is Actually Converging Toward the Intended Architecture
- Which target architecture outcomes are being funded by the current portfolio?
- Are major architecture gaps left without any funded change?
- Are funded initiatives creating new duplication or dependencies that contradict the intended direction?
- Which legacy systems, platforms, or integrations are actually scheduled to leave the enterprise?
- Are shared enablers being delivered early enough for dependent investments?
- What architecture outcomes have been repeatedly deferred despite continued project spending?
- Does the combined portfolio move the enterprise structurally toward the target, or merely deliver isolated local improvements?
Governing Architecture Through Procurement and Sourcing
Shaping Architecture Requirements Before a Technology Procurement Is Fixed
- What business capability and outcome is the procurement intended to support?
- Which architecture requirements must be defined before potential solutions or suppliers are considered?
- What interoperability, data, security, resilience, portability, and lifecycle expectations should apply?
- Which enterprise platforms, standards, and target-state directions should constrain the procurement?
- What requirements should remain outcome-based rather than prescribing a particular product or implementation?
- Which future integration, migration, or exit needs should be built into the procurement from the start?
- What architecture information must Procurement and suppliers receive to respond meaningfully?
Challenging a Procurement Request That Prematurely Prescribes a Product or Solution
- What underlying business or capability need is the requested product meant to address?
- What evidence shows that this specific product or solution is necessary?
- Which requirements were defined before the preferred solution was selected?
- What existing enterprise capabilities or services could satisfy some or all of the need?
- What materially different sourcing or architecture options remain viable?
- What long-term dependencies or constraints would accepting the prescribed solution create?
- How should the request be reframed so suppliers compete against the required outcome rather than a predetermined architecture?
Evaluating the Architecture of Competing Supplier Solutions
- How well does each supplier solution satisfy the required business and architectural outcomes?
- How does each option fit existing and target enterprise architecture?
- What integration, data, identity, platform, and operational dependencies would each supplier introduce?
- How do the options differ in resilience, security, scalability, interoperability, and lifecycle support?
- What proprietary technology or supplier-specific architecture would increase switching difficulty?
- Which supplier claims require evidence, proof of concept, reference implementations, or contractual confirmation?
- What architectural differences should materially influence the sourcing decision even if commercial scores are similar?
Specifying Interoperability, Data, Portability, and Exit Requirements in a Procurement
- What systems, partners, and enterprise services must the procured solution interoperate with?
- What APIs, standards, formats, protocols, or event mechanisms should suppliers support?
- Who must retain ownership and usable access to enterprise data?
- In what format and timeframe must data be exportable?
- What configuration, metadata, interfaces, or operational knowledge must be transferable during exit?
- What contractual obligations should support migration, transition assistance, and service continuity?
- How can we make these requirements testable rather than leaving them as broad procurement language?
Assessing Architectural Lock-In Created by Commercial Terms or Supplier Design
- Which parts of the proposed solution depend on proprietary technology or supplier-specific services?
- What commercial terms increase the cost or difficulty of reducing or ending the relationship?
- What data, integration, licensing, or technical dependencies would persist after contract termination?
- How much enterprise capability would become dependent on this supplier?
- What realistic alternatives could replace the supplier if circumstances changed?
- What value do the supplier-specific capabilities provide in exchange for the additional dependency?
- What architectural or contractual measures could reduce lock-in without sacrificing disproportionate value?
- Which enterprise standards and target-state directions apply to this procurement?
- What existing shared platforms or services should the procured solution use?
- Would the procurement introduce a new platform or technology category that the enterprise does not currently need?
- Where does the proposed sourcing approach align with planned application, data, integration, and technology architecture?
- Which apparent conflicts are legitimate because the target architecture has changed or does not fit the context?
- What exceptions would be required if the procurement proceeds as proposed?
- How can the procurement be adjusted to meet its business need while strengthening rather than fragmenting enterprise architecture?
Handling a Procurement Constraint That Makes the Preferred Architecture Impractical
- What procurement, market, commercial, legal, or timing constraint prevents the preferred architecture from being obtained?
- Is the constraint temporary or likely to persist throughout the solution lifecycle?
- Which architectural requirements remain genuinely non-negotiable?
- What alternative architecture options could satisfy the business need under the constraint?
- Can a temporary solution be used without becoming an uncontrolled permanent deviation?
- What additional risk, cost, or future migration burden would the compromise create?
- What decision authority should approve the revised architecture and its consequences?
- What architectural decisions require input from each stakeholder group?
- Which stakeholder owns each commercial, legal, security, data, business, or architecture judgment?
- Where do requirements from different functions conflict?
- What information should be shared before the tender or sourcing process begins?
- How can architecture requirements be incorporated without creating duplicate approval processes?
- Which issues need to be resolved before supplier evaluation, and which can remain conditions of later design?
- How should unresolved cross-functional decisions be escalated without delaying the procurement unnecessarily?
Reassessing Architecture During Contract Renewal or Recompetition
- Does the existing solution still fit current business and architecture needs?
- How has enterprise dependence on the supplier changed during the contract term?
- Have target architecture, standards, security requirements, or technology options changed materially?
- What technical debt, integration burden, or lock-in has accumulated?
- Which alternatives are now credible that were not available during the original procurement?
- What migration or exit opportunity would be lost by renewing without reassessment?
- Should the enterprise renew, reconfigure, compete, replace, or begin exiting the current solution?
Ensuring a Procured Solution Can Be Transitioned, Replaced, and Retired Responsibly
- What will be required to migrate into the solution safely?
- How will existing data, integrations, and users transition from the current environment?
- What dependencies could make future replacement unusually difficult?
- What data, configuration, documentation, and operational knowledge must remain accessible to the enterprise?
- What contractual rights and supplier assistance are necessary for eventual exit?
- What happens to data, interfaces, licences, and infrastructure when the solution is retired?
- What evidence should be required before accepting that the solution has a credible lifecycle and exit path?
Governing and Assuring Architecture Through Product, Program, and Delivery
Engaging Architecture Early in a Product, Program, or Project
- What architecture questions need to be resolved before significant design or delivery commitments are made?
- Which existing capabilities, platforms, standards, or roadmaps should the team understand at initiation?
- What cross-domain dependencies could affect scope or sequencing?
- Which architecture decisions can remain open until later delivery stages?
- What level of architecture involvement is proportionate to the initiative's consequence and complexity?
- Who should provide architecture support during discovery and early design?
- What would become expensive to correct if architecture engagement begins too late?
Defining Architecture Boundaries and Delegated Decisions for a Delivery Team
- Which architecture decisions may the team make independently?
- What standards, guardrails, reference architectures, and target-state constraints apply?
- Which shared services or platforms form fixed boundaries around the team's design space?
- What kinds of decisions require consultation or escalation?
- Which local choices are sufficiently reversible to remain fully delegated?
- What evidence should the team retain for consequential decisions made within its authority?
- How will the team know when a seemingly local decision has become an enterprise concern?
Reviewing a Consequential Design Before It Becomes Expensive to Reverse
- Which parts of the proposed design create long-lived or difficult-to-reverse commitments?
- What assumptions are being made about shared platforms, data, suppliers, integrations, or future scale?
- Does the design align with relevant target architecture, standards, and reference patterns?
- What materially different design options were considered?
- What cross-domain consequences could emerge after implementation?
- Which unresolved risks or dependencies require action before commitment?
- What should be changed now because correction would become disproportionately expensive later?
Applying Architecture Governance in Agile and Continuous-Delivery Environments
- Which architecture decisions occur too frequently for traditional review gates?
- What guardrails can let teams make routine decisions without central approval?
- Which architectural rules can be automated in delivery pipelines or platform policies?
- What significant decisions still require human architectural judgment?
- How should architecture decisions be recorded without introducing heavy documentation overhead?
- What events should trigger deeper architecture review during continuous delivery?
- How can governance remain responsive enough that teams do not bypass it to maintain delivery speed?
Allowing Teams to Self-Certify Changes That Stay Within Established Guardrails
- What conditions must be true for a team to self-certify an architecture change?
- Which standards and guardrails must the team assess before proceeding?
- What evidence should the team retain to demonstrate conformance?
- What kinds of change are too consequential for self-certification?
- How should uncertainty or ambiguous applicability be handled?
- What sampling, audit, or feedback mechanism can test whether self-certification is working?
- What recurring self-certification problems would indicate that the guardrails themselves need improvement?
Escalating a Delivery Decision That Creates Cross-Domain Consequences
- What consequence extends beyond the delivery team's delegated authority?
- Which other domains, platforms, products, or business units are affected?
- Is the issue about shared dependency, precedent, risk, standard deviation, or irreversible commitment?
- What options has the team already considered?
- Which stakeholders need to participate in the escalated decision?
- What decision body is the lowest level capable of owning the full consequences?
- What information should accompany the escalation so it can be resolved without restarting the entire design discussion?
Verifying That Important Architecture Decisions Survive Implementation
- Which architecture decisions are important enough to verify during implementation?
- What observable implementation evidence would demonstrate conformance with each decision?
- Have delivery constraints caused the team to alter any material architecture choice?
- Do the implemented interfaces, dependencies, data flows, or platform choices match the approved intent?
- Which architecture rules can be checked automatically?
- What deviations have occurred without being formally recorded?
- What corrective action is needed where implementation no longer matches the intended architecture?
Responding When Delivery Evidence Invalidates an Architecture Assumption
- Which architecture assumption has been contradicted by implementation evidence?
- How material is the assumption to the approved architecture direction?
- Does the evidence indicate a local implementation issue or a flaw in the broader architecture?
- Which decisions, standards, roadmaps, or reference architectures depend on the invalid assumption?
- What alternative design or transition response is now viable?
- Who needs to approve a material change in direction?
- What learning should be fed back into future architecture work so the same assumption is not repeated?
Providing Architecture Assurance Before Production, Migration, or Major Release
- Which architecture conditions must be satisfied before this change enters production or migration?
- Have material architecture decisions been implemented as intended?
- Are unresolved exceptions, risks, and dependencies visible and owned?
- Are security, resilience, data, integration, and operational concerns sufficiently addressed?
- What temporary transition arrangements will exist after release?
- Which issues can safely be accepted after release, and which should block progression?
- What evidence should be retained to support the assurance decision?
Feeding Implementation Outcomes Back into Enterprise Architecture
- What did implementation reveal that was not known during architecture design?
- Which standards, patterns, or reference architectures worked well in practice?
- Which guidance created unnecessary difficulty or failed to address real constraints?
- What new dependencies or architectural realities emerged?
- Did the implemented solution produce the expected architecture outcome?
- Which enterprise architecture records, roadmaps, or target-state assumptions now need updating?
- What learning should be shared with other teams facing similar architecture decisions?
Managing Architecture Exceptions, Temporary Deviations, and Technical Debt
Requesting an Exception to an Architecture Standard or Guardrail
- Which specific standard or guardrail cannot be followed?
- What business or technical circumstance creates the need for an exception?
- What alternatives were considered before requesting the exception?
- What scope of architecture would the exception affect?
- What risks, costs, or future constraints would the deviation introduce?
- How long is the exception expected to be necessary?
- What evidence should accompany the request so it can be assessed proportionately?
Evaluating Whether an Architecture Deviation Is Justified
- What value or necessity does the proposed deviation provide?
- Is the underlying architecture requirement genuinely applicable in this context?
- What alternatives could achieve the same outcome without deviation?
- What enterprise risks or dependencies would the exception create?
- Is the deviation reversible and bounded?
- What compensating controls or conditions could reduce its consequences?
- Would approval create a precedent that materially weakens the architecture standard elsewhere?
Distinguishing a Standards Exception from a Controlled Experiment
- Is the team trying to solve an exceptional local constraint or deliberately test a new architectural approach?
- What learning objective exists if this is an experiment?
- What production exposure is acceptable during the trial?
- What time, scope, and user boundaries should limit the experiment?
- What evidence will determine whether the experiment succeeds or fails?
- What happens to the implementation when the experiment ends?
- At what point should successful experimental evidence trigger reconsideration of the existing standard?
Approving an Architecture Decision Subject to Explicit Conditions
- What prevents unconditional approval of the architecture today?
- Which specific conditions must be satisfied?
- Who owns each condition?
- What evidence will demonstrate that the condition has been met?
- By what date or event must the condition be closed?
- What happens if delivery proceeds but the condition remains unresolved?
- Who has authority to verify closure or decide whether the approval must be revisited?
Managing a Temporary Architecture Departure That Must Later Be Removed
- Why is the temporary departure necessary?
- What architecture state should eventually replace it?
- Which dependencies or constraints prevent immediate conformance?
- What cost and risk will exist while the temporary architecture remains?
- Who owns removal of the temporary component or deviation?
- What explicit exit condition or deadline should apply?
- What governance response is needed if the supposedly temporary state continues beyond its intended life?
Recording Architectural Debt Created by a Deliberate Compromise
- What architectural compromise has been made?
- What delivery constraint or business reason justified accepting it?
- Which future cost, risk, coupling, or limitation does the compromise create?
- What systems, capabilities, or teams will be affected by the debt?
- What would remediation require?
- What event should trigger reconsideration or repayment of the debt?
- Where should the debt be recorded so it remains visible after the immediate initiative ends?
Prioritizing Architecture Debt According to Enterprise Consequence
- Which architecture debt items affect critical or strategically important capabilities?
- Which debt creates the greatest risk, change friction, operating cost, or dependency?
- What debt is growing more expensive as new solutions build on top of it?
- Which items can be addressed together through a common architectural change?
- What debt is tolerable because its consequences are small or localized?
- Which remediation actions are constrained by other roadmap or investment dependencies?
- How should the portfolio balance architecture debt reduction against new capability investment?
- What remediation action was committed when the exception or debt was accepted?
- Who owns completing the action?
- What deadline, milestone, or exit condition applies?
- What evidence demonstrates actual remediation rather than planned remediation?
- Have new dependencies made the commitment harder or less appropriate?
- What escalation should occur when remediation is repeatedly delayed?
- When can the exception, condition, or debt item be formally closed?
Managing Multiple Interacting Exceptions That Together Change the Effective Architecture
- Which active exceptions affect the same domain, platform, standard, or capability?
- Are individually acceptable deviations combining into a materially different architecture?
- What new dependencies or risks emerge from their interaction?
- Has the cumulative exception pattern effectively superseded the intended standard or target state?
- Which temporary deviations have become mutually dependent?
- Should the enterprise address the combined issue through a broader architecture change rather than separate exception renewals?
- What governance body should decide when cumulative exceptions have become an enterprise architecture problem?
Closing, Renewing, or Superseding an Exception When Conditions Change
- Has the condition that justified the original exception changed?
- Has the required remediation or migration been completed?
- Does the exception still create material risk or architectural divergence?
- Is renewal justified by new evidence or merely by continued delay?
- Has a revised standard or target architecture superseded the original requirement?
- What new expiry, conditions, or ownership should apply if the exception continues?
- What evidence is required to close the exception permanently?
Defining the Architectural Problem a Major Modernization Must Solve
- What business, technical, risk, cost, or strategic problem is driving the modernization?
- Which symptoms are visible, and what structural causes sit behind them?
- What parts of the current architecture prevent required future capability?
- Which problems could be solved incrementally without a major transformation?
- What would remain unacceptable if the enterprise only upgraded the existing technology?
- What architectural outcome would demonstrate that the underlying problem has been solved?
- How can the modernization objective avoid becoming "replace old technology" without a clearer enterprise outcome?
- Which business capabilities are genuinely affected by the transformation?
- What information domains and data flows must change with them?
- Which applications and services need to be replaced, restructured, or retained?
- What platforms, technologies, and infrastructure are within the transformation boundary?
- What operating-model, ownership, or support changes are necessary for the target architecture to work?
- Which adjacent architecture should remain outside scope despite being related?
- Where would an artificially narrow scope create downstream rework or leave the structural problem unresolved?
Deciding Whether Incremental Improvement Is Enough or the Target Architecture Must Fundamentally Change
- Can the current architecture support the required future capabilities with bounded improvements?
- Are recurring problems caused by local defects or by the underlying architecture structure?
- How much change effort is currently spent preserving legacy constraints?
- Are integration, support, security, or operational problems worsening despite incremental modernization?
- What future requirements cannot reasonably be met within the existing architecture?
- Could a fundamentally different target still be reached through incremental migration rather than a big-bang replacement?
- What evidence would justify the additional disruption and investment of a deeper architectural change?
- Which systems, data, capabilities, and platforms must change together?
- What technical, operational, contractual, or business dependencies define each group?
- Which dependencies make it unsafe to migrate individual components separately?
- Where can interfaces temporarily decouple parts of the transformation?
- Which shared foundations should move before dependent groups?
- How do dependency groups affect migration waves, ownership, and funding?
- What new evidence should cause a dependency group to be split, combined, or resequenced?
- Which target architecture elements are shared across transformation workstreams?
- Where could independent workstreams make incompatible architecture decisions?
- What shared platforms, data, interfaces, or standards need coordinated delivery?
- Which workstream assumptions depend on another workstream's outcomes?
- What architecture decisions require a common cross-program authority?
- How should changes to the target architecture propagate across all workstreams?
- What evidence would show that individual workstream success is producing enterprise-level architectural divergence?
Coordinating Modernization When Different Parts of the Enterprise Cannot Move at the Same Pace
- Which domains or systems can modernize quickly, and which are constrained?
- What business, regulatory, contractual, technical, or organizational factors explain the different pace?
- What interfaces or transition architectures can support controlled coexistence?
- Which slower-moving elements should not be allowed to block independent progress elsewhere?
- Which fast-moving areas risk creating architecture that becomes incompatible with later migration?
- How long can asynchronous modernization continue before transition complexity becomes excessive?
- What sequencing and governance will keep different modernization speeds aligned with the common target?
- What complexity in the legacy architecture is the new platform intended to remove?
- Which legacy behaviors or customizations are being copied into the new environment without challenge?
- Are temporary migration interfaces becoming permanent design elements?
- Is the new platform accumulating duplicate functions already provided elsewhere?
- What new proprietary dependencies or operational burdens are being introduced?
- Which old applications, data stores, integrations, and processes will actually disappear after migration?
- How will we measure whether the new platform simplified the enterprise rather than only modernized its technology?
- Where has implementation diverged from the target or transition architecture?
- Which divergences were deliberate decisions and which occurred informally?
- What delivery constraints, new evidence, or local optimizations caused the drift?
- Does the drift reveal that the target architecture is unrealistic or merely that governance is weak?
- What cumulative consequences arise if the deviations continue?
- Which changes should be corrected in delivery, and which should update the target architecture?
- How can the transformation be realigned without creating unnecessary rework or pretending the original plan is still valid?
Retiring Legacy Architecture After Replacement Capabilities Become Operational
- Which legacy systems, interfaces, platforms, and data stores should now be removable?
- Are all required capabilities genuinely available in the replacement architecture?
- What hidden consumers or dependencies could still prevent retirement?
- Have data retention, archival, audit, and regulatory obligations been satisfied?
- What licences, contracts, infrastructure, and support arrangements can be terminated?
- Can legacy components be disabled reversibly before permanent removal?
- What evidence will confirm that the transformation has actually eliminated the legacy architecture rather than merely stopped investing in it?
- Which architecture problems was the transformation intended to solve?
- Did redundant applications, platforms, integrations, or technologies actually leave the enterprise?
- Has undesirable coupling or dependency been reduced?
- Are ownership, information authority, and architecture boundaries clearer?
- Has resilience, security, supportability, or changeability materially improved?
- Did the transformation create new concentration, supplier, or operational risks?
- Is the resulting enterprise structurally simpler and easier to evolve, or has complexity merely moved elsewhere?
Managing Architecture Through Mergers, Acquisitions, Divestitures, and Separations
- What major applications, platforms, data assets, technologies, and suppliers does the other organization depend on?
- Which business capabilities rely on architecture that would be difficult or expensive to integrate?
- What unsupported technology, technical debt, security exposure, or resilience weakness is material to the transaction?
- Which contracts, licences, or supplier terms could constrain integration or change ownership?
- What data, sovereignty, privacy, or regulatory issues could complicate combination?
- Which architectural assumptions in the deal thesis require validation before commitment?
- What findings could materially change integration cost, sequencing, value, or transaction terms?
Baselining Two Enterprise Landscapes for Post-Transaction Architecture Decisions
- What capabilities, applications, information domains, platforms, and technologies exist in each organization?
- How can equivalent architecture elements be compared consistently across both landscapes?
- Which ownership, lifecycle, criticality, cost, and usage information is reliable?
- What overlapping applications or platforms appear to serve similar needs?
- Which important dependencies cross the future organizational boundary?
- Where do the two enterprises use incompatible terminology or architecture classifications?
- What minimum combined baseline is necessary before rationalization and target-state decisions begin?
Deciding How Far Two Enterprise Architectures Should Actually Converge
- What business integration model is intended for the combined organizations?
- Which capabilities need common architecture to operate effectively together?
- Where does strategic differentiation justify retaining separate architecture?
- Which shared foundations would produce meaningful cost, interoperability, or risk benefits?
- What migration burden would full convergence create?
- What long-term complexity would deliberate separation preserve?
- What degree of convergence best matches the intended business model rather than assuming that acquisition always means full architectural absorption?
- Which capabilities are duplicated across the two organizations?
- Which applications, platforms, or technologies provide overlapping support?
- What evidence should determine which elements are retained, consolidated, replaced, or retired?
- Where is coexistence justified because operating requirements genuinely differ?
- What dependencies or data migrations make rationalization difficult?
- Which decisions create the greatest simplification or cost reduction without undermining business capability?
- What sequence prevents rationalization from disrupting critical operations during integration?
Integrating Data, Identity, Interfaces, and Shared Services Across Combining Organizations
- Which data domains and identifiers need to work consistently across the combined enterprise?
- What identity and access arrangements are required for users, systems, and administrators?
- Which interfaces must connect formerly separate business processes?
- What shared services should be integrated first to enable broader combination?
- Where do semantic differences prevent straightforward data or process integration?
- What temporary federation or bridging architecture is required during transition?
- How will the integration avoid creating permanent duplicate sources, identity systems, or interface layers?
Preserving an Acquired Capability That Should Not Be Absorbed into the Existing Architecture
- What strategic or operational value would be lost if the acquired capability were forced into the existing architecture?
- Which parts of the acquired architecture are essential to preserving that value?
- What enterprise standards or shared foundations still need to apply?
- Where should architectural autonomy remain explicit?
- What interfaces are necessary between the preserved capability and the wider enterprise?
- What risks or costs arise from maintaining a distinct architecture?
- What future conditions should trigger reconsideration of the decision to preserve rather than integrate it?
Separating Day-One Transaction Needs from the Intended End-State Architecture
- What must function on the first day after transaction close?
- Which Day-One solutions are temporary compromises rather than intended long-term architecture?
- What shared access, identity, data, connectivity, or operational arrangements are needed immediately?
- Which integration work can safely wait until after business continuity is secured?
- What temporary architecture must have explicit ownership and exit conditions?
- Which Day-One choices could unintentionally constrain the future target architecture?
- How should the roadmap distinguish legal or operational readiness from actual architecture integration?
Defining the Architecture Perimeter for a Divestiture or Organizational Separation
- Which capabilities, systems, data, platforms, contracts, and suppliers belong to the separated entity?
- Which architecture elements are currently shared with the parent organization?
- What must be duplicated, replaced, transferred, or temporarily shared?
- Which data and identity boundaries must exist at legal or operational separation?
- What hidden dependencies could prevent the separated entity from operating independently?
- Which services should remain under transitional arrangements rather than be separated immediately?
- What target perimeter would allow both resulting organizations to operate without unintended architectural dependence?
Designing Transitional Service Arrangements with Explicit Architecture Exit Paths
- Which services must the seller or parent continue providing temporarily?
- What systems, data, identities, infrastructure, or people underpin each transitional service?
- What security and access boundaries are required during the arrangement?
- What service level and duration are necessary for business continuity?
- What replacement capability must the separated entity establish before exit?
- Which milestones and dependencies determine when each transitional service can end?
- How will both parties prevent the transitional architecture from becoming a permanent hidden dependency?
Confirming That Post-Merger Integration or Separation Has Actually Reached Its Intended Architecture
- Which target architecture outcomes were defined for the transaction?
- Have the intended applications, platforms, integrations, and services actually been consolidated or separated?
- Have temporary bridges, transitional services, duplicate environments, and exceptional access arrangements been removed?
- Are data ownership, identity boundaries, and operational responsibilities now clear?
- Have legacy contracts, licences, and infrastructure been terminated where intended?
- What residual dependencies remain between organizations or formerly separate estates?
- Does the resulting architecture match the business integration or separation model, or has temporary complexity become permanent?
Responding to Regulatory, Geopolitical, Supplier, Security, and Technology Change
Assessing the Architecture Impact of a New Regulatory Requirement
- Which capabilities, information, applications, platforms, suppliers, and locations are affected by the new requirement?
- What architectural constraints does the regulation introduce that did not exist before?
- Which parts of the current architecture already comply, and where are material gaps?
- What existing data flows, integrations, hosting arrangements, or operating practices may become unacceptable?
- Which architecture changes are mandatory, and which are only possible responses to the requirement?
- What deadlines, transition periods, or dependencies constrain the response?
- Does the regulation require a local adjustment, an enterprise standard change, or a broader architectural redesign?
Responding to a Geopolitical or Sovereignty Change That Affects Technology or Data
- Which suppliers, hosting locations, data flows, support arrangements, or technologies are exposed to the changed geopolitical condition?
- What sovereignty, sanctions, export-control, ownership, or jurisdictional constraints now apply?
- Which critical capabilities depend on the affected countries, providers, or regions?
- What apparently independent services share the same geopolitical exposure?
- Which workloads, data, or operations need relocation, isolation, duplication, or alternative sourcing?
- What transition risk would arise from changing the architecture quickly?
- What longer-term architecture change would reduce similar exposure without creating disproportionate fragmentation?
Responding to Withdrawal, Failure, or Distress of a Critical Supplier
- Which capabilities, systems, data, and operations depend on the supplier?
- What evidence indicates whether the issue is temporary disruption, strategic withdrawal, or permanent viability risk?
- What contractual rights, continuity provisions, data-export mechanisms, and transition assistance are available?
- Which services could be substituted quickly, and which are deeply embedded in the architecture?
- What immediate measures are needed to preserve continuity while a longer-term response is designed?
- Which exit, replacement, or diversification option is realistically achievable within the available time?
- What architecture changes should remain after the immediate supplier crisis has passed?
Reassessing Architecture After a Major Security Vulnerability or Incident
- Which architectural assumptions were invalidated by the vulnerability or incident?
- What systems, platforms, identities, data flows, or trust boundaries were materially exposed?
- Was the weakness local to one implementation or systemic across the enterprise architecture?
- Which shared dependencies amplified the impact or limited containment?
- What immediate controls are necessary before broader architectural changes can be completed?
- Which standards, reference architectures, technology choices, or target-state assumptions now need revision?
- What structural change would reduce the likelihood or consequence of a similar incident recurring?
Changing Architecture After a Significant Resilience Failure or Outage
- What architectural dependency or failure mode caused the disruption to spread?
- Which supposedly independent services failed because of a common underlying dependency?
- Did recovery arrangements perform as the architecture assumed?
- Which capabilities experienced consequences greater than the accepted resilience level?
- What changes to redundancy, isolation, recovery, supplier diversity, or operating modes would address the weakness?
- What additional complexity and cost would the stronger resilience architecture create?
- Which lessons should become enterprise architecture requirements rather than remain local incident actions?
Evaluating Whether a Major Technology Shift Creates a Materially Better Architecture Option
- What new capability or architectural possibility has become feasible because of the technology shift?
- Which current architecture constraints could the new technology genuinely remove?
- What evidence exists beyond market enthusiasm or vendor positioning?
- What new dependencies, skills, operating models, security concerns, or supplier risks would adoption introduce?
- Which existing architecture investments would become obsolete or need migration?
- Can the technology be tested through bounded adoption before enterprise-wide commitment?
- Does the shift justify changing the target architecture, or should it remain an option until evidence matures?
Reassessing Architecture After a Material Policy or Government Direction Change
- Which existing architecture decisions depended on the previous policy direction?
- What new obligations, priorities, prohibitions, or operating conditions now apply?
- Which current or planned investments conflict with the new direction?
- What architecture can remain unchanged despite the policy shift?
- Which standards, roadmaps, target architectures, or procurement plans need reconsideration?
- What commitments are difficult to reverse and require explicit treatment?
- How quickly should the enterprise alter its architecture before the policy direction itself is proven durable?
Reprioritizing Architecture Roadmaps After an External Shock
- Which roadmap assumptions have been invalidated by the external event?
- What new risks, constraints, or urgent capabilities now require architectural attention?
- Which planned changes can be delayed without unacceptable consequences?
- Which architecture work has become more urgent because of newly exposed dependencies or vulnerabilities?
- What funded initiatives should be resequenced, accelerated, reduced, or stopped?
- What temporary architecture may be necessary before the roadmap can return to a stable path?
- Does the shock require only reprioritization, or has the target architecture itself become unsuitable?
Deciding Whether an External Change Can Be Contained Locally or Requires Structural Redesign
- Which parts of the enterprise are directly affected by the external change?
- Can the consequences be addressed within one system, domain, supplier relationship, or location?
- What shared dependencies could cause a local response to create problems elsewhere?
- Is the external change temporary, uncertain, or likely to represent a durable new condition?
- Would repeated local mitigations create growing enterprise complexity?
- What threshold of cost, risk, or cross-domain impact would justify structural redesign?
- Which architecture option solves the immediate problem while avoiding unnecessary enterprise-wide change?
Removing Emergency Architecture Measures After Stable Conditions Return
- Which emergency controls, platforms, interfaces, workarounds, or supplier arrangements were introduced?
- What condition originally justified each emergency measure?
- Does that condition still exist?
- Which temporary components have acquired new consumers or dependencies since introduction?
- What stable architecture should replace or absorb the emergency arrangement?
- What risks arise from removing the measure too early or retaining it indefinitely?
- What evidence confirms that the enterprise can retire the emergency architecture safely?
- What recurring architecture decisions must the metamodel support?
- Which entity types are necessary to answer those questions?
- Which relationships between capabilities, information, applications, platforms, technologies, suppliers, initiatives, and decisions are materially useful?
- Which attributes are essential for ownership, lifecycle, criticality, status, or analysis?
- What proposed data has no clear decision use and therefore may not justify ongoing maintenance?
- Which information is already mastered elsewhere and should be referenced rather than duplicated?
- How can the metamodel remain small enough to sustain while still supporting important cross-enterprise analysis?
Deciding Which Architecture Information Must Be Maintained Continuously
- Which architecture information is used repeatedly in consequential decisions?
- Which facts become dangerous when stale?
- What information would be costly or slow to reconstruct when urgently needed?
- Which dependencies, standards, lifecycle statuses, decisions, and ownership relationships need persistent visibility?
- What detailed information can remain in authoritative specialist systems until a decision requires it?
- How often should different information categories be reviewed or refreshed?
- What information should we stop maintaining centrally because its ongoing cost exceeds its architecture value?
Connecting the Architecture Repository to Authoritative Enterprise Sources
- Which architecture facts already have authoritative sources elsewhere in the enterprise?
- What information should be synchronized automatically rather than re-entered manually?
- Which source should be authoritative for ownership, contracts, technology, infrastructure, APIs, data, finance, or organizational information?
- How should conflicting data between the repository and an authoritative system be handled?
- What source metadata should remain visible so users can judge provenance and freshness?
- Which integrations would materially reduce manual maintenance effort?
- How do we avoid turning the architecture repository into another competing system of record?
- Who is accountable for confirming each important category of architecture information?
- Which owner is closest enough to the information to keep it accurate?
- How frequently should the information be reviewed given how quickly it changes?
- What events should trigger an immediate update outside the normal review cycle?
- How should last-reviewed dates and validation status be exposed to users?
- What happens when an owner does not confirm information within the expected interval?
- Which information is important enough that stale ownership or status should generate an explicit warning?
- Which architecture information currently lives in different repositories or specialist tools?
- What information should remain distributed because another tool is the authoritative source?
- Which identifiers are needed to connect records representing the same architecture element?
- What relationships must be visible across tool boundaries?
- Where is duplication creating conflicting architecture information?
- What common metamodel or exchange conventions are needed for federation?
- How can users obtain a coherent architectural view without forcing all information into one repository?
Designing Repository Relationships That Support Dependency and Impact Analysis
- Which relationships must be captured to answer the enterprise's most important impact questions?
- What capability-to-application, application-to-data, application-to-platform, supplier, initiative, and technology links are needed?
- Which dependency types need to be distinguished rather than represented as a generic connection?
- What relationship direction, ownership, lifecycle, or criticality information matters for analysis?
- Which relationships can be derived from technical or operational evidence?
- Where would modeling every possible relationship create more maintenance burden than analytical value?
- What impact-analysis questions should the repository be able to answer reliably once the relationship model is in place?
Automating Discovery, Validation, and Staleness Detection Where Practical
- Which architecture facts can be discovered reliably from operational systems?
- Where can automated evidence validate or challenge manually maintained records?
- What changes in cloud, identity, APIs, source repositories, networks, or technology versions should trigger architecture updates?
- Which signals can reveal that an architecture record has become stale?
- What false positives or missing context make full automation unsafe?
- Where is human validation still necessary before discovered information becomes authoritative?
- Which automation would reduce the most maintenance effort without creating misleading confidence in the repository?
Preventing the Architecture Repository from Becoming a Duplicate CMDB or Documentation Warehouse
- What decision purpose does each category of repository information serve?
- Are we storing low-level configuration better managed by operational systems?
- Which documents are being retained without a clear architecture use?
- Are architects maintaining detailed technical inventories that another function already owns?
- What relationships or decision records provide more architectural value than additional inventory detail?
- Which repository content could be removed without impairing consequential architecture decisions?
- What governance will prevent future requests from expanding the repository beyond its useful architectural purpose?
- What architecture knowledge is currently dependent on the existing tool?
- Which models, relationships, decisions, history, metadata, and attachments need preservation?
- What information should be cleansed, simplified, or retired rather than migrated?
- Can the target tool represent the relationships and lifecycle concepts the practice actually needs?
- How will identifiers and links to authoritative sources survive migration?
- What validation will confirm that critical architecture knowledge was transferred correctly?
- How will the practice avoid recreating old repository complexity simply because the previous tool supported it?
Simplifying the Architecture Knowledge Base When Its Maintenance Burden Exceeds Its Value
- Which information consumes the greatest maintenance effort?
- Which fields, models, views, or records are rarely used in meaningful decisions?
- What architecture questions would become impossible if this information were removed?
- Can detailed information be reconstructed or retrieved from authoritative sources when needed?
- Which overlapping models or taxonomies can be consolidated?
- What historical information needs preservation even if active maintenance stops?
- How much simpler can the knowledge base become without weakening decision support, traceability, or impact analysis?
Measuring Enterprise Architecture Value and Outcomes
Defining Which Enterprise Outcomes the Architecture Practice Is Expected to Improve
- What enterprise problems is the architecture practice expected to help reduce?
- Which decision, complexity, reuse, risk, changeability, or strategic-alignment outcomes should improve?
- Which outcomes can Enterprise Architecture influence but not control independently?
- Who experiences the benefit when those outcomes improve?
- What evidence would demonstrate a meaningful change rather than architecture activity alone?
- Which desired outcomes conflict and therefore require balanced measures?
- What small set of outcomes best reflects the actual mandate of the Enterprise Architecture practice?
Establishing a Baseline Before Claiming Architecture Improvement
- What is the current level of the outcome we intend to improve?
- Which data sources can establish the baseline credibly?
- What time period and organizational scope should the baseline cover?
- Are current measurements consistent enough for later comparison?
- What external factors could change the metric independently of Enterprise Architecture?
- Where must qualitative evidence supplement numerical measures?
- What baseline limitations should be recorded before future improvement claims are made?
Measuring the Quality and Timeliness of Consequential Architecture Decisions
- Which architecture decisions are consequential enough to include in the measure?
- How long does it take from a clear decision need to an accountable decision?
- How often are major decisions reopened because important evidence or dependencies were missed?
- How often does architecture review occur only after costly commitments have already been made?
- Are decision rationales, alternatives, consequences, and ownership recorded sufficiently?
- Do stakeholders consider the architecture decision process timely enough to use voluntarily?
- What evidence indicates that faster decisions remain sufficiently informed rather than merely quicker?
Measuring Reduction in Unnecessary Architectural Complexity
- Which forms of complexity are we deliberately trying to reduce?
- Are redundant applications, platforms, technologies, interfaces, or suppliers actually declining?
- How many temporary architecture components remain beyond their intended life?
- Are dependencies becoming simpler and easier to understand?
- Has rationalization removed operating cost and support burden as well as inventory entries?
- Has consolidation reduced duplication without creating excessive concentration or coupling?
- What evidence shows that complexity has left the enterprise rather than moved into a different architectural layer?
Measuring Reuse Without Encouraging Forced or Low-Value Reuse
- Which shared capabilities, APIs, data products, platforms, or patterns are intended for reuse?
- How often are teams using them when they genuinely fit the need?
- What duplicate implementations were avoided because reuse was available?
- What time, cost, or risk reduction resulted from useful reuse?
- Are teams being pressured to reuse services that do not meet their requirements?
- Where does low reuse indicate a discoverability, quality, ownership, or architectural-fit problem?
- How can we measure reuse value without creating an incentive to maximize reuse regardless of context?
Measuring Whether Enterprise Architecture Is Reducing Material Risk
- Which material risks is Enterprise Architecture expected to influence?
- Are unsupported technologies, unowned systems, fragile dependencies, or uncontrolled exceptions declining?
- Are critical supplier and platform dependencies becoming better understood and managed?
- Have significant architecture risks been closed through funded change?
- Are resilience, security, or regulatory weaknesses being identified earlier in decisions?
- What risks have merely been transferred rather than reduced?
- What evidence connects the architecture intervention to a meaningful change in enterprise exposure?
Measuring Whether the Architecture Is Becoming Easier to Change
- How many systems or teams typically need coordinated change for a common business modification?
- Are teams able to make more routine decisions within clear interfaces and guardrails?
- Is the time required to integrate, replace, or retire architecture components improving?
- Are shared platforms reducing repeated foundational engineering?
- Is tight coupling or cross-system regression effort declining?
- Can new capabilities be introduced without repeatedly redesigning large parts of the enterprise?
- What evidence shows that improved delivery speed comes from architectural changeability rather than temporary increases in staffing or effort?
Measuring Whether Investment and Delivery Are Becoming More Strategically Coherent
- Can major investments be traced to required capability and architecture outcomes?
- Are fewer initiatives creating architecture that conflicts with enterprise direction?
- Are shared architecture enablers being funded before dependent initiatives need them?
- Are duplicate investments being identified before commitment?
- Is the portfolio retiring obsolete architecture as well as adding new capability?
- Are delivery outcomes increasingly consistent with approved target and transition architectures?
- What persistent gaps between strategy, funding, and delivered architecture remain visible?
Distinguishing Architecture Activity Metrics from Evidence of Enterprise Value
- Does this metric show an enterprise outcome or merely that architecture work occurred?
- What decision would improve if we knew this number?
- Does producing more of the measured activity necessarily create more value?
- Could teams increase the metric while making the enterprise architecture worse?
- What outcome measure should accompany this activity measure?
- Is the metric useful for internal workload management even if it should not be presented as EA value?
- Which current EA metrics should stop being used as evidence of effectiveness?
Changing Architecture Measures When They Create Distorted Incentives or Stop Being Useful
- What behavior is the current measure encouraging?
- Are teams optimizing the metric rather than the intended architecture outcome?
- Has the underlying enterprise priority changed since the measure was introduced?
- Is the metric still sensitive to meaningful improvement?
- What important consequence is the measure currently ignoring?
- What replacement or complementary measure would better represent the desired outcome?
- How should historical comparability be preserved when the measurement approach changes?
Learning, Adapting, and Sustaining the Enterprise Architecture Capability
Learning from Architecture Outcomes Across Multiple Initiatives
- What recurring architecture outcomes are visible across recent initiatives?
- Which decisions or patterns repeatedly produced good results?
- Which recurring problems suggest a systemic architecture weakness rather than isolated delivery failure?
- What dependencies, standards, or assumptions repeatedly surprised teams?
- Which lessons are common enough to justify enterprise guidance?
- Which outcomes remain context-specific and should not be generalized?
- What architecture practice, standard, roadmap, or capability should change based on the combined evidence?
Reviewing a Major Architecture Decision After Its Consequences Become Visible
- What problem was the original architecture decision intended to solve?
- Which assumptions and evidence supported it at the time?
- What benefits actually materialized?
- Which accepted downsides occurred, and were they proportionate to expectations?
- What unexpected dependencies, costs, risks, or constraints emerged?
- Would we make the same decision today with the evidence now available?
- What should be updated in architecture guidance or future decision practice based on the outcome?
Learning from an Initiative That Failed Because Architecture Assumptions Were Wrong
- Which architecture assumptions proved incorrect?
- Why were those assumptions considered credible when the initiative began?
- What evidence was available but overlooked, misunderstood, or missing?
- Which dependencies or transition conditions were underestimated?
- Did governance occur too late to challenge the assumptions effectively?
- What architecture method, evidence requirement, or review trigger would have exposed the issue earlier?
- What reusable lesson should be incorporated without overreacting to one failed initiative?
Capturing Reusable Architecture Lessons from Delivery Without Turning Every Local Practice into Enterprise Guidance
- What delivery lesson has potential relevance beyond the originating team?
- Which parts of the lesson depend on local context?
- Has the same pattern appeared in several implementations?
- What evidence shows that the lesson improves an architecture outcome rather than merely reflecting team preference?
- Should the learning become a pattern, reference architecture, standard, example, or informal guidance?
- What variation should remain possible when other teams apply it?
- What additional evidence is needed before promoting the lesson into enterprise-wide guidance?
Turning Technology Experiments into Reusable Enterprise Learning
- What hypothesis was the technology experiment intended to test?
- What evidence did the experiment produce about value, risk, fit, and operational feasibility?
- Which assumptions were confirmed or disproved?
- In what contexts did the technology perform well or poorly?
- What architecture dependencies or prerequisites became visible?
- Should the technology move toward broader adoption, remain experimental, become restricted, or be abandoned?
- How should the findings be recorded so other teams do not repeat the experiment without benefiting from prior evidence?
Maintaining Continuity of Critical Architecture Knowledge and Leadership Through Personnel Change
- Which architecture knowledge currently depends too heavily on particular individuals?
- What major decisions, dependencies, relationships, and rationales would be difficult to reconstruct if those people left?
- Which leadership responsibilities need explicit succession or delegation?
- What knowledge should be captured in durable decision records or repositories?
- Which stakeholder relationships and informal coordination mechanisms need deliberate handover?
- How can incoming architects distinguish established decisions from personal preferences of previous role holders?
- What practices reduce key-person dependency without attempting to document every detail of architectural knowledge?
Retiring a Governance Mechanism That No Longer Adds Enough Value
- What purpose was this governance mechanism originally created to serve?
- What decisions or risks does it currently influence?
- What evidence shows that its benefit has declined?
- Is another mechanism now handling the same purpose more effectively?
- What delay, duplication, or administrative burden does the mechanism create?
- What essential control would be lost if it were removed?
- Should the mechanism be eliminated, simplified, merged, automated, or replaced?
Adapting Architecture Methods and Ways of Working When They Stop Supporting Good Decisions
- Which architecture methods or practices are creating effort without improving decisions?
- What changes in organizational structure, delivery model, or technology have made the current approach less useful?
- Which steps exist mainly because of historical process rather than current need?
- Where are teams bypassing the method because it does not fit how work is actually done?
- What evidence, decisions, or controls must remain even if the method changes?
- What lighter or more distributed approach could achieve the same architectural outcome?
- How will we test whether the revised way of working improves both decision quality and usability?
Developing Architecture Capability and Professional Coherence Across a Distributed Practice
- What knowledge and judgment should every architect in the distributed practice share?
- Which specialist capabilities should remain differentiated by role or domain?
- Where are inconsistent architecture practices causing conflicting decisions?
- What communities, peer reviews, mentoring, or shared learning mechanisms would improve coherence?
- How can architects learn from one another without creating unnecessary central process?
- What evidence would reveal genuine capability gaps rather than simply differences in style?
- How should professional development evolve as architecture responsibilities become more federated and embedded?
Recovering an Enterprise Architecture Practice That Has Become a Documentation or Approval Exercise
- What evidence shows that the EA practice has become focused on artifacts or approvals rather than enterprise outcomes?
- Which architecture activities consume the most effort without changing meaningful decisions?
- Why do stakeholders engage with EA only when required rather than because it helps them?
- Which consequential decisions are happening outside the architecture process?
- What documentation, reviews, or governance steps can be removed or simplified immediately?
- What decision support, dependency insight, roadmap, or strategic work should replace low-value activity?
- What measurable change would show that the EA practice has become useful to the enterprise again?