technical risk assessment

8/13/2019 Technical Risk Assessment

1/37

Technical Risk Assessment

Standard Dedicated uCMDB (SD-uCMDB) Instance

Version 1.0

Date 10/31/2009

P o r t f o l i o D e v e l o p m e n t Technical Risk Assessment


2/37


V2.2 07-31-06 HP Enterprise Services Internal Page 2 of 37

Index

DOCUMENT INFORMATION .................................................................................................. 3

PURPOSE...................................................................................................................................... 3

PREREQUISITES............................................................................................................................ 3DURATION................................................................................................................................... 3INSTRUCTIONS............................................................................................................................. 3

TECHNICAL RISK ASSESSMENT TEMPLATE CHANGE HISTORY.................................................... 4

PROJECT CHANGE HISTORY......................................................................... 5ORGANIZATIONAL ASSIGNMENTS................................................................................................ 6

1. SUMMARY ............................................................................................................................... 7

2. RISK ANALYSIS.................................................................................................................... 10

INSTRUCTIONS........................................................................................................................... 10

RISK ASSESSMENT -GENERAL................................................................................................... 11

RISK ASSESSMENTPROCESS................................................................................................... 15

RISK ASSESSMENT -TECHNICAL................................................................................................ 28

3. ADDITIONAL RISKS ........................................................................................................... 35

INSTRUCTIONS........................................................................................................................... 35

RISK DESCRIPTION AND ASSESSMENTS...................................................................................... 35


3/37



Document Information

Purpose

The purpose for the Technical Risk Assessment is twofold:

To outline any high-level technical or process barriers that exist in the proposal, and to

rank them according to their severity

To provide a preliminary analysis of the impact of these barriers to the proposal and toupdate the analysis over time as more information is known about the proposal

Prerequisi tes

The following documents must be produced by upstream activities before a Technical Risk

Assessment can be completed:

Idea Submission Form: This will help give information describing the initiative and anyhigh-level available documents. If clarification is needed, a request will be made back to

the Service Line Manager for further details.

Business Requirements to the extent known: Depending on the nature of the Offeringand the current CtP phase, these could be the High-level Requirements and/or theDetailed Business Requirements. If clarification is needed, a request will be made back to

the Portfolio Development Program Manager for further details.

Updates to the EDS Enterprise Architecture: The Core Architect should notify theEnterprise Architecture Program Officeof any needed updates to the EDS Enterprise

Architecture based on information known during Manage and Plan.

Product Release Plan:This should provide the architect with details sufficient tounderstand the proposal including a tentative description of features. After receiving the

Product Release Plan, if additional clarification is necessary, a request will be made back

to the Portfolio Development Program Manager for further details.

Durat ion

After receiving a request for a Technical Risk Assessment, the assigned architect will identifythe appropriate group(s) requiring involvement. Provided the pre requisites have been completed

fully, the completed assessment must be sent back to Portfolio Management within five business

days.

Inst ruct ions

The Technical Risk Assessment has three major sections:

1. Summary: This section contains tables that can be used to summarize the results of theTechnical Risk Assessment and assist the Core Architect in determining an overall rating

for the proposal.

2. Risk Analysis: This section contains a number of predetermined risk analysis areas that

must be examined to outline the high-level risks associated with the proposal. Each areahas three levels of risk from which to choose. Report the current situation by selecting the

appropriate risk assessment.

Each organization that participates will determine their rating for each question.
mailto:[email protected]:[email protected]:[email protected]


4/37



Comments shall be provided for each risk area ranked Medium or High.

3. Additional Risks:In addition to the risks outlined in the Risk Analysis section, theremay be additional risks that need to be analyzed in order to assess the technical feasibility

of this new idea. These additional risks need to be added to this section. Describe the risk,

assign it a ranking, and add sufficient notes to describe the implications of what it meansto EDS.

In some circumstances it may be desirable to produce a single Technical Risk Assessment whichspans multiple targeted releases. The documentation approach may vary depending on the

architectural coupling of the releases. The Core Architect should work with the PortfolioDevelopment Program Manager to determine the best documentation approach for a particular

offering. If using this template to span multiple targeted releases, repeat Sections 1 through 3 as

needed.

Technical Risk As sessm ent Temp late Change History

The following Change History log contains a record of changes made to this template:

Published /Revised Date

Version#

