Enterprise Architecture and Risk Management - Home - · PDF fileTitle: Enterprise Architecture...

Copyright © 2012 OAD Consulting, Inc. Slide 1

Building Business Capability

IncorporatingEnterprise Risk Management

intoEnterprise Architecture

Terry MerrimanChief Architect

OAD Consulting, Inc.

Copyright © 2012 OAD Consulting, Inc.

EA/ERM Framework

ObjectivesProvide an EA framework that integrates with the solution architectureUses open standards and is extensible

Configuration changesMetamodel changesReport modifications and additions

Tracks the architectural viewsShows the enablement of business processesShows various points in time (As‐Is / To Be)Extend the EA framework with ERM concepts

Slide 2


An Integrated Approach to Enterprise Architecture & Enterprise Risk Management

Based on Numerous StandardsRM-ODPRUPTOGAFArchiMateCOSO

Models the Different Architectural ViewsBusinessInformation SystemsInfrastructure

Provides Information for Strategic PlanningBusiness Process RealizationsFuture State RoadmapsProject Portfolio Management

Integrates with Risk ManagementObjectivesRisks & OpportunitiesRisk ResponsesManual & Automated ControlsTransactional and Analytical Data

TechnologyArchitecture

Hardware, Software, Network

ApplicationArchitecture

Services

DataArchitecture

Data Information

Business Architecture

Business Processes, Organization, People

ERM / Key Risks

Financial, Business and IT Controls

KPIs / Key Metrics

Continuous Monitoring

GRC Integrated Framework


Imagine your architecture as a 3-dimensional spaceArchitectural Assets

What’s in the Box?

Modeling Enterprise Architecture


Who is Interested?

Architectural Stakeholders


Audit & Compliance Personnel


How Do We AddressAll of Their Needs?

Architectural Stakeholders




Service Driven Multi-dimensional Set of Architectural Views


Through a Separation of Concerns

To address the needs of:The StakeholdersThe Business ProcessesThe Future



BusinessArchitecture

InformationSystems

Architecture

InfrastructureArchitectureH

oriz

onta

l Slic

esA

rchi

tect

ural

View

s

Through a Separation of Concerns

Horizontal Slices provide an inventory of architectural assetsand their relationships within each view (layer)

Application Architecture

Data Architecture

TOGAF Provides Architectural Views with Services


InformationSystems

Architecture

InfrastructureArchitecture

EA Services provide stable specifications of architectural needsand a categorization of architectural elements

Modeling Enterprise ArchitectureH

oriz

onta

l Slic

esA

rchi

tect

ural

View

s

EA Services “Glue” the Layers Together

Using an Enterprise Level Service Taxonomy

Different layers have different life-cycles




InformationSystems

Architecture

Lower level elements provide specific service specializations


oriz

onta

l Slic

esA

rchi

tect

ural

View

s

«IT App»SQL Server 2005



Architectural elements implement the service specializations

Higher level elements require generic services

Service Specializations

Service Requirements



InformationSystems

Architecture






oriz

onta

l Slic

esA

rchi

tect

ural

View

s

Vertical SlicesBusiness Process Realization Architectural Requirements

ArchiMate provides a layered approach to show how IT is aligned with the Business and provide a means to discover architectural requirements



oriz

onta

l Slic

esA

rchi

tect

ural

View

s

Vertical SlicesBusiness Process Realization Architectural Requirements

Futu

re S

tate

Roa

dmap

Futu

re S

tate

Roa

dmap

Futu

re S

tate

Roa

dmap

Futu

re S

tate

Roa

dmap

Roadmaps show how the architecture is to change over time.Projects align with the Roadmaps to affect the change.

Cur

rent

Sta

te

Futu

re S

tate



InformationSystems

Architecture



Copyright © 2012 OAD Consulting, Inc. Slide 13C

urre

nt S

tate

Futu

re S

tate



InformationSystems

Architecture



Enterprise Risk Management

Planning

Proj

ect P

ortf

olio

M

anag

emen

t Execution

Risk Mediation


Driving the Project Portfolio


Architectural Details

