EA views
A guideline to help entities develop EA views by defining view types and detail levels and providing examples they can use.
A guideline to help entities develop EA views by defining view types, detail levels, and providing practical examples.
In brief
Views present EA components in different forms depending on purpose and audience.
They are based on building blocks, attributes, and relationships in the general component model.
They help manage and document current and target state in the EA tool.
About this document
This document provides a guideline to help entities develop EA views by defining view types and detail levels and offering examples they can use.
Document objectives
The document aims to provide a guideline that helps entities build EA views of all types (catalog, matrix, visual representation) for all EA domains, and to present the results of documenting and analysing EA components to stakeholders. It helps to:
Help government entities develop their own EA views to meet stakeholder needs across all EA domains.
Present the results of documenting and developing EA components (EA artifacts) to the right stakeholders.
Support the setup of tools used to document and develop EA components (EA tools) in entities.
Types of EA views
EA views fall into three main types:
Catalog
A view that lists EA components built from the same building block and lists their attributes and/or related building blocks.
Matrix
A view that shows the relationship or linkage between two or more EA components, where one component can relate to many others.
Visual representation
A view that shows the relationship or linkage between a set of EA components through a visual display.
Detail levels of EA views
Each view reflects a different level of detail. Levels are:
Conceptual level
The highest level of representation for documenting building blocks. Often used for visual representations or catalogs. Focuses on high-level concepts and core requirements. Examples: business value chain, data landscape, application landscape.
Logical level
More detailed than conceptual, less than physical. Often used for visual representations. Focuses on moderate detail on component attributes and relationships. Examples: integration landscape, network diagram.
Physical level
The most detailed level. Often used for catalogs or matrices. Focuses on detailed component and relationship information. Examples: data warehouse catalog, virtual server catalog, network device catalog.
List of EA views (sample)
A sample of core views by EA domain, view type, and detail level:
Conceptual level
Logical level
Physical level
Conceptual level
Logical level
Physical level
Stakeholders
Define the list of stakeholders with whom EA views will be shared, based on their requirements and needs (the same view may be developed for more than one group). Study each target stakeholder group to choose the right view and the right level of detail so that views support decision-making or raise awareness of EA components and maximise the value of EA outputs.
Methodology for sharing views with stakeholders
The EA office develops EA views according to an agreed plan that defines how EA outputs are shared with stakeholders. Steps:
Identify stakeholder requirements
Identify the requirements and needs of target stakeholders from different departments through meetings and capture their views on the data they need and why, and ensure the required data exists in the general component model for views that support decisions or awareness.
Design EA views
Design EA views to meet the requirements of each target stakeholder group from across the entity (the same view may be developed for more than one group) in all EA domains.
Define communication channels
Define the channel for each target stakeholder group through which EA views are shared, or by granting access to view data on the EA tool if available.
Govern and update view versions
Control the release of updated versions of EA views by reflecting target stakeholder feedback and their views in line with their work context.
Continuous improvement
Continuously review and assess EA views and collect stakeholder feedback to ensure their needs are met and to incorporate their suggestions for ongoing improvement of EA outputs.
EA view details
The document details EA views per domain by defining the following attributes for each view:
View description: a short summary of the view and main building blocks, and the view type (catalog, matrix, or visual).
Detail level: conceptual, logical, or physical.
Potential uses (benefits): e.g. an overview of building block(s) and their links, awareness activities, design and development work.
Stakeholders: the target stakeholders for the view, internal and external (senior management, staff, beneficiaries, development and design teams).
Related building blocks: the building block(s) included in the view.
Examples of views and how to document them
A sample of views used to document application architecture (catalogs, matrices, visual representations):
Application architecture catalogs
Application catalog
Aims to list all applications and their descriptive data.
Technical integration points register
Aims to list all internal integration points between applications and external points with other entities.
Application architecture matrices
Application/organisational unit
Aims to show the link between organisational units and the applications they use to digitise their operations and services.
Application/business service
Aims to show the link between applications and the services they deliver.
Visual representations for application architecture
Application landscape
Aims to show a diagram of all entity applications, giving an overview by application area.
Integration landscape
Aims to show a diagram of all internal and external integration points between entity applications and external entities, and the type and method of integration.
Link to the general component model
Each view is built from the building blocks and attributes defined in the general component model. Ensure views align with the model adopted in your entity.