Enterprise Architecture Standards

The standards that apply for enterprise architecture apply for different areas. These include:

1. Naming convention – there needs to be an agreed upon naming convention of artefacts to facilitate re-use of objects.
2. Tools for developing deliverables – to ensure effective collaboration across entities, there needs to be a standard use of tools which will enable sharing and re-use of models
3. Definition of attributes – an understanding of each object that is created in the repository needs to be the same across all entities. This is enforced through adherence of the set of attributes that should be captured for each entity.

Naming Convention Standards

There are more added advantages to be gained from the use powerful features within a tool such as Sparx Enterprise Architect. However, these powerful features need to be enhanced with the implementation of set standards that will ensure seamless alignment of artefacts as well as enabling re-use.

Needless to say, an object or artefact is only available for re-use once it has been created within the tool. However, the challenge with CASE tools is that the repository does not have the in-built intelligence to create the relationship between different objects with similar names. In this case therefore, the naming convention is important because the repository is case sensitive. For example, these objects are different.

Although the entities above have the same name, the spelling itself gives the entity its own unique identity. Sparx Enterprise Architect will identify ‘Customer’ with a capital “C” as a separate entity from ‘customer’ (the name written in lower case) and ‘CUSTOMER’ (written in upper case), etc.

To enable reuse of the objects, it is therefore imperative that specific standards be adhered to when creating artifacts/entities to ensure that they are available for reuse.

The following naming conversion is therefore recommended.

For each name, only the first letter of each word should be in capital letters, e.g., Customer, Manager, Human Resource Management, Financial Officer, Customer Acceptance Form

Tabulated below is the proposed naming conversion for entities, processes, etc.

The above describes objects that have a relationship with each other. None of them exists in isolation. Their relationship to each other is depicted in a meta-model that has been defined for the government of Rwanda. Depicted below is a simplified meta-model highlighting the alignment and relationship between the objects.

Government of Rwanda Simplified Metadata

NOTE: To ensure that the team applies the naming convention properly, it is imperative that before an object is created, the user should always first look to check if it has already been created within the repository. Once it has been created, it will carry all assigned attributes whenever it is reused.

Production of the blueprints should always take into account the abovementioned relationship between objects. Thus, no object should be created in isolation of the others.

Tools Standards

In addition to the naming conversion, the following section outlines the standards that should apply with regard to the tool available for the exercise.

Depicted below are the Enterprise Architecture Standards that apply to Government of Rwanda

Attributes for models

Application Modelling

Application architecture modeling seeks to present a pictorial view of the application landscape within a given organization. At the core of application architecture is the interdependency and relationship between disparate systems.

The goal of application architecture is to enable informed decision-making. In this regard, therefore, the attributes that are recorded for application architecture are crucial. They must cover a wide area and present information from different perspectives.

The captured information and attributes about any application must include—but not be limited to—the following:

NOTE: A distinction should be made between application and software architecture. Application architecture looks at the relationship between different applications and their modules, while software architecture concentrates on the make-up of a specific application.

The deliverables from the application architecture exercise include the following:

Business Process Modelling

Business processes describe the activities that an entity undertakes in delivering a service to customers. Within the public sector, the customer will include a citizen, patient (at a hospital or clinic), another government institution (e.g. a Ministry would have local government offices and agencies as some of its customers), private entities, etc.

The process that the public entity executes in the delivery of service must be clearly defined. Tabulated below are some of the attributes that should be captured for each process.