Author Change History

06 Jan 2005 1.01 L Fernandez Removed macros & improved formatting

Provided references for responding to questions

Removed question 11 due to overlap w/ overall rating

Removed references to Technology Development

13 Apr 2005 1.02 N. Cresswell Added references to Delivery Systems Architecture

30 June 2005 1.03 E. Nadhan / H.

Steinman Added a Risk Rating Detail table in the Summary

section. Clarified the language in the Prerequisites

section.

27 July 2005 1.04 N. Cresswell Updated references to the DSA CtO Procedures

10 Nov 2005 1.05 H. Steinman

E. Nadhan / H.Steinman

Added EDS Technology Policy as a reference forRisk 10 (EDS Experience).

Used name DSA Support for CtO Enterprise

Process Annex BArchitecture GuidanceAssessment for Validate, Plan and Design forconsistency throughout document.

Added table to track evolution of risk ratings overtime as progress is made from one phase to the next.

09 March 2006 1.06 P. Singh Added questions to assess process risk.

Added Not Applicable and Insufficient Requirementscheck boxes.

21 June 2006 1.07 H. Steinman Renamed from Preliminary Technical Assessment toTechnical Risk Assessment

Added instructions for handling multiple targetedreleases in one document

01 Sept 2006 1.08 H. Steinman Changed Business Case/Plan references to Product

Release Plan throughout document.

03 Jan 2007 1.09 H. Steinman Fixed typo in risk evolution table.

24 Jan 2007 1.10 H. Steinman Updated to reference EDS Enterprise Architectureinstead of DSA.

21 Mar 2007 1.11 H. Steinman

M. Hunter

Updated to reference new CtP role names andrequirements management activities.

19 Feb 2008 1.12 H. Steinman Corrected typo in Process Question 4.

03 Apr 2008 1.13 H. Steinman

E. Perry

Made several improvements in grammar andpunctuation. No content changes.

28 Jul 2008 1.14 H. Steinman Added question for change in usage, deployment, or


5/37



ApplicationServices

Engineering &Portfolio -ApplicationsEngineering

support

Project Change History

The following Change History log contains a record of changes made to this document:

Published /Revised Date

Version#

Author Change History

11/3/2009 1.0 Doug Fisher Changed all reference from Standard Dedicated toStandard Private with the acronym SD-uCMDB.


6/37



Organizat ional Assignments

After receiving a request for a Technical Risk Assessment, the assigned architect will review it todetermine which organizations will be involved with the initiative. Those individuals who will

play a role in developing this initiative will also be responsible for giving input to this report.

Below, please identify the organizations that the architect anticipates will be required in

developing this initiative, and document who from that organization (SME) will provide input tothis report.

Capability / Organization

Group(s)

Subject Matter Expert

Global Process Owner Zoe Lambert

Service Owner Roland Fadrany

Capability Owner Alexis Mermet-Grandfille

Engineering Leader Craig Parker
mailto:[email protected]?subject=Technical%20Risk%20Assesment%20for%20Standardized%20Private%20uCMDBmailto:[email protected]?subject=Technical%20Risk%20Assesment%20for%20Standardized%20Private%20uCMDBmailto:[email protected]?subject=Technical%20Risk%20Assesment%20for%20Standardized%20Private%20uCMDBmailto:[email protected]?subject=Technical%20Risk%20Assesment%20for%20Standardized%20Private%20uCMDBmailto:[email protected]?subject=Technical%20Risk%20Assesment%20for%20Standardized%20Private%20uCMDBmailto:[email protected]?subject=Technical%20Risk%20Assesment%20for%20Standardized%20Private%20uCMDBmailto:[email protected]?subject=Technical%20Risk%20Assesment%20for%20Standardized%20Private%20uCMDBmailto:[email protected]?subject=Technical%20Risk%20Assesment%20for%20Standardized%20Private%20uCMDBmailto:[email protected]?subject=Technical%20Risk%20Assesment%20for%20Standardized%20Private%20uCMDBmailto:[email protected]?subject=Technical%20Risk%20Assesment%20for%20Standardized%20Private%20uCMDBmailto:[email protected]?subject=Technical%20Risk%20Assesment%20for%20Standardized%20Private%20uCMDBmailto:[email protected]?subject=Technical%20Risk%20Assesment%20for%20Standardized%20Private%20uCMDB


