Government of Rwanda Enterprise Architecture Framework

• Acronyms
• Glosary Terms
• Background
• Purpose
• Enterprise Architecture Domains
• Enterprise Architecture Drivers
• Scope of the EA Framework
• Architecture Development Method (ADM)
• Architecture Content Framework
• Enterprise Architecture Notation
• Architecture Building Blocks
• Architecture deliverables
• EA Tools
• Reference Models
• Artefacts to be produced
• ANNEXTURE

Acronyms

Glosary Terms

 

Background

The government of Rwanda has embarked on a project to establish and implement enterprise architecture (EA) in public entities with the end goal of establishing common architecture standards across all ICT functional units.

This will in turn assist the government in fostering synergies between entities within and across defined clusters. The government has identified the following as some of the topical issues that enterprise architecture will seek to resolve.

1. Poor support for business needs – in some sectors, the ICT function has been found to be misaligned with the needs of the business. This is largely because the ICT capabilities have been developed without direct reference to the business requirements
2. Lack of coordination – Projects undertaken within some of the entities are not properly coordinated resulting in wasteful expenditure when some resources could have been re-used or shared
3. Inaccurate scoping of projects – without a reference point on the ICT and business landscape, projects are scoped based on assumption of the impact and resources needed to deliver. This has in some cases let to inaccurate project scoping.
4. Lack of integration and interoperability – although there are some shared services across some of the public entities, it has been found that their respective ICT functional units have had minimal collaboration. The close association between some of the public entities calls for more integration
5. Low quality service delivery – some complaints around quality of service delivery is attributed to lack of coordinated planning due to the absence of reference point of the current business or ICT landscape. This is the gap the enterprise architecture seeks to fill.

It is acknowledged that within each government entity, some of the building blocks that make up enterprise architecture are in existence. The challenge, however, is that their development and arrangement has not been properly coordinated with the use of common standards and therefore fail to provide the added value that the business should be deriving from them.

 

 Addressing the abovementioned challenges requires a structured approach. Within the Enterprise Architecture practice, both methodologies, standards, principles, governance and EA framework drive the structured approach. The selection of each of these requirements is important as care must be taken to ensure that the asset that is selected meets the requirements and capabilities of government of Rwanda.

There are a number of frameworks available that could have been chosen to drive this initiative. However, not all of them meet the requirements of Rwandan Government. The framework that has been chosen is The Open Group Architecture Framework (TOGAF) because its completeness and applicability.

The selection of TOGAF is based on the appreciation that the framework not only covers are all the required architecture domains but also presents an iterative approach to implementation of enterprise architecture.

 

However, although TOGAF is robust, it is still too complex. The decision was therefore taken to customize the framework to meet the requirements of Rwanda. This decision resulted in the development of the Rwanda Government Enterprise Architecture Framework (RGEA).

Through this modified framework, the core artifacts that are needed to develop enterprise architecture for Government of Rwanda entities are organized per architecture domain to show the horizontal and vertical alignment with other domains.

 

Purpose

The purpose of this document is to provide guidance to enterprise architecture practitioners within government of Rwanda on the application of the enterprise wide architecture framework. The document unpacks the elements that make up the Enterprise Architecture framework and describes their interrelationships as well as the deliverables that the programme seeks to produce.

The Government of Rwanda Enterprise Architecture framework (Figure 3) has been modified to make it generic for applicability within all government institutions. It provides building blocks that will enable IT executives to not only document their architectures but also provides inputs for the development of other assets such as ICT Plans, ICT roadmaps, Investment plans etc. To this end, therefore, the framework will guide IT in positioning itself in developing capabilities that will ensure seamless IT-Business alignment.

Enterprise Architecture Domains

As stated above, enterprise architecture seeks to address business requirements that would bring added value to the organization and its target customers. To achieve this, leading practice has identified five interlinked domains that make up enterprise architecture. These are Business, Information, Data, Application, and Technology Architecture domains.

The modified Government of Rwanda Enterprise Architecture Framework has combined some of the closely aligned domains so that the view is made up of the following three core domains:

1.      Business Architecture – This is the apex architecture domain as it sets the requirements for the other supporting one. Within the Business Architecture domain, the organization’s strategic mandate is defined and this sets the foundation for business requirements that the other architecture domains seek to address. Within the business architecture domain, therefore, the following elements are defined: Business strategy, governance, organisational structure, Business Rules, key business processes, business locations and services. These set the direction for the organisation which IT seeks to enable. The following domains which have a technical focus in nature, therefore, are designed to enable the business architecture objectives.
2.  Information Systems Architecture – the processes that are defined within the business architecture domain need both human and system interventions to execute. In some cases the processes are fully automated while in some the mix of manual and automated processes occur. It is therefore important that relationship between business processes / services and systems be clearly defined.

This association of the process with systems is reflected both within the business and application architecture domains.

The application domain itself has a close association with the data and information architecture domains. Thus the application uses data from the databases and either presents or transmits via some protocol.

Because of this close association between the three domains, The Application, Data and Information domains have been grouped together within the Information Systems Architecture Domain.