The ImplementationBuilt on the open standards of UML & SQLGuided by metamodels

Cur

rent

Sta

te

Futu

re S

tate



InformationSystems

Architecture





Goals of an ERM FrameworkTo discover and validate the existing controls within the architectureTo discover those that are needed but absentTo determine the level of support required for missing controlsTo design a control solution that provides continuous monitoring of the effectiveness of the controlsTo provide strategic and tactical input into the project portfolio to ensure the appropriate level of risk mitigation and monitoring is in place


Financial Risk Management

«Strategic Objective»Maintain ROI

«Objective»Maintain Cash Conv ersion Period of

25 Days or Less

«Risk»Late Payments

«Risk Response»Avoid Payments

«Control»Outstanding Inv oice Alert

«Risk»Increase in Inv entory Value

«Control»Customer Credit Limit

Establishment

«Control»Inv entory Value Control

«Control»Inv entory Purchase Approv al

«Risk Response»Increase in Inv entory Value

«Risk Response»Accept Late Payments

«Details Strategic Objective»

«May Impact Objective»

«Selected Response»

«Addresses Response»

«May Impact Objective»


«Addresses Response»«Addresses Response»


«Candidate Response»

Enterprise Risk ManagementKey Elements of an

ERM Framework

• Objective Categories• Strategic Objectives• Objectives• Risks• Risk Responses• Controls



Key Elements of an ERM FrameworkObjective Categories

Provide a way of organizing the objectivesStrategic Objectives

Address different concerns within the categoryAre top level objectives

Objective Categories and Strategic Objectives



Key Elements of an ERM FrameworkObjectives detail the strategic objectives

Are of three types– Operational– Reporting– Compliance

Objective data points– Measure: Indicates how the objective is measured– Target: What the desired measure is– Tolerance: The permitted deviation from the target

Objectives



Key Elements of an ERM FrameworkRisks may adversely impact the objectivesRisk data points

Event Level– Indicates the scope of the risk– Industry, Entity, Business Unit, Process

Leading indicator– Predicts future likelihood of the risk

Escalation trigger– The measure of the leading indicator that triggers the need for action

Likelihood– The likelihood that the risk will occur within the time horizon

Time horizon– The time period during which the risk may occur

Impact– Quantitative cost should the risk occur– May be a financial cost, a hit to the company’s reputation, etc

Risks



Key Elements of an ERM FrameworkRisk Responses provide possible solutions to mitigate the risks

Each risk may have one or more risk responseEach risk response represents a trade off between the cost of the risk and the cost of the mitigationEach response may be to avoid, reduce, share, or accept the risk

Risk response data points (residual risk)Estimated cost of implementationResidual impactResidual likelihoodResidual impact

Risk Responses



Key Elements of an ERM FrameworkControls provide a means to mitigate riskControls relate to actions that are taken

Following policies– manual check lists

Performing business activities– Manual activities described in the business process model

Invoking IT solutions– IT services that represent the automation of activities from the business

process model

Charting compilations– Typically, spreadsheets containing 10’s to 100’s of controls at a fine grained

level– For example, the dozens of controls within SAP regarding the month‐end

closing process

Controls



Key Elements of an ERM FrameworkControls should be verified by

Reports showing the results of the control’s actions – Some are manually generated and others automatically generate by the IT

solution

Control results should be continuously monitored by…PeopleAutomated systems

Controls may have remedial actions should objectives not be metManual activitiesAutomated systems

Control results should be reviewed to determine whether adjustments must be made

Controls



Key Elements of an ERM FrameworkThe key objective of instituting an ERM policy is not to automate as much of the process as is possible…But rather to balance the cost of the impact of each risk against the cost of implementing a risk response to the risk…And having implemented the selected risk responses, to continuously monitor the effectiveness of their controls to ensure that objectives are met within their level of approved toleranceThe focus of this presentation has been on risk mitigation, but the same framework can be used for performance evaluation



Phases of ERMPlanning

Risk Response 2

Residual RiskCost of Implementation

Objectiv e3Objectiv e2

Risk3Risk2

Establish Risk Env ironment

Set Objectiv es