7/37



1. SummaryAfter completing this report, the architect will provide an overall rating for this proposal. Use the RiskRating Detail table in this section to summarize the results of the risk analysis and to assist you indetermining an overall rating. The rating will use the following criteria:

Criteria Rating

Completely feasible - no difficulties to overcome 5

Mostly feasible - only slight difficulties to overcome 4

Possible - several difficulties to overcome 3

Difficult - many difficulties to overcome 2

Impossible to overcome difficulties 1

Rating Type Rating(1-5)

Notes

General Ratingfor this proposal

4

Process ratingfor this proposal

3

Technical ratingfor this proposal

3

Overall rating forthis proposal

3


8/37



This table may be used to summarize the results of the Risk Analysis below. Double-clickanywhere on the table to activate the Excel worksheet. Delete rows that are not needed.

Risk # Risk Descr iption Low Medium High N/AInsuff.

Req.

1 Availability of sufficient offering details x

2 Time-to-market reasonability x

3 EDS Experience x

4 Learning Curve x

Sub Total 3 1 0

Sub Percentages 75.00% 25.00% 0.00%

1 Process Conformance x

2 Process Flow Definition x

3 Process Components x

4 Process Reusability x5 Process Scalability x

6 EDS Industry Frameworks x

7 Technology Policy Tools Compliance x

8 Tools Independence x

9 Process Integration Effort x

10 Process Automation x

11 Process Measurability x

Sub Total 8 2 0


1 Technology maturity x

2 Technology provider stability x3 Integration Complexity x

4 Technology availability x

5 Standards current state x

6 # of technology categories x7 Change in usage, deployment, or support x

Sub Total 5 2 0


1 Leveraged Component Dependency x

2 RADM Component Dependency x

Sub Total 0 0 2


Total 16 5 2

Total Percentages 69.57% 21.74% 8.70%

Risk Rating Detail

Process

Technology

General

Additonal Risks


9/37



This table may be used to track the evolution of the risk ratings from phase to phase. This can beuseful to highlight how risks change over time as progress is made from one phase to the next.

Risk # Risk Description

Manage

Phase

Rating

(Low,

Medium,High)

Plan Phase

Rating

(Low,

Medium,

High)

Design

Phase

Rating

(Low,

Medium,High)

General

1. Availability of sufficientoffering details

Low Low

2. Time-to-marketreasonability

Medium

3. EDS experience Low

4. Learning Curve Low

Process

1. Process Conformance Low

2. Process Flow Definition Low

3. Process Components Low

4. Process Reusability Low

5. Process Scalability Low

6. EDS Industry Frameworks N/A

7. Technology Policy ToolsCompliance

Low

8. Tools Independence Low9. Process Integration Effort Medium

10. Process Automation Low

11. Process Measurability Medium

Technology

1. Technology Maturity Low

2. Technology Provider

Stability

Low

3. Integration Complexity Low

4. Technology availability Low

5. Standards current state Low

6. # of technology categories Medium

7. Change in usage,deployment, or support

Medium

Additional Risks

1. Leveraged ComponentDependency

High

2. RADM ComponentDependency

High


10/37


11/37



Risk As sessm ent - General

1. Have sufficient offering details been provided in order to develop an accurate riskassessment?

Topic: Offering Description

Reference(s):Business Requirements

Product Release Plan

o Release Roadmap Matrix

o Release Description

o Release Risk Analysis

Not Applicable

Insufficient Requirements

Rating Criteria

x Low Well-defined details

_ Medium Some incomplete details

_ High Vague or missing details

Notes: (Required for all Medium and High ratings)

Offering Details are well defined

Recommended mitigation strategy: (Required for all Medium and High ratings)


12/37



2. How reasonable is the Portfolio Management-suggested time-to-market for this initiative?

Topic: Time-to-Market

Reference(s):

Business Requirements

Product Release Plan: Release Roadmap Matrix

Not Applicable


Rating Criteria

_ Low Time frames seem reasonable with normal resourcelevels

X Medium Time frames is a concern because it may requireabove average resource levels

_ High

Time frames may require a large amount ofadditional resources

OR

Time frames were not provided


Time to market is very aggressive and may require significant resources to deliver on time.

Dependency on other components to deliver the solution may extend the timeframe for this

particular solution.

