# Scope of the EA Framework
The scope for Government of Rwanda Enterprise Architecture Framework includes the following:
• Architecture Development Methods (ADM)
• Architecture Content Management
• Enterprise Architecture Tools
# Architecture Development Method (ADM)
The Architecture Development Method (ADM) describes how the artefacts that enterprise architecture will document and maintain.
**NOTE:** *Each entity within the government of Rwanda will define its own enterprise architecture following the standards that the RGEA has defined. The term ‘Government-wide’ Enterprise Architecture refers to the set of common EA standards, principles and building blocks that each entity will need to define in developing respective architectures.*
The scope for the ADM therefore covers the following areas:
1. **Business Architecture: **This includes the definition of:
- ***Business Strategy (****Business Direction Model*) – This include the following:
- **Business drivers **such as government mandates, legislative requirements, ministerial decrees, strategic goals and initiatives
- **Strategic objectives **of the organization
- **Business requirements.** Closely aligned to the strategic objectives, these are the requirements for business to meet the strategic objectives
- **Business services** – a list and description of the services that the business delivers to its customers (these include both internal and external customers such as the citizenly)
- **Core Business Processes** – within the scope of this programme, only core business processes will be mapped. These are processes that are aligned to specific business units or service e.g. Birth Registration, Local Government Inspection etc. The processes will not be document to the activity detail level for this programme.
- **Business Location** – it is understood that each public entity has offices spread over wide geographical areas and offering differentiated yet related business services. To understand the levels of collaboration between the functional units over such areas, it is necessary to model the services, processes, and technology based on the area of
- use. For Example, Data Capturing may be undertaken using a manual form in a rural area and thereafter be recaptured on a system at the head office.
- **Business Function **– the function that each business unit performs and their resultant responsibility for processes, services, and technology
- **Business Roles / Actors** - this assigns responsibility of each service, process or technology to a role or an actor. Each process, a RACI should be defined. Thus, for each process there will be someone who is either Responsible (R), Accountable (A), Consulted (C) or Informed (I) for its execution
- **Stakeholders** – these are entities that have vested interest in the operations to the organization. They influence policy and have power to either enable or derail the enterprise architecture initiative
- ***Business Process Modelling*** – Only core business processes will be documented for this programme. These will include both manual and automated processes. Please refer to the Government *of Rwanda EA Standards.docx* for description of applicable business process modelling standards. The core business processes will be mapped against the core business objectives.
2. I**nformation Systems Architecture **
- ***Documentation of the Application Landscape.*** This includes the development of an application catalogue. This is an asset that documents all the attributes of the information systems within a given environment complete with all the needed attributes for each application (refer to *Government of Rwanda Application Catalogue Template.xls*). Apart from cataloging the applications in the environment, it is a helpful asset that will assist IT managers in making future IT investment decisions through a clear assessment of the lifecycle of each system, required support, system integration matters and process automation.
- **NOTE:** *This does **NOT** include Software / System Architecture modelling i.e. a detailed architecture modelling of a specific system. The scope for the Government-wide EA project is to document interrelationships between disparate systems and present a view of the application landscape.*
- ***Data Architecture –*** for this project, the data architecture does **NOT** include data modelling. The architecture documentation will seek to identity the data sources for each entity, data structures, shared data across entities to enable integration and data management (including data storage, back-up)
3. **Technology Architecture: - **This will cover the infrastructure landscape including a list of servers, Type of Network, Data Storage Types, and communication protocols.
The deliverables for this will present blueprints for each entity with the following key elements:
1. **Baseline view (As-Is view): **this will present the current view of a given environment
2. **Target view (To Be view):** this will describe the desired state of the environment taking into account the future strategic initiatives and IT capabilities that need to be put in place to meet these initiatives
3. **Gap Analysis:** this will overlay the Target (To Be) view over the Baseline (As Is) view to show the gaps that need to be filled as the organization transitions into the Target state
4. **Roadmap:** this will prioritize the initiatives that must be undertaken to aid the organization transition from the Baseline (As Is) to the Target (To Be) state
# Architecture Content Framework
The content framework for the Government of Rwanda Enterprise Architecture covers the following areas:
1. Architecture Meta Model
2. Architecture Building blocks
3. Architecture Deliverables
# Enterprise Architecture Notation
Government of Rwanda has selected ArchiMate as a notation for enterprise architecture modelling. Models will be developed and stored within Sparx Enterprise Architect using the ArchiMate Notation.
##### **Architecture Meta-Model**
Effective enterprise architecture documentation entails the use of common standards that are easily applied and understood by both architects and target audience. To this end, apart from defining the enterprise architecture framework – which outlines the artefacts or primitives that need to be modelled
– there is also a requirement to define the relationship between these artefacts which are shared across the domains.
This relationship is defined using a Meta-Model. TOGAF has defined meta-model as:
*“a precise definition of the constructs and rules needed for creating models.”*
It further states that a meta model is:
*“a model that describes how and with what the architecture will be described in a structured way”*
As stated above, the government of Rwanda has adopted and modified TOGAF for its architecture implementation. By extension, the TOGAF Meta model has also been adopted and modified to ensure that it is truly aligned to the needs and requirements of government or Rwanda
The prime role of the Meta Model is to provide definition and relationship between all artefacts and building blocks that make up enterprise architecture.
[](https://guidelines.risa.gov.rw/uploads/images/gallery/2025-10/BNQimage.png)
To facilitate this process, the government of Rwanda has adopted the use of *ArchiMate *notation. To this end, the Meta Model covers four layers namely:
##### **Business Layer Meta-Model**
This cover phases A and B of TOGAF ([*Figure 2*](#_bookmark2)) i.e. Architecture vision and Business Architecture. The Business Layer Meta Model for the RGEA is depicted below.
[](https://guidelines.risa.gov.rw/uploads/images/gallery/2025-10/wSximage.png)
##### **Business Layer Objects**
[](https://guidelines.risa.gov.rw/uploads/images/gallery/2025-10/tnvimage.png)
[](https://guidelines.risa.gov.rw/uploads/images/gallery/2025-10/II9image.png)
##### **Information System Layer Meta Model**
This covers the definition and usage of application and data concepts
[](https://guidelines.risa.gov.rw/uploads/images/gallery/2025-10/U3Mimage.png)
##### **Information Systems Layer Objects**
[](https://guidelines.risa.gov.rw/uploads/images/gallery/2025-10/1Egimage.png)
[](https://guidelines.risa.gov.rw/uploads/images/gallery/2025-10/tITimage.png)
##### **Technology Architecture Layer Meta Model**
This covers the definition and usage of Technology concepts
[](https://guidelines.risa.gov.rw/uploads/images/gallery/2025-10/kU2image.png)
##### **Technology Layer Objects**
[](https://guidelines.risa.gov.rw/uploads/images/gallery/2025-10/xs4image.png)
[](https://guidelines.risa.gov.rw/uploads/images/gallery/2025-10/YyFimage.png)
# Architecture Building Blocks
Success of enterprise architecture projects hinges on a number of things. Key among many dependencies is the establishment of sound building blocks for EA implementation.
Building blocks, by definition, are critical elements that lay the foundation for the success of the initiative. These represent both abstract building blocks such as Governance Structure, Standards, Principles, IT Roadmap or Strategy etc as well as physical artefacts such as Databases, Servers, applications, and skilled resources.
In a nutshell, building blocks form the foundation on which enterprise architecture implementation will be based.
The following are some of the key building blocks for the Government of Rwanda Enterprise Architecture:
- Enterprise Architecture Governance model (refer to ‘***Government of Rwanda Enterprise Architecture Governance.docx***’)
- Enterprise Architecture Principles (refer to ‘***Government of Rwanda Enterprise Architecture Principles.docx’***)
- RGEA Meta Model ([*Figure 6: **Government of Rwanda EA Meta-model layers***](#_bookmark13))
- RGEA Framework ([*Figure 3: **The Rwanda Government-wide Enterprise Architecture Framework ***(RGEA)](#_bookmark3)
- Enterprise Architecture documentation guideline (***Government of Rwanda Enterprise Architecture Guide.docx)***
# Architecture deliverables
The deliverables of enterprise architecture projects will be the Blueprints for each government entity. The blueprints will be developed based on the architecture methodology and architecture standards.
Refer to the following documents for information pertaining to the development of the blueprints:
- *Government of Rwanda Enterprise Architecture Governance.docx* – This outlines the governance structures that will drive the implementation of enterprise architecture across Government of Rwanda
- *Government of Rwanda Enterprise Architecture Principles.docx* – This outlines the guiding principles that will drive the enterprise architecture initiatives
- *Government of Rwanda Enterprise Architecture Standards.docx* – This outlines the architecture standards that each initiative will need to adhere to
- *Blueprint Development Guidelines for Government of Rwanda Enterprise Architecture.ppt* – this describes systematic instructions on how to undertake an enterprise architecture assignment
# EA Tools
The Government of Rwanda has procured *Sparx Enterprise Architect* for documenting enterprise architecture models. The choice of *Sparx Enterprise Architect *is driven by the tool’s robust functionalities that not only support multiple architecture models, but also its ability to re-use objects within the shared Object repository.
The other tools that will be used are listed below:
1. Architecture Modelling: ***Sparx Enterprise Architect***
2. Artifact Library / Repository: ***Sparx Enterprise Architect***
3. Reporting: ***Microsoft Word***
4. Data Capturing: ***MS Excel***
5. Presentation: ***MS Powerpoint***
6. Notation: ***ArchiMate and UML Notation***
Refer to *Blueprint Development Guidelines for Government of Rwanda Enterprise Architecture.ppt*
# Reference Models
Application Reference Model
It is acknowledged that public entities fall within different industries and therefore have different and unique requirements. These requirements inform the structure and arrangement of some of the attributes that respective entities have. As such, therefore, there will be different reference models for each industry / cluster.
One of the important reference models that will need to be developed for each cluster will be the application Reference Model.
The application reference model presents a structure view of the applications that each entity uses in relation to the business requirements. The model reflects core capabilities and the applications that are
used within and organization as well as the enterprise wide application needs which are viewed as organization enablers. Below is a diagram of a sample application reference model.
[](https://guidelines.risa.gov.rw/uploads/images/gallery/2025-10/fJqimage.png)
[](https://guidelines.risa.gov.rw/uploads/images/gallery/2025-10/VFGimage.png)The top-level view of the model merely depicts the capabilities of respective applications per business / functional areas. Concealed within the top level view are the actual names of applications. While this diagram is important and conveys important information, the real value comes from the ability to conduct impact assessment for each application. This view provides a strong foundation for determining the extent at which an application is used within the environment.
Within *Sparx Enterprise Architect* and indeed any other repository-based enterprise architecture toolset, it is possible to select an artefact such as an application and view all other entities that are associated with it. In this case, the application reference model will enable decision makers to see the business areas and services that utilize a specific application. In that way, when change is being considered for any given application, decision makers are able to see the impact that change will have on all related business units and services.
##### **ESB**
Refer to the document *Government of Rwanda Enterprise Architecture ESB Reference Model.DOCX*
##### ***Security***
Refer to the document *Government of Rwanda Enterprise Architecture Security Reference Model.DOCX*
# Artefacts to be produced
The following will make up the deliverables of the enterprise architecture project in each entity:
1. Conceptual Model – shows alignment of all architecture domains
2. Business Direction model view
3. Business Process Models:
4. Business Service catalogue (High level)
5. Application Catalogue
6. Application Models:
7. Technology models
8. Matrices
- - Application to Business Process / Service Matrices
- Application to Technology Matrices
- Application to Database Matrices