# 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