Recommended mitigation strategy: (Required for all Medium and High ratings) Validate all required resources are available, if resources are not currently scheduled or available

open a risk dependency with the project manager.


13/37



3: How much experience does EDS have with these processes or technologies or both?

Topic: EDS Experience

References:


Product Release Plan: Release Scope of Features & Capabilities

EDS Enterprise Architecture

EDS Technology Policy

Not Applicable


Rating Criteria

_ Low Substantial experience

X Medium Limited experience

_ High No experience


HP Enterprise Services has a lot of experience with the technologies involved in the solution.

The process and governance to control when a solution utilizes the Standard Dedicated uCMDB

solution and when a deployment is custom is not well defined and has typically not been wellgoverned or controlled. This process that determines when a solution is custom versus leveraged

needs to be well defined.

The governance process must accommodate both new sales in the solutioning phase as well as

during the steady state operations. If the process detects a solution that does not fit the strictguidelines for a leveraged solution, the appropriate organization will be notified and an action

plan to transition or support the custom solution by the appropriate organization should bedocumented and executed.


One of the outputs of the solution will be a governance process that describes the processes and

steps to be followed during initial sales creation and steady state. The process will define ghtecriteria and actions that need to be taken if a solution is determined not to meet the leveraged

deployment criteria.


14/37



4: How is the learning curve for these processes or technologies or both characterized?

Topic: Learning Curve

References: Business Requirements

Product Release Plan: Release Scope of Features & Capabilities

Not Applicable


Rating Criteria

X Low Easy

_ Medium Challenging

_ High Very Steep


The learning curve is not great. Many companies already have the processes in place and this

implementation will not change any of the customersprocesses, just the tools utilized to

facilitate the configuration management processes.



15/37



Risk Assessment Process

1: To what extent can standard processes be followed?

Topic: Process Conformance

References:



Standard realization processes followed within EDS for different product work types arelisted below

Table 1

Product Work Type Realization Process

Applications and System

Engineering

GAD QMS:http://www.gsms-

am.eds.com/gad_qms/gsms/

Operations ITIL:http://www.gsms-am.eds.com/itil/

Applications Development OCE:http://www.gsms-am.eds.com/gad_qms/gsms/perform_task.htm

Project Management PM2:

http://pm2.iweb.eds.com/processes/process_pm2.asp

Not Applicable


Rating Criteria

X Low Processes employed, if any, are in conformance with oneof the following in the order of preference listed below

EDS standard realization processes listed above inTable 1, wherever existent

Industry standard processes if there are no EDSstandards defined in this space

EDS Alliance Partner processes if there are no EDS orindustry standards defined in this space.

_ Medium Most of the processes are in conformance with one of the

following standards:

EDS process standards

EDS Alliance Partners' process standards

Standards applicable to the industry in context
http://www.gsms-am.eds.com/gad_qms/gsms/http://www.gsms-am.eds.com/gad_qms/gsms/http://www.gsms-am.eds.com/gad_qms/gsms/http://www.gsms-am.eds.com/gad_qms/gsms/http://www.gsms-am.eds.com/itil/http://www.gsms-am.eds.com/itil/http://www.gsms-am.eds.com/itil/http://www.gsms-am.eds.com/gad_qms/gsms/perform_task.htmhttp://www.gsms-am.eds.com/gad_qms/gsms/perform_task.htmhttp://www.gsms-am.eds.com/gad_qms/gsms/perform_task.htmhttp://www.gsms-am.eds.com/gad_qms/gsms/perform_task.htmhttp://pm2.iweb.eds.com/processes/process_pm2.asphttp://pm2.iweb.eds.com/processes/process_pm2.asphttp://pm2.iweb.eds.com/processes/process_pm2.asphttp://www.gsms-am.eds.com/gad_qms/gsms/perform_task.htmhttp://www.gsms-am.eds.com/gad_qms/gsms/perform_task.htmhttp://www.gsms-am.eds.com/itil/http://www.gsms-am.eds.com/gad_qms/gsms/http://www.gsms-am.eds.com/gad_qms/gsms/


16/37



_ High Few processes, if any, are in conformance with EDSstandard realization processes or EDS Alliance Partners'

standards

Processes are following multiple standards (EDS, EDSAlliance Partner or otherwise)


All common processes for development, project management, and operations can be followed.

There are not special circumstances which would require alteration of stand processes.



17/37



