https://pubs.opengroup.org/togaf-standard/adm/chap01.html#tag_01_05 Four dimensions are typically used in order to define and limit the scope of an architecture: Breadth: what is the full extent of the enterprise, and what part of that extent will this architecting effort deal with? Many enterprises are very large, effectively comprising a federation of organizational units that could validly be considered enterprises in their own right The modern enterprise increasingly extends beyond its traditional boundaries, to embrace a fuzzy combination of traditional business enterprise combined with suppliers, customers, and partners Depth: to what level of detail should the architecting effort go? How much architecture is "enough"? What is the appropriate demarcation between the architecture effort and other, related activities (system design, system engineering, system development)? Time Period: what is the time period that needs to be articulated for the Architecture Vision, and does it make sense (in terms of practicality and resources) for the same period to be covered in the detailed Architecture Description? If not, how many Transition Architectures are to be defined, and what are their time periods? Architecture Domains: a complete Enterprise Architecture Description should contain all four architecture domains (Business, Data, Application, Technology), but the realities of resource and time constraints often mean there is not enough time, funding, or resources to build a top-down, all-inclusive Architecture Description encompassing all four architecture domains, even if the enterprise scope is chosen to be less than the full extent of the overall enterprise