IM/IT ARB Presentation Template
IM/IT ARB Presentation Template
Presenter Name Branch
Table of Contents
- Business Requirements and Benefits
- Business and Solution Options Summary
- Solution Map
- System Data Flow Diagram
- Application Map
- RICEF Factors (Reports, Interfaces, Conversion, Extensions, Forms)
- Conversion/Cutover Considerations
- System Landscape
- Deployment Considerations
- Support Considerations
- Open Issues
- Estimating Summary
The IM/IT Architecture Review Board ensures:
- Alignment of the Enterprise Architecture with Public Services and Procurement Canada (PSPC) strategic goals; and
- That all IM/IT initiatives and activities are aligned with the Enterprise Architecture (EA), which is contained within the PSPC and CIO strategic plans
Initiatives/potential projects with an estimated value >$1M are brought to the attention of the IM/IT ARB by the PDO or the CE organization. The IM/IT Architecture Review team reviews Statement of Requirements and any supporting documents to assess the project for potential impacts. The IM/IT Architecture Review Board then meets to review those project proposals that may impact the EA.
The IM/IT ARB also considers security, privacy, and information management policy compliance impacts. The review normally occurs before the Preliminary Project Plan has been finalized to ensure that:
- Project outcomes align with the EA vision; and
- The project leverages existing components and processes where linkage has the potential to optimize outcomes, reduce costs or provide integration opportunities.
- The conceptual solution outlines the future solution, specifically the application, the technology, the process, and the effort/training required for support.
- The conceptual solution contains the design decisions for application, process, and technology, as well as training and performance support.
- Create this deliverable in the plan stage to:
- identify the applications in the solution and the relationships between them.
- depict the future business processes at a high level.
- describe a vision of the technical working environment that will support the defined applications.
- Describe the project history as it supports the information in this document.
- Summarize the business problem faced by the client.
- Include relevant discussion points on the advantages, regulations, and resource availability for the project, as well as on the driving force and rationale for it.
- If the initiative is part of a multi-phase release plan, indicate how the release for this project may be related to other releases within the overall solution strategy.
The table describes the high level business requirement by identity number, title, requirement and priority.
- Provide a summary of the expected benefits (when available)
Business and Solution Options Summary
The table describes each business and solution options by business option, solution option and comments/ recommendation.
|Business Option||Solution Option(s)||Comments/
|business option 1||solution option 1
solution option n
- Identify the solution's applications, for each solution option as appropriate, and the relationships between them.
- Take into account any planned and/or existing applications that support the solution. The extent of integration with other applications will need to be considered, as this will have implications for the definition of the application architecture and potential impacts on the disaster recovery solution.
- Create this deliverable during the plan stage to:
- map the applications required to support the solution, showing the various functional and technical layers of each application.
- provide a basis for the detailed design of the technology build.
- illustrate dependencies among the applications.
- increase the predictability of application performance (because the run-time behaviour of common components is familiar and consistent).
- develop a construction blueprint and ensure consistency across systems.
- map the functional requirements.
System Data Flow Diagram
- The information sources/database used
- The interface between the systems and end users
- Information requirements and flow
- Integration with other applications
- Disaster recovery integration/requirements
List the different applications involved in the solution and
how they interface with one another
By leveraging information about user working styles, geography and interface requirements, we can identify the required access channels for the targeted applications.
The targeted business applications are those suites of solution that the architecture is designed to support.
Integration services provide integration capability for the disparate application systems. The integration services layer consists of business objects, collaborators and adapters. Business objects provide a wrapper to logically grouped transactions. This provides the business applications with a generic interface that hides the complexity of interaction with back-end systems. Collaborators assemble data from multiple back-end systems by leveraging adapters, which provide simplified access to each of the back-end systems. Some adapters may be custom developed while others can be reasonably provided by a third party.
Business systems consist of all existing and new back-office applications and databases that the targeted business applications will leverage for functionality and data. This includes packaged and custom applications as well as databases, data warehouses and data marts.
The technology services are a comprehensive set of run-time services required to support the targeted applications and processing styles.
- RICEF Factors are objects that are required for the solution.
- RICEF stands for Reports, Interfaces, Conversions, Extensions and Forms.
- RICEF objects should be presented in a table. The table needs to identify:
- source system
- complexity (Simple, Medium or Complex)
- whether object is new or a modification to an existing object
- name of object
- description of object
- Identify and describe any business requirements that cannot be incorporated into the solution. Provide a rationale as to why this is the case.
- The definition of a gap is:
- For packaged software, an area of functionality that is not supported by the standard packaged software configuration.
- A business requirement that cannot be met through a system/application solution.
- List all the assumptions that you have made in reference to the solution. The intention is not to repeat the project assumptions, but to list assumptions that are more related to what must be in place for the solution to be implemented in the described manner.
- Examples of assumptions to consider are:
- changes to existing applications that are required.
- infrastructure that is required.
- skills from the client that are expected, e.g. UAT at a specific time.
- whether existing Disaster Recovery Solution will be leveraged.
- Describe conversion and cutover processes that are required for this solution.
- Are they manual conversions or automated conversions?
- What will be the process to convert the data and what are the timing considerations?
- The conversion of data from the current format to the structure required by the new application. A conversion can be performed via an automated program or completed manually.
- The technical architect defines the landscape for development, execution and operations environments.
- At a macro level, technical architecture refers to the infrastructure components in the enterprise.
- At an implementation level, technical architecture is the physical infrastructure (co-hosted or dedicated) and application components that describe to designers and developers the environments that need to be built and maintained during the development lifecycle.
- List any major deployment activities requirement for this solution.
- Are there new processes or technology getting deployed regionally?
- How many users/sites may be affected?
- Is a new solution recommended to be included in the disaster recovery annual test?
- A stage that introduces the new business capability into the operating environment. The tasks in this stage transition the workforce, deploy new processes and technology, and stabilize operations. These tasks are repeated for each deployment unit.
- Are there any impacts to the current SLAs?
- Are there any impacts to the disaster recovery solution?
- Need Application Management to be involved in this assessment.
- Are there new applications?
- Are there new disaster recovery components?
- 1 PY - skilled programmer to support ongoing application fixes
- ½ PY - Linux expert to support OS
- 24/7 on-call support
- List all of the issues that are required to bring to conclusion regarding the conceptual solution.
- They can be listed in table format - sample below
The table describes open issues that are required to bring to conclusion the conceptual solution by ID, issue, severity, action and status.
- Insert a summary of the estimating model that has been approved as client-facing.
- One-time costs:
- custom development
- packaged software
- hardware and system software
- Ongoing costs:
- application and service support
- data services
- license maintenance
- hardware support
- Date modified: