This site uses cookies to improve your experience and analyze visits.
The EA development cycle tasks as NORA describes them, from scope definition through to ongoing requirements management.
| Stage | Main Tasks |
|---|---|
| Stage 1: Defining the scope of the EA development cycle | Study and assess EA development requirements, frame the scope horizontally (capabilities, organisational units, beneficiaries, applications, data, infrastructure components) and vertically (domains, components, viewpoints, stages), then approve the requirements and scope in the development cycle charter. |
| Stage 2: Diagnosing the current state | Detail the scope per domain, inventory EA data, document the current components and viewpoints, then analyse the current state and issue recommendations for each domain on its own. |
| Stage 3: Studying future trends | Agree on the future direction for each EA domain, study international experience, standards, and best practices, and identify the national requirements that shape those directions. |
| Stage 4: Designing the future state | Draw an initial future view for each domain, align them with each other, and detail the future components and viewpoints in a way that meets the cycle objectives set in Stage 1. |
| Stage 5: Analysing EA gaps | Compare current and future states across domains, identify gaps and their intersections, weigh their impact, and design fitting solutions in line with the directions and the entity's priorities. |
| Stage 6: Building the roadmap to the targets | Derive the list of initiatives and projects that close the gaps, rank them by importance and dependency, and build an integrated roadmap that develops the domains in line with the entity's goals. |
| Stage 7: Managing EA requirements | A continuous stage: document EA requirements in a central register, manage their states from creation through delivery or closure, and track them through a digital EA tool. |
Review requests and needs reaching the EA unit, check they are new, set the assessment criteria, then agree with stakeholders on whether to launch the cycle.
Set the horizontal scope (capabilities, organisational units, beneficiaries and journeys, applications, data entities, technology and security components) and the vertical scope (domains, components, viewpoints, and the chosen stages).
The chief enterprise architect reviews the scope with stakeholders, signs off the development cycle charter (objectives, stages, timeline, roles), and the EA team updates the request repository.
The domain architect pulls the relevant requirements from the cycle charter, picks the components and viewpoints needed, and agrees with stakeholders on how inputs will be collected.
Build data-collection templates, identify sources, pull what is already available, and coordinate with stakeholders to fill gaps or verify accuracy.
Build the domain components (such as business capabilities, organisational units, services, and processes) and develop the required viewpoints, including value chain, service catalogue, and process maps.
Analyse the documented outputs, single out weaknesses and improvement areas, and write domain-level recommendations that feed the future-state design.