Identify Risks that May Impact the Objectiv es

Automated Detectiv e Control

Risk

LikelihoodImpactTime HorizonLeading IndicatorEscalation Trigger

Objectiv e

MeasureTargetTolerance

Risk Response 1

Residual RiskCost of Implementation

Manual Detectiv e Control

Automated Prev entiv e Control

Manual Detectiv e Control 1

Manual Control 2

Manual Control 3

Determine Candidate Risk Responses

Make Manual Remediation Changes

Make System Remediation Changes

Determine Control Rationalization

Avoids, Reduces, Shares or Accepts

Impacts

CandidateResponse

Selected Response

Copyright © 2012 OAD Consulting, Inc.

Phases of ERMPlanningExecution

Slide 26


Manual Detectiv e Control

S/W Applications

Automated Detectiv e Control

Transactional Data

Manually Generated Compliance Report

System Generated Compliance Report

Spreadsheets, Access Databases, etc.

Automated Prev entiv e Control

Transaction Processing Component

Produces Guards

Influences

Exported Data

Monitors

ProducesProduces Utilizes

Monitors



Phases of ERMPlanningExecutionRisk MeditationImplementationContinuous Monitoring

Risk Response 4

Automated Detectiv e

Control

Automated Prev entiv e

Control


Control

Risk Response 2

Determine if Objectiv es Hav e Been Met

Control/Process Remediation

Make Manual Remediation Changes

Make System Remediation Changes

Determine Control Rationalization

Manually Generated Compliance Report

System Generated Compliance Report

Spreadsheets, Access Databases, etc.

Risk Response 3

Executiv e Reports

Objectiveswere met?

Objectiv e3Objectiv e2

Objectiv e


Control

Manual Detectiv e

Control


Control


Control


Control


Control

Continue monitoring

[No]

[Yes]

Selects

Creates


Enterprise Risk Management ExampleExample: Hazardous Waste Risk Management

«Objective Category»Hazardous Waste Risk Management

«Objective»Ensure No Env ironmental Damage is Incurred

Along with any Subsequent Fines.

«Strategic Objective»Maintain a Safe, Productiv e Workplace,

Complying with all Regulations

«Objective»Report All Incidents in a Timely and

Transparent Manner

«Risk»Corrosion on Barrels Causes

Material to Leak

«Risk»Unsafe Transport Conditions Cause Barrels to Explode in

Transit

«Risk»Equipment Failure Causes Deep

Water Pump Failure

«Risk Response»Proactiv e Barrel Replacement

«Risk Response»Accept Barrel Leakage

«Risk Response»Maintain Fire Retardent Systems

«Risk Response»Maintain Drilling Equipment at Optimum

Performance

«Risk»Responsible Party/Parties Falsify

Documents

«Risk Response»Three Indiv iduals within at Least Two

Reporting Hierarchies Must Verify Document Accuracy

«Risk Response»Reactiv e Barrel Replacement


«May ImpactObjective» «May Impact

Objective»


«May ImpactObjective»

«Selected Response»«CandidateResponse»


«CandidateResponse»

«May ImpactObjective»

«Details StrategicObjective»

«Details StrategicObjective»


Enterprise Risk Management Example

1st Candidate Response

«Risk Response»Accept Barrel Leakage

Risk Responses


«Risk Response»Reactiv e Barrel Replacement

«Organizational Unit»Vendor Management

Vendor Relations Manager

George Benard

«Control»Vendor Control

«Policy»:Vendor Selection

Requirements

«Report»:Vendor Selection Check Off Sheet

«Activ ity»

:Replace Barrels

«Activ ity»

:Paint Barrel

«Control»Manual Barrel

Inspection Control

«Activ ity»

:Inspect Barrels for Defects

«Report»:Barrel Inspection Report

«RACIRole»

«RACIRole»

«RACI Role»

«AddressesResponse»

«Control Action»

«Control Verification»


«Control Action»


«ControlRemediation»



2nd Candidate Response


«Risk Response»Proactiv e Barrel

Replacement

«Activ ity»

:Replace Barrels

«Activ ity»

:Paint Barrel

