Transcript ARB Template

<Client Name>
<Project Name>
IM/IT ARB Presentation Template
Pierre Nantel, Office of the CIO
Information Technology Services Branch (ITSB)
February 2010
EDRM # xxxxxx
Page 1
Table of Contents
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
Introduction
Background/Summary
Business Requirements and Benefits Summary
Business and Solution Options Summary
Solutions Map
System Data Flow (Diagram)
Application Map
RICEF Factors (Reports, Interfaces, Conversion, Extensions, Forms) or Use Case Diagram
Gaps
Assumptions/Dependencies
Conversion/Cutover Considerations
System Landscape
Deployment Considerations
Support Considerations
Open Issues
Estimating Summary
Examples/Back up
Introduction
•The Conceptual Solution outlines the future solution, specifically
the application, the technology, the process, and effort/training
required for support.
•The Conceptual Solution contains the design decisions for
application, process, 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.
– Describes a vision of the technical working environment that
will support the defined applications.
Background/Summary
•Describe the project history as it supports the discussion within this
document.
•Summarize the business problem faced by the client.
•Include relevant discussion points on the advantages, regulations,
resource availability, and the driving force and rationale for the project.
•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.
Business Requirements
Req.
ID
HLR1
HLR2
HLR3
HLR4
HLR5
HLR6
HLR7
HLR8
HLR9
Title
Requirement
<<Enter High-Level Business Requirements to
be fulfilled by this conceptual solution.>>
Priority
Benefits Summary
•Provide a summary of the expected benefits (when available)
Business and Solution Options Summary
Business Option
<business option 1>
Solution Option(s)
<solution option 1>
<solution option n>
Comments /
Recommendation
Solution Map
•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 to 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 of the applications required to support the solution, showing
the various functional and technical layers of the 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
– Serve as a construction blueprint and ensure consistency across
systems
– Map the functional requirements
System Data Flow Diagram
•Document:
– 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
Application Map
Business
Systems
Integration
Services
Business Users
Applications
<<List the different applications involved in the solution and how they interface with one another>>
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 are the enabling technology for providing 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 a each of the back-end systems. Some Adapters may be custom developed
while others can be reasonably provided by a third party.
Business Systems consists 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.
Technology Services
The technology services are a comprehensive set of run-time services required to
support the targeted applications and processing styles.
RICEF Factors
•RICEF Factors is a list of objects that are required for the solution.
•RICEF stands for Reports, Interfaces, Conversions, Extensions and
Forms.
•RICEF objects should be presented in a table format. The table needs
to identify
– Source system
– Complexity (Simple, Medium or Complex)
– If object is new or a modification to an existing object
– Name of the object
– A description of object to be modified or added.
Gaps
•
•
Identify and described any Business requirement(s) that cannot be
incorporated into the solution. Provide a rational as to why?
The definition of a GAP is:
1. For packaged software, gaps are areas of functionality that are
not supported by the standard packaged software configuration.
2. A business requirement that cannot be meet through a system /
application solution.
Assumptions/Dependencies
•List all of the assumptions that you have made in reference to the
Solution. The intention is not to repeat the project Assumptions, but
those that are more focused on 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 I.e. UAT at a specific
time.
– Existing Disaster Recovery Solution will be leveraged.
Conversion/Cutover Considerations
•Describe Conversion and cutover processes that are required for this
solution.
– Are they manual conversions vs. automated conversions?
– What will be the process to convert the data and what are the
timing considerations?
•Definition
– 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 can be completed manually.
System Landscape
•The Technical Architect defines the landscape for Development
,Execution and Operations environments
•At a macro level, Technical Architecture defines 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.
Deployment Considerations
•List any major deployment activities requirement for this solution.
– Are there new processes and technology getting deployed
regionally.
– Described how many users / sites may be impacted?
– Is a new solution recommended to be included in the
Disaster Recovery annual test?
•Definition
– A stage that introduces the new business capability into the
Operating environment. The tasks within this stage transition
the workforce, deploy new processes and technology, and
stabilize the operations. These tasks are repeated for each
deployment unit.
Support Considerations
•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.
•New applications?
•New Disaster Recovery components?
 1 PY  skilled programmer to support on-going application fixes
 ½ PY  Linux expert to support OS.
 24/7 on-call support.
Open Issues
•List all of the Issues that are required to bring to conclusion regarding
the Conceptual Solution.
•It can be listed in table format – sample below
ID
1
2
3
Issue
Severity
Action
Status
Estimating Summary
•Insert a summary of the estimating model that has been approved
as Client Facing.
•One-time costs:
– Custom development
– Configuration
– Training
– Packaged Software
– Hardware and System software
•On-Going costs:
– Application and service support
– Data services
– License maintenance
– Hardware support