• Application Architecture – Defines and documents artifacts for the Application systems in each environment, their interactions, and their relationships to the core business processes of the organisation. It documents the user interfaces, applications and their attributes, associations between different application etc.
•  Data Architecture – defines the Data sources, usage of the data, users of the data, owners of the data, location of the databases, reporting tools, data classification etc.
• Information Architecture – Defines the Information Lifecycle Management, documents, information transfer protocols, data classifications etc.

3. Technology Architecture – This documents the hardware & software capabilities required to support deployment of business, data, and application services.

Enterprise architecture seeks to bring seamless alignment of the abovementioned domains to deliver value to the customer. Thus in documenting end to end architecture for each entity, an association will be made between business services and business process which in turn will be mapped to the application that automate the processes (as well as the role or actors that are responsible for its execution).

Similarly, every application has to map back to the data sources where it stores and retrieves data from.

The infrastructure that support the systems has also to be mapped to the resultant technologies. This seamless alignment is depicted in Figure 4.

 

Enterprise Architecture Drivers

Listed below are some of the business requirements and drivers that make a case for Enterprise Architecture.

•  Legislation: - Legislations change frequently. An agile enterprise architecture ensures that organizations comply with changing legislation easily by imbedding legislation and rules into everyday business processes execution and technology enablement. It also follows that the requirement to comply with pieces of legislation has a direct influence on the type of service and process that an organization delivers.
• Government Mandate: - Acts of Parliament and government mandates must be complied with. These are some of the strongest drivers for enterprise architecture because they trigger specific processes.
• Strategic Goals (Business and IT Alignment): - Arguably the most important value of enterprise architecture is that it ensures the alignment of IT capabilities with business requirements. This is achieved through the seamless alignment of Business Architecture domain with the Information
• Systems Architecture and Technology domains (refer to Figure 4). ICT needs to align itself to the strategic goals of the organization.
• Enable decision making and change management: - Properly defined, documented, and implemented enterprise architecture will assist executives in making informed decisions by highlighting the relationships between various elements that work together in the delivery of services or products and showing what the impact of a change in any one of them would have on the other related elements.
• Improve Operational efficiency and productivity: - One of the key values to be derived from enterprise architecture is the ability to assist organizations in making changes that will streamline operations, reduce unwanted redundancies and optimize operational activities.
• Cost Reduction: - Agile enterprise architecture streamlines processes, people and technology to efficiently and profitably manage the delivery of services and products through process improvement, technology rationalization and portfolio management, and through effective definitions of roles and responsibilities
• Improved integration and operability: - As blueprints for each organization are being developed, entities will be able to see how best they can integrated with others within the same cluster. This is because the blueprints will show the landscape for each entity which will include the technologies and services. As such, common and related services will be made clearer and decisions on the use of specific technologies. The need for improved integration is therefore another important driver for enterprise architecture because the result is optimization of the use of available resources.
• Proper project planning: - By making the baseline (As Is) view of the enterprise clear, enterprise architecture enables better planning for projects as decisions makers are able to see not only the impact that a project would have, but also see and re-use what is already in the environment before a decision to either build or buy is made.

Scope of the EA Framework

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. Information 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.

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) i.e. Architecture vision and Business Architecture. The Business Layer Meta Model for the RGEA is depicted below.

Business Layer Objects

Information System Layer Meta Model

This covers the definition and usage of application and data concepts

Information Systems Layer Objects

Technology Architecture Layer Meta Model

This covers the definition and usage of Technology concepts

Technology Layer Objects

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)
• RGEA Framework (Figure 3: The Rwanda Government-wide Enterprise Architecture Framework (RGEA)
• 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.

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

ANNEXTURE

The Government of Rwanda Enterprise Architecture Framework is limited in what it can contain. Trying to put everything that is relevant for the development of enterprise architecture artefacts in one document would be an over-kill and would fail to add value. This is largely because some of the complementing information falls within different – though closely related – disciplines. As such, different material will apply in reference to specific elements of the projects.

It is therefore necessary to develop the related material in separate documents and make reference to them. These will only apply when the need arises.

The following sections lists the material that should be used in conjunction with the Government of Rwanda Enterprise Architecture Framework.

1. Government of Rwanda Enterprise Architecture Governance.docx – This outlines the governance structures that will drive the implementation of enterprise architecture across Government of Rwanda
2. Government of Rwanda Enterprise Architecture Principles.docx – This outlines the guiding principles that will drive the enterprise architecture initiatives
3. Government of Rwanda Enterprise Architecture Standards.docx – This outlines the architecture standards that each initiative will need to adhere to
4. Blueprint Development Guidelines for Government of Rwanda Enterprise Architecture.ppt – this describes systematic instructions on how to undertake an enterprise architecture assignment
5. Government of Rwanda EA Matrices Template.xls – this includes templates for matrices that will allow managers conduct impact assessment before change is implemented. The templates show the relationship between different architecture domains. The following matrices are included in the documents:

• • • Application to Business Service Matrix
    •  Application to Business Process Matrix
    • Application to Functional Unit Matrix
    • Application to Technology Matrix
    • Business Process to Business Service Matrix

6. Data Gathering Template.xls – this provides the minimum required elements that should be documented for enterprise architecture projects. It is an asset that allows stakeholder to capture the information and share with the architecture teams.