«Organizational Unit»Vendor Management

Vendor Relations Manager

George Benard

«Control»Manual Barrel

Inspection Control

«Control»Vendor Control

«Control»Automated Barrel Monitoring Control

«Policy»:Vendor Selection

Requirements

«Activ ity»

:Inspect Barrels for Defects

«Report»:Barrel Inspection Report

«Report»:Vendor Selection Check Off Sheet

«IT Service»:Inv entory

Management Serv ice

«Report»:Inv entory Aging

Report


«Control Action»

Accountable

«RACIRole»

Responsible

«RACIRole»


Informed«RACI Role»

«Control Action»


«Control Action»


«ControlRemediation»«Control

Remediation»



«Control Remediation»


Enterprise Risk Management ExampleSelected Response



Healthcare Example«Risk Response»

Unsigned Manual Response

«Risk»Unsigned Patient

Authorization Form

«Activ ity»

:Walk Through Inspection

«Control»Manual Patient

Admission Control

«Policy»:Patient Admission

Policy

«Activ ity»

:Contact Patient for Additional Info

«Report»:Patient Forms

Inspection Report

«Report»:Walk Through

Inspection Report

«Activ ity»

30% of the Population :Sample Patient Documentation


«Candidate Response»



«Control Action»«Control Action»


«Control Action»



«Risk»Unsigned Patient

Authorization Form

«Risk Response»Unsigned Mixed

Response

«Control»Automated Patient Admission Control

«IT Service»Scan and Verity Admissions Form :

Document Scanning Serv ice

«Activ ity»

:Walk Through Inspection

«Policy»:Patient Admission

Policy

«Activ ity»

:Contact Patient for Additional Info

«Report»:Patient Forms

Inspection Report

«Report»:Walk Through

Inspection Report

«Activ ity»

10% of Population :Sample Patient Documentation

«Report»:Automated Forms Inspection Report

«Activ ity»

:Ask Patient for Missing

Information

«Control»Manual Patient

Admission Control



«Control Action»




«Control Verification» «Control Verification»


«Control Action»«Control Action»

«Control Action»



Healthcare Example


Integrating ERM with EA


Enterprise Risk ManagementNon-Architectural View


What We Have Accomplished

Captured each architectural view along with life‐cycle informationShown how the applications and database schemas interact to realize key scenariosShown the key architectural elements involved in the business process realizationsAdded roadmaps and projects to provide portfolio managementIntegrated risk management with the business policies, activities, and services of the architectural views



Going From Chaos


Continuous MonitoringObjectives – Risks - Controls


InformationSystems

Architecture

InfrastructureArchitectureH

oriz

onta

l Slic

esA

rchi

tect

ural

View

sVertical Slices

Business Process Realization Architectural Requirements



Futu

re S

tate

Cur

rent

Sta

te

To Strategic Planning

Copyright © 2012 OAD Consulting, Inc. Slide 40Back

Terry MerrimanChief Architect

[email protected]

+1-610-998-2878www.EA2.us


Supporting Architectural Slides


Cur

rent

Sta

te

Futu

re S

tate



InformationSystems

Architecture





Concerns of Business ArchitectureBusiness ObjectivesBusiness Needs (High Level Requirements)Business ProcessesBusiness InformationBusiness Policies and RulesRequirements

Business needs (high level requirements)Use cases


Business ArchitectureBusiness Processes

MemberEligibi l ityPolicies

Membership Policy Definition Process

MemberEligibi l ityPolicies

ProgramPolicies Roster

Eligibil ityPolicies

Sports Program Dev elopment Policy Definition Process

ProgramPolicies Roster

Eligibil ityPolicies

GameResults

Post-Season Ev ent Process

GameResults

Divisions& Teams

Sports Program Dev elopment Process

Divisions& Teams

Season Execution Process

GameOfficials

Registrations

Registration InfoMember Registration

Process

GameOfficials

Registrations

Registration Info

Schedules

Schedule Games Process

Schedules

Venues,Calendars, &

Officials

Venues, Calendars, and Game Officials Setup Process

Venues,Calendars, &

Officials

