TOGAF's ADM runs the same basic method across Phase B (Business Architecture), Phase C (Information Systems Architecture: Data and Application), and Phase D (Technology Architecture). What is that shared method, and what concretely does each phase produce that Phase E (Opportunities & Solutions) needs to do its job?

## Three phases, one method Phases B, C, and D of the ADM — Business Architecture, Information Systems Architecture (which itself splits internally into Data Architecture and Application Architecture), and Technology Architecture — are structurally identical in method even though they operate on different subject matter, and understanding that shared method is the key to understanding why TOGAF organizes the middle of the ADM this way. ## The shared method The shared method has three steps, repeated once per phase. 1. **First, describe the Baseline Architecture**: what actually exists today in this domain. - In Phase B that means current business processes, organizational structure, business capabilities, and governance. - In Phase C it means the current data entities and their relationships, plus the current application portfolio and how applications map to business functions. - In Phase D it means the current technology platforms, infrastructure, and the technology standards actually in force. 2. **Second, describe the Target Architecture**: the desired future state in that same domain, derived from the Architecture Vision set in Phase A and refined with more domain-specific detail than Phase A's high-level sketch had room for. 3. **Third, perform Gap Analysis**: a structured comparison of Baseline against Target that produces an explicit list of gaps — capabilities or components the Target needs that the Baseline lacks, and things the Baseline has that the Target doesn't need and should be retired or consolidated. TOGAF is explicit that gap analysis should be systematic rather than impressionistic: a common technique is to build a matrix of architecture building blocks against baseline/target presence, so gaps aren't a vague narrative but an itemized, traceable list. ## Why repeat it three times Why repeat the same method three times instead of doing one big analysis across everything at once? Because the domains genuinely differ in what 'baseline' and 'target' even mean concretely, and in who has the expertise to assess them: | Phase | Who assesses it | |---|---| | **Phase B** | business analysts and process owners | | **Phase C** | data modelers and application portfolio owners | | **Phase D** | infrastructure and platform engineers | Forcing them into one undifferentiated analysis would blur accountability for closing each kind of gap. Running the same method three times with the same rigor also means the outputs are structurally comparable to each other — three gap lists in the same format — which matters a great deal for the next phase. ## What Phase E does with the output That next phase, Phase E (Opportunities & Solutions), is where the payoff of doing B, C, and D as parallel, structurally consistent exercises shows up. Phase E is the first point in the ADM that starts thinking in terms of implementation rather than pure architecture description: it takes the accumulated gap lists from B, C, and D, along with the updated Architecture Definition Document each phase produces, and groups related gaps into logical **Work Packages** — coherent bundles of business, data, application, and technology change that make sense to deliver together as one project or initiative. This is also where build-vs-buy decisions, dependency analysis between work packages, and an initial cut at **Transition Architectures** (intermediate states between Baseline and the ultimate Target) get done. None of that is possible if B, C, and D produced their gap analyses in inconsistent formats or at mismatched levels of granularity — Phase E would have nothing coherent to group. ## The trade-off The trade-off of this three-times-repeated method is thoroughness against cost and calendar time: doing a rigorous baseline/target/gap cycle in each of three domains, with the right domain experts engaged each time, is significantly more expensive than a single lightweight current-vs-future sketch, and for a small, narrowly-scoped engagement it can be overkill — which is why TOGAF explicitly allows tailoring when the engagement's scope doesn't touch that domain meaningfully. ## What goes wrong in practice A concrete failure mode: a team runs Phase D's technology gap analysis with real infrastructure engineers producing a detailed, itemized gap matrix, but runs Phase C's data/application gap analysis as a rushed slide with vague bullet points because 'the data team was busy.' When Phase E tries to group gaps into work packages, the technology gaps are specific enough to scope and estimate, but the application gaps are too vague to bundle meaningfully — so Phase E either stalls, or proceeds with under-specified application work packages that blow their estimates once implementation starts. ## Where it shows up A worked example: a retailer replacing its point-of-sale platform runs Phase B to baseline current store-associate workflows against a target of unified in-store/online checkout; Phase C to baseline the current POS application and its data model against a target application and shared customer/inventory data model; and Phase D to baseline current in-store hardware and network against a target cloud-connected terminal fleet. Phase E then groups 'new checkout workflow,' 'shared inventory data model,' and 'network upgrade for cloud connectivity' into one linked work package, because the gap analyses from all three phases were specific enough to show those three gaps depend on each other.