2: Do the process steps within a process flows have defined conditional activities that

accommodate potential success or failure conditions?

Topic: Process Flow Definition

References:



Not Applicable


Rating Criteria

X Low Consensus reached between process stakeholders on flowwith supporting documentation for the success and failure

paths

_ Medium Ongoing discussion between process stakeholders on the

flows for the success and failure paths

_ High Consensus has not been reached between processstakeholders for most of the flow paths




18/37



3: How many of the following process components will be involved in this initiative?

Program Management and Governance

Service Support

Project Management

Service Desk

Change Management

Configuration Management

Release Management

Problem Management

Incident Management

Service Delivery

Service Level Management

Capacity Management

Availability Management

Document Management

Value Management

Applications and Systems Engineering

Applications Development

Operations

Trading partner interaction

Business Process

Software Development

Knowledge Management

Knowledge Transfer

Topic: Process Components

References:



Not Applicable


Rating Criteria

X Low 1-7

_ Medium 8-15


19/37


20/37



4: What is the extent to which these processes can be reused across industries?

Topic: Process Reusability

References:



Not Applicable


Rating Criteria

X Low Processes can be reused across industries. Nocustomization required.

_ Medium Processes can be reused between customers within anindustry. Some customization is needed to use theseprocesses for customers in other industries.

_ High Processes are specific to one or more customers within anindustry. Major customization is required to use theseprocesses for other customers.




21/37



5: To what extent can Workflow-based processes be scaled?

Topic: Process Scalability

References:



Not Applicable


Rating Criteria

X Low Workflow-based processes can scale across geographiesand industries

_ Medium Workflow-based processes can scale across customerswithin a given geography or industry

_ High

Workflow-based business processes can scale within acustomers enterprise


Workflow processes related to the Standard Dedicated uCMDB implementation will primarily be

the processes owned and developed by the customer. The only processes related to this initiative

that are HP Enterprise Services developed is the governance process that controls the decisions

during the sales cycle and steady state that validate whether the Standard Dediated uCMDBsolution applies.



22/37



6: To what extent do the Business Processes employ the EDS industry frameworks?

Topic: EDS Industry Frameworks

References:



Not Applicable


Rating Criteria

_ Low The offering is based completely upon one of the industryframeworks.

_ Medium Process related components of the offering are based uponone of the EDS industry frameworks.

_ High

Limited portions of the process related components of theoffering are based upon one of the EDS industryframeworks.




23/37



7: Are the tools supporting processes compliant with EDS technology Policy?

Topic: Technology PolicyTools Compliance

References:




Not Applicable


Rating Criteria

X_ Low Supporting technologies, if applicable, are all provided byEDS Alliance partners.

_ Medium Supporting technologies are provided by parties other thanEDS Agility Alliance partners but are in conformancewith the EDS process-related standards.

_ High Supporting technologies are not provided by EDSAlliance partners and are not in conformance with theEDS process-related standards.


All technologies utilized to support the processes related to HP Enterprise Services are provided

by HP Software.

Recommended mitigation strategy: (required for all Medium and High ratings)


24/37



8: To what extent are the processes specific to the tools that enable them?

Topic: Tool Independence

References:




Not Applicable


Rating Criteria

X Low Processes can be implemented using most tools in thisspace.

_ Medium Processes can be implemented using a subset of tools inthis space.

_ High Processes are tool specific.




25/37



9: What is the level of effort in integrating the processes?

Topic: Process Integration Effort

References:




Not Applicable


Rating Criteria

_ Low Most of the processes are already integrated with nomanual intervention required.

X Medium

Integration can be achieved with existing technologies butsome processes are yet to be integrated. Inputs andOutputs have been identified and aligned.

Some processes require manual intervention, but inputsand outputs have been identified and aligned.

_ High Manual intervention is required between processes and noinputs and outputs have been identified.


The process developed to provide governance has not yet been integrated to the overall sales and

steady state process.


The process and governance to manage the deployment of the Standard Dedicated uCMDB

instance during the sales cycle and steady state will be developed during the design phase andintegrated into the sales cycle. The same governance process will be integrated into the normal

change process for steady state governance.


26/37



10: To what extent can the processes be automated?

Topic: Process Automation

References:




Not Applicable


Rating Criteria

X Low Most of the processes employed are already automatedand configurable