«EA2 Receive Event»League Registration Opening

Date

«EA2 Receive Event»League Registration Final Close

Date

«EA2 Receive Event»

Season Close Date


Season Opening Date


Season Setup Date


League Setup Date

Accounting Process

«Impacts»

«Initiates» «Initiates»

«Initiates»

«Ends»

«Initiates»

«Ends»

«Initiates»

[Changes to LeagueComponents]

«Initiates»


Business ArchitectureBusiness Information Model



Business Policies and Rules



Requirements Traceability


Business ArchitectureSample Report – Tracing Objectives to Use Cases



Concerns of Application ArchitectureRoles and actorsComposition of logical componentsInterface definitionsInteractions through interfaces

Implementation of interfaces (Provided Interface)Requirement for an interface (Required Interfaces)Integration styles to be employed

Application behaviorTechnology Requirements


Business System Components




Interface Definitions and Usage

«App Interface»iPlayer Rating Session

+ ratePlayersStatistically(int) :void+ setPlayerRating(int) :void+ updateRatingDefs() :void

«Presentation»Player Manual Rating

Presentation

«Work Session»Player Rating Session

«Async»iPlayerRatingPages

«Presentation»Player Statistical Rating

Presentation



«Business App»Player Rating Engine

«Async»iPlayerRating

Team Assigner Program Dev elopment DB Schema

«R/W» SQL

«Service»Player Serv ice

A«ESB»iPlayer

Member Management DB Schema

«ETL»Member toProgDev

«R/W» SQL

«Service»Sports Program Serv ice

«ESB» iSportsProgram

«Service»League Serv ice«ESB»

iLeague

«Service»Player Rating Serv ice

«Sync»iPlayerRating

«Service»Logging Serv ice

«ESB»iLoggingService

«ESB» iLoggingService

«ESB»iPlayer

«Business App»Player Rating Front

End Application

«UI»iManualRating UI

«UI»iStatisticalRating UI

«ESB» iLoggingService

«ESB»iPlayer

«Service»Single Signon

Serv ice

«ESB» iLogin «App Interface»iPlayerRating

+ getPlayerRating(long) :int+ setPlayerRating(int, long) :void+ ratePlayersStatistically(ID, xmlPlayerRatingParameters) :void

Application Context DiagramShows the Business Applications, Services, DB Schemas and their interactions through interfaces for a given scenario



Application Component Context DiagramDetailed view of the application components and their interactions


Integration StylesDetails the integration styles represented on the context diagrams



Application BehaviorDetails the system flow of component interactions


:Team Assigner«Internal Role»

«Business App»PRFE :Player Rating Front End

«Service»SCS :Sports Club Service

«EA2 EDB Schema»:Program Development DB

Schema

«Service»:Sports Program Service

«Service»:Player Rating Service

iSportsClubiStatistical Rating UI SQLiSports Program iPlayerRating

GetClubList(pMemberID) :string

:Club List

:Club List

DisplayClubList

Select Club

GetClub(pName) :xmlSportsClub

GetSportsProgram :SportsProgram

:SportsClub

:xmSportslClub

DisplayClubInfo

GetSportsProgramList(clubID) :string

:Sports Program List

S t P Li t


Application ArchitectureSample Report – Logical Dependencies


Application ArchitectureSample Report – Shows Where Data is Being Passed


Application ArchitectureSample Report – Data Flow through a Set of Scenarios


Data Architecture

Concerns of Data ArchitectureDB SchemasDB schema accessETL Jobs with scheduling informationStored proceduresXML documentsEnterprise level data definitions


DB Schemas with Logical/Physical Design

Data Architecture

«ETL»Member toProgDev

Program Dev elopment DB Schema

«R/W» SQL «ETL»Member toProgDev

«Stored Proc»Program Maintenance


XML Documents

Data Architecture


ETL Jobs

Data Architecture


Infrastructure Architecture

Concerns of Infrastructure ArchitectureActors, and VendorsNetwork and Site informationIT Software and ServicesHardware Model ConfigurationsDeployed Hardware Based on the ModelsExecution Environments


Infrastructure Architecture

