Book a Demo

Please note : This help page is not for the latest version of Enterprise Architect. The latest help can be found here.

Prev Next

Scope of Architecture

Architectures will only be successful if they are scoped correctly. The Enterprise Architecture Body of Knowledge (EABOK) describes three important aspects of scope, but another one can be added that addresses the importance of the stakeholders in the success of the architecture program and the architectures it creates and manages:

  • Time Scope
  • Organization Scope
  • Detail Scope
  • Stakeholder Scope

Architecture time frames, organizational context, levels of detail and appeal to stakeholders must all be appropriately set for the architecture to be relevant and successful. Enterprise Architect has tools that support all of these types of scope, from the Roadmap overlay feature for time modeling, the Organization chart to show which parts of the enterprise will be affected, and the wide range of diagrams and matrices that can be used to allow stakeholders to visualize the architectures at the appropriate level of detail.

Time Scope

Time Scope is important because the business typically works in cycles, and it is critical that the architectures respect this time dimension of the organization's management and operation. Strategic plans for medium to large enterprises typically span a period of between three and five years, so it is common for strategic architectures to describe a similar time period, while implementation projects typically run for a period of between three and twelve months. Tactical architectures that group a number of implementation projects can span a period of between one and two years.

Enterprise Architect has some useful features that can help with managing time, including the Roadmap overlay that allows a time scale and extent to be defined and that can indicate the phases any element passes through set against the backdrop of that timescale. The tick spacing can be set from days up to years, allowing any time extent to be represented. Any architectural elements can be represented on Roadmap diagrams, including architectures themselves, principles, capabilities, applications, information, technology devices and more.

The flexibility of the overlay allows any diagram to be converted into a Roadmap, and there is a wide range of settings that can be used to configure the visualization of the Roadmap, including the Diagram Legend, which can be used to define the segmentation of the elements into a series of phases. The Roadmap Options can be used to change the time scale from years, quarters, months, or days down to very fine graduations (used for engineering diagrams). The start and finish times can be set, and the scale can be changed to stretch or collapse the time scale. The position and height of the time ruler can be changed, and fonts and colors can all be configured to make the diagrams more appealing.

The Roadmap Options dialog in Sparx Systems Enterprise Architect.

Detail Scope

Selecting the correct level of detail for an architecture is critical to its success; this is particularly true when it comes to the Implementation teams. Creating architectures that are too lofty or aspirational will result in Implementation teams making important design decisions themselves which, while they might be appropriate for their solution, might not be the best outcome for the entire enterprise. On the flip side of this argument, creating architectures that are too prescriptive and detailed can constrain an Implementation team and result in the team not having the flexibility to select the best solution.

Enterprise Architect is a tool based on the concept of collaboration, and there are many facilities that will help the architecture team members work with each other and with all stakeholders, including implementation teams, to determine the most appropriate level of detail for the architectures. The Model Library facility allows in-model reviews to be created, where elements from the architectures such as Goals, Objectives, Applications, Technology nodes and more can be dragged in as references for the reviews. The Discuss & Review and Discuss & Review - History windows allow architects and stakeholders to deliberate about the architectures and the consequent implementations. The Diagram Filtering facility and a wide range of tools for changing the visualization of elements in diagrams allow the appropriate level of detail to be set for the architectures and the views that are created for stakeholders.

The Element Discussion facility can be used to discuss requirements, in Sparx Systems Enterprise Architect.

Organization Scope

Enterprise Architecture is a non-trivial and costly discipline, and it is critical that value is delivered to the business. The best outcomes will be achieved if the architecture touches all parts of the enterprise, but it is quite common for some parts of the enterprise to receive greater emphasis in the architectural descriptions than others. Having a clear understanding of the structure of an enterprise and its organizations and how strategic plans relate to this structure is critical for the success of any enterprise architecture effort.

Enterprise Architect has an Organizational Chart within the Strategic Modeling Technology, which can be used to model the structure of an enterprise and its organizations. The architectures can be related to this structure, which allows the organizational scope to be visualized.

Stakeholder Scope

The stakeholders and the shareholders or organization owners that they represent are the ultimate beneficiaries of the enterprise architecture, and it is important that the right stakeholders are selected and communication is managed to ensure they are kept updated with the progress of the architectural work and the governance of the Implementation Initiatives.

Enterprise Architect has a number of facilities to ensure that the stakeholder scope is determined and that the architectures are created in accordance with what these individuals or groups require. The stakeholders themselves can be modeled inside the tool and their relationship to elements such as Drivers, Goals, Objectives, Applications and Architectural Requirements can be maintained. This allows impact analysis to be visualized, so that when changes occur that affect any of these elements, the stakeholders who have an interest in the change can be determined. The visualization can be through diagrams, matrices or lists of elements and can be viewed directly in the model, or publications can be generated in a variety of formats including PDF, DOCX and Web Pages.

Example Component diagram representing stakeholders, in Sparx Systems Enterprise Architect