_ Medium Processes employed can be automated using existingtechnologies. Some automated processes are configurable

_ High Processes cannot be automated and are therefore notconfigurable. New investment required in appropriate

technologies to make these processes automated andconfigurable




27/37



11: To what extent can the effectiveness of the business processes be measured and monitored?

Topic: Process Measurability

References:




Not Applicable


Rating Criteria

_ Low Measurement metrics have been pre-defined and themetrics collection mechanisms are all automated

X Medium Measurement metrics have been pre-defined and some ofthe metrics collection mechanisms are automated

_ High Measurement mechanisms have not been pre-defined andmost of the metrics collection mechanisms are manual or

have to be incorporated


Metrics to measure the efficiency of running the solution are already defined, but the process

required to measure the effectiveness of the governance process have not been determined or

defined.

Recommended mitigation strategy:(Required for all Medium and High ratings)

As part of this project, one of the outputs will be a defined process and metrics to measure the

effectiveness of the governance process used to determine custom versus leveraged solutions.The process and metrics will provide valuable information to the business regarding the

governance process for the Standard Dedicated uCMDB solution.


28/37



Risk Ass essment - Techn ical

1. How mature are the required technologies in todays market?

Topic: Technology Alignment

Reference(s):




Not Applicable


Rating Criteria

X Low Existing technologies require minor modification(s)

_ Medium Existing technologies require major modification(s)

_ High Leading edge or new technologies required

Aging technologies that are a challenge to support(e.g. New COBOL offering)


The existing technologies require minor modifications. These modifications will be done at theedge of the architecture which will not impact the core systems.



29/37



2. How stable are the technology providers?

Topic: Company Stability and Potential

Reference(s):


Product Release Plan: Alliance and Vendor Usage


Not Applicable


Rating Criteria

X Low Existing, well-established, well recognized companieswith a track record of product and technology success.

_ Medium Emerging companies with sufficient financialresources and management team with strong trackrecord of success.

OR

Maturing companies with established client bases anddocumented track records of product performance.

_ High Emerging companies with limited financial resourcesand little or no track record of success.


Technologies being used are either from HP or technologies that are prevalent in the marketplace

and being utilized by HP software.



30/37



3. How complex are the integration issues surrounding these technologies?

Topic: Integration Issues

Reference(s):


Product Release Plan: Preliminary Architecture Diagram


Not Applicable


Rating Criteria

X Low Integration methods are currently used and availableeither within EDS or in the marketplace

_ Medium Some integration methods will need to be developedby either EDS or technology vendors

_ High Some of the integration methods and/or their sourcesare unknown


The integration capabilities are not complex and already exist within HP Enterprise Services. No

new integration technologies are being introduced or utilized in the solution.



31/37



4. How available are the required technologies?

Topic: Technology Availability

Reference(s):



Release Description

Alliance and Vendor Usage


Not Applicable


Rating Criteria

X Low All required technologies are available from existingpartners

_ Medium Most required technologies are available off-the-shelffrom non-partner vendors

_ High New partnerships will have to be created before EDShas access to these technologies


All Technologies are either available from HP software or from vendors that HP already hasestablished relationships with.



32/37



5. What is the state of the current standards supporting these technologies?

Topic: Standards

Reference(s):


Product Release Plan: Release Description


Not Applicable


Rating Criteria

X Low Single defined standard

_ Medium Competing standards

_ High No globally accepted standards




33/37



6. How many of the following technology and technology management categories will be

involved in this initiative?

Hosting

Networking

Wireless and Mobility

Storage

Distributed Systems and Desktops

Application Services

Security

Workflow and Provisioning

Topic: Technology Requirements

Reference(s):


Product Release Plan: Preliminary Architecture Diagram


Not Applicable


Rating Criteria

_ Low 1 to 2

X Medium 3 to 4

_ High 5


HP Software uCMDB8.02+.

Java

Secure File Transfer

DCS from ESL, Network from Redfish, Distributed Desktop

All these technologies are very mature and are prevalent in the market place.


While there are multiple technologies involved in the project, all are very mature in themarketplace and are very sell defined and in production at a number of customer sites across the

HP customer base. During the design phase, continued interlock between the service lines and

the other owners of information like ESL, Redfish and the BMC Atrium tool will be held tomake sure architecture aligns with the needs of the stakeholders..


34/37