SCMS-101 :Proliant ML570

«EA2 IP»123.232.45.2


«EA2 IP»123.232.45.1


«EA2 IP»123.323.45.3


«EA2 IP»123.323.45.4

Quest ISP

«EA2 IP»150.39.56.1

Paris :Cisco 4006«EA2 IP»123.323.44.1

«EA2 IP»123.323.42.2

Internet

Paris FW :Cisco Firewall

«EA2 IP»123.323.42.1

«EA2 IP»123.323.41.2

Paris :Cisco Local Director

«EA2 IP»123.323.44.8

«EA2 IP»123.232.45.255


«EA2 IP»123.323.44.6


«EA2 IP»123.323.44.5

Paris :iNET Connection

«EA2 IP»150.39.56.121

«EA2 IP»123.323.41.1


«EA2 IP»123.323.44.7

SCMS-01 :Compaq DL380

«EA2 IP»123.323.44.9

«EA2Active/Passive

Fail Over»

«EA2Active/Active

Fail Over»

Network Topology


Infrastructure ArchitectureServer Deployments


Infrastructure ArchitectureSample Report – Server Deployments


EA Service TaxonomyEA Service Taxonomy Provides…

A way to create stable architectural requirements while tracking the underlying changes in the elements realizing the requirementsA way to categorize the functionality provided by architectural elements and a way to eliminate redundant implementationsA way to plan the introduction and elimination of entire technologies with minimal effort


TOGAF provides a starter taxonomy of applications, interfaces, and

services than can be modified to fit your environment

EA Service Taxonomy


Data ManagementData dictionary/repository services Database management system (DBMS) services Object Oriented Database Management System services File management services Query processing functions Screen generation functions Report generation functions Networking/concurrent access functions Warehousing functions

The categories contain similar but distinct services.



EA Service Taxonomy


Software Engineering Services Programming language services Object code linking services Computer Aided Software Engineering (CASE) environment and tools services Graphical User Interface (GUI) building services Scripting language services Language binding services Run Time Environment services

Application Binary Interface services

The categories contain similar but distinct services.



This was the hardest part!

EA Service Taxonomy

Combination of callable (SOA) and non-callable services - a superset of

an SOA service taxonomy


Infrastructure elements provide implementations

of the Service Specializations.

Service Layer includes:- EA Business Service- EA App Service- EA IT Service

This slide shows a few IT Services

Service Category groups similar

Services

Services are required by architectural

elements

Service Specializations provide technology

and/or standards based methods for

implementing Services.

EA Service Taxonomy

«IT App»SQL Serv er 2005


Extended Service Taxonomy

EA Business Services- Capabilities required by external constituents- Implemented by Business Processes’ Activities

EA Information System Services- Capabilities required by Business Activities- Implemented by Business Applications

and enterprise level DB Schemas

EA Infrastructure (IT) Services- Capabilities required by Business Applications- Infrastructure supplies service specializations- Implemented by IT Software


Extended Service Taxonomy

Sample Report – EA Service Taxonomy (IT Service Layer)


Business Process Realizations


BP Realization Sample ReportThis shows each layer’s required services and the configuration items that provide the services within the context of the Business Process


Roadmaps and Projects

RoadmapsDefine the future state representation of the architecture

Roadmap PhasesProvide an iterative/incremental implementation

ProjectsAlign to Roadmap Phases and implement the architectural vision


Roadmaps & Business Process Realizations


CMDB Style Sample Report

This report shows the deployment status of configuration items for a five year period. It organizes them by the IT Service they provide. The report can also show configuration items that provide Business and IS services.


Project Scope

Linking a Project to all Impacted Architectural ElementsBusiness Objectives Business Needs Use Cases Use Case Realizations


Project ScopeSample report showing all architectural elements impacted by a project, including elements from all Use Case Realization diagrams


Enterprise Risk ManagementNon-Architectural View

Enterprise Architecture and Risk Management - Home - · PDF fileTitle: Enterprise Architecture...

Documents

Transcript of Enterprise Architecture and Risk Management - Home - · PDF fileTitle: Enterprise Architecture...