7. Are we changing the manner of 1) usage, 2) deployment, or 3) support of an existing

technology (e.g., tool)?

These are defined as follows:

1) Usage: Using a technology for a different purpose, or use by a different user community.This could also include a change in licensing scheme.

2) Deployment: Changing the way a technology is hosted or distributed, e.g. a desktop toolwill now be centrally hosted.

3) Support: Changing the level or manner of support, e.g. going from 8x5 to 24x7 support,

or going from vendor support to EDS help desk support. Not necessarily related to achange in deployment, but if the deployment changes, it is likely support will change as

well.

Topic: Standards

Reference(s):


Product Release Plan: Release Description EDS Technology Policy

Not Applicable


Rating Criteria

_ Low Minor changes to one of the three aspects

X Medium More complex changes to one or two aspects

_ High Complex changes to two to three of the aspects


We are changing the deployment of the configuration management tool. Today the tool is

only offered as a leveraged instance integrated with other tools within a leveraged stack.

This offering will switch the deployment to a distributed or Standard Dedicated uCMDB thatwill need to be managed and supported from a leveraged model. If changes to the

environment violate the Standard Dedicated model, actions will need to be taken to transition

the support model to a custom or dedicated support model.



35/37



3. Additional Risks

Inst ruct ions

Replicate the template below to capture pertinent information describing additional risks thatneed to be analyzed before moving forward.

Use the following as guidelines when identifying additional risks:1. Risks are intended to point out high-level show stoppers

2. Risks will cover only the technologies (not capabilities or offerings) -- technologies canexist even though the Capability or Offering does not!

3. Risks should cover general technologies (e.g., mature hosting technologies exist in thisspace, but the anticipated communications technologies are immature), but should not

cover specific hardware or software products.

4. Risks may cover resource requirements at a high level (e.g., will require new securitytechnologies, but most of the security organization is working on project X for the next 6

months)5. Risks should address Portfolio Management-imposed restrictions (e.g., time-to-market is

3 months, 75% cost reduction, must use product "A" from supplier "Z", etc.)

Risk Descr ipt ion and Ass essments

1. Risk: HP Enterprise Services has many Managed File Transfers solutions that can be used to

deliver a secure file transport mechanism, but there is not particular component that has been

identified to fill that gap within the current SRA application stack.

Topic: SOE Standard Component

References:


Architecture Components

Not Applicable


Rating Criteria

_ Low Business has a well defined solution that has theappropriate business ownership and has beendocumented as the Managed File Transfer solution

that can be used by other capabilities.

_ Medium Business has a solution that can fulfill the capabilitybut lacks a clear business owner that is responsible for

the solution.


36/37



X High There is no clear business owner for the managed filetransfer solution and the managed file transfer solution

is not documented within the current componentsavailable for use the solution design.


HP Enterprise Services has a technology that has been deployed in the Legacy EDSenvironments but lacks the following items:

1. No clear business owner for the solution2. No clear technical owner responsible for ongoing development and integration into

the overall architecture3. No well defined support or deployment model


This issue is currently being addresses within the ESM organization and will be documented as a

risk or critical dependency within the Standard Dedicated uCMDB solution.


37/37


2.Risk: Release and Deployment Management does not reflect the interdependencies betweeneach of the individual projects being worked within the ESM organization.

Topic: Release and Deployment Management

References:


Architecture Components

Not Applicable


Rating Criteria

_ Low The Release and Deployment process has a very clearand mature process to determine interdependencies of

business solutions and a means to schedule the releasebased on the dependencies of the individual

components.

_ Medium The Release and Deployment does not have a clear ormature process to track the dependencies of

components but the individual projects have an

understanding of their dependencies on othercomponents or projects.

X High The Release and Deployment process does not have aclear and mature process to determineinterdependencies of business solutions or a means to

schedule the releases based on the dependencies of theindividual components within those solutions.


The Release and Deployment Management process does not have clear line of sight to the

detailed dependencies each of the projects have on each other. A general dependency of the

projects may exist, but there is no overall detailed dependency mapping that would allow the

RADM team to determine what components can be deployed independent of any othercomponents.


Document at a component level within the project those dependencies on other architecturalcomponents that are required to deliver the solution to the business. The detailed dependencieswill be supplied to the RADM team so they can appropriately schedule implementations based

on these dependencies.

technical risk assessment

Documents