copyright 2001 perot systems europe. all rights reserved architecture model introduction tim taylor

Copyright 2001 Perot Systems Europe. All rights reserved

Architecture Model Introduction

Tim Taylor

Copyright 2001 Perot Systems Europe. All rights reserved 2

The Model

Initial Scope– Applications currently supported by

Distribution IS

Information collected– Applications

• processes supported– Technologies

• hardware• software• data management

– Data• model and flows

Sources– Application Support– inventory questionnaire– Y2K inventory– interviews– anything else available!


Distribution IS






Tools– CASEwise

• repository• diagramming

– MS Office• data collection and input• reporting

Output– HTML

– CASEwise model

– MS-Office documents (standards)

Tools– CASEwise



Output– HTML

– CASEwise model

– MS-Office documents (standards)

EME Model

Distribution Enterprise Architecture


Standards - Position Today

Operating systems

Databases

Middleware

Communication protocols

Development tools

Business reporting tools

Security

Archiving, backup & restore

Disaster Recovery

System management tools

Hardware platforms

Development & Test environments

Documentation

Service LevelManagement

Cost ManagementAvailabilityManagement

CapacityManagement

ContingencyPlanning

ChangeManagement

Software Control &Distribution

ProblemManagement

Help DeskManagement

ConfigurationManagement

Service Support

Service Delivery

A

R

G

R

G

G

G

A

A

A

A

A

G


Standards - Linking To The Model



CapacityManagement

ContingencyPlanning

ChangeManagement


ProblemManagement

Help DeskManagement


Service Support

Service Delivery

Archive, Backup & Recovery


.DOC

HyperlinksTo HelpNavigation


link to documentlink to documentlink to documentlink to documentlink to document

DBMS - OracleDBMS - Oracle

.DOC

Database ManagementDatabase Management

Availability MgmtCapacity MgmtBackup……...

.DOC


Standards - Linking To The Model



CapacityManagement

ContingencyPlanning

ChangeManagement


ProblemManagement

Help DeskManagement


Service Support

Service Delivery



Database ManagementDatabase Management

Availability MgmtCapacity MgmtBackup……...

.DOClink to documentlink to document

DBMS - OracleDBMS - Oracle

.DOC



link to documentlink to document

.DOC

EME Model


Issues - Architecture

Technical Architecture– The ‘to be’ picture is still some way off being decided– The Distribution 'Programme' is seen to be acting as the default Design Authority

e.g.: project teams are taking MIMS and UDB related decisions that will have a major impact on future architectures, and how they are supported and operated.

Information Architecture– There are too many standalone databases– There is a need for an MI architecture (a standard tool alone does not solve this

issue).

Application Architecture– There is duplicate (potential) functionality in the chosen solutions of the main

programme projects =>potential for consolidation– The existing architecture has potential for consolidation of applications to fewer

servers, beyond that currently planned.

Operational Architecture– There is a lack of coverage in key areas e.g. pre-production standards– There is process ‘overload’ on some of the functional areas


Issues - Model

Relationship with other current / planned initiatives – Business Process Modelling– Systems Integration

Business Architecture

Information Architecture

Technical Architecture

OperationalArchitecture

Ownership Programme Issues with current intention /

message of Business and

Information Architectures

Toolset Architecture review CASEwise Process Modelling MOOD Considerations

costs skills match to requirements (for IS = fit with current model)


Implementation - Architecture

1) Recommended Initial set up– minimum feasible configuration– keep it simple while issues are resolved

Architecture

Costs• Software

1 x Enterprise edition client £ 5,000• Hardware

Standard PC NIL

Total £5k

Architecture

Costs• Software

1 x Enterprise edition client £ 5,000• Hardware

Standard PC NIL

Total £5k

EME Model

EME Model

Distribution IS

Enterprise Edition


Architecture

Costs• Software

Server Option, (Oracle) per Server £10,0001 x Enterprise edition client £ 5,0003 x Professional client £ 7,750

• HardwareOracle server £ 2,000 (free?!)

Total £20 - 22k

Architecture

Costs• Software

Server Option, (Oracle) per Server £10,0001 x Enterprise edition client £ 5,0003 x Professional client £ 7,750

• HardwareOracle server £ 2,000 (free?!)

Total £20 - 22k

IS ApplicationServices

IS Planning &Strategy

IS Operations IS TechnicalServices

Oracle

EME Model

Professional Enterprise EditionProfessionalProfessional

EME Model

Implementation - Architecture2) Possible Phase 2

– indicative Client Server configuration– bed in processes before “hard coding” business rules


Implementation - Architecture3) Possible Phase 3

– integrate with Notes (or other tools)– develop workflow to actively drive IS processes

Architecture

Costs• Architecture (as before) £20-22k• Development estimated 3 weeks 1 x Notes developer

1 x IS model manager

Architecture

Costs• Architecture (as before) £20-22k• Development estimated 3 weeks 1 x Notes developer

1 x IS model manager

IS ApplicationServices

IS Planning &Strategy

IS Operations IS TechnicalServices

Oracle

EME Model

Professional Enterprise EditionProfessionalProfessional

EME Model

Notes server

St a r t Po in t F irs t Step

O p t iona l Step

F in is h

Metadata- processes- roles- groups

St a r t Po in t F irs t Step

O p t iona l Step

F in is h

Workflow


Implementation - Benefits

EventEventManagementManagement• Operational Processes• Application Specific Events

EventEventManagementManagement• Operational Processes• Application Specific Events

Configuration Configuration ManagementManagement• Applications• Network• Operations• Security/Access• etc

Configuration Configuration ManagementManagement• Applications• Network• Operations• Security/Access• etc

• Consistency• Single source of data• Facilitates standards

• Consistency• Single source of data• Facilitates standards

ArchitectureArchitecture• Definition• Impact Analysis

ArchitectureArchitecture• Definition• Impact Analysis

• Impact Analysis• Costs (IS) vs Benefits (Process)

• Impact Analysis• Costs (IS) vs Benefits (Process)

Current State Future StateCurrent State Future State

Tools / Tools / InterfacesInterfaces• CASE tools etc.• DBMSs

Tools / Tools / InterfacesInterfaces• CASE tools etc.• DBMSs

• Reuse (design objects)• Reduced timescales• Facilitates standards

• Reuse (design objects)• Reduced timescales• Facilitates standards

Enabling new Enabling new ProjectsProjects• Check-out/ Kick-start• Reuse• Project Deliverables• Check-in

Enabling new Enabling new ProjectsProjects• Check-out/ Kick-start• Reuse• Project Deliverables• Check-in


Next Steps - Model

Implement current deliverables– Review current content

• Agree IS standards with stakeholders– Implement agreed content

• Implement Phase 1 CASEwise architecture• Resolve tool issues

– CASEwise, MOOD or both?– Develop and agree further Phase plans

Model ScopeModel Scope

ISIS





Develop the model further Further IS standards and processes

more ITIL coverage

Integration with Programme• “to be” definition• business ownership for architecture• full lifecycle processes and standards• roles and responsibilities

ProgrammeProgramme






Next Steps - IS

IS tasks which could be tackled in the short term– Consolidation

• systems software e.g. Operating Systems• hardware e.g. Servers

– Business Continuity• process definition• conducting Business Impact Assessment

– IT Disaster Recovery• Proposal to cover the range of problems from Incidents to full Disasters

– ESM Tool Selection– Change Management

• Co-ordination & streamlining– Proactive Problem Management and Root Cause Analysis

• process definition• selection of tools• gather key problem related information• perform analysis


Next Steps - Programme

Getting visibility of the ‘to be’ direction– Information Architecture (MI / data warehouse)– Assistance is resolving the outstanding Systems Architecture decisions with major

impact on IS e.g. application consolidation– Help in resolving (quickly) the questions on the Technical Architecture with major

impact on IS e.g. Middleware

Copyright 2001 Perot Systems Europe. All rights reserved

Distribution ISSupporting the Programme

5 December 2000


Progress Update

--- Objectives --- Collate inventory of current technology

base

Define IS Standards and Processes

Create an accessible repository for this information

Highlight key architectural issues and areas for improvement

Highlight any gaps in the coverage of the IS ‘life-cycle’

Align IS with Distribution business strategy

Reduce cost of IT ownership


base








Collate inventory of current technology base


Distribution IS







Distribution IS






Tools– CASEwise



Output– HTML– CASEwise model– MS-Office documents (standards)

Status– Version 1 published 30 Nov– Initial PS draft with EME QA,

refinement and addition– Manual feedback loop until

processes agreed

Tools– CASEwise



Output– HTML– CASEwise model– MS-Office documents (standards)

Status– Version 1 published 30 Nov– Initial PS draft with EME QA,

refinement and addition– Manual feedback loop until

processes agreed

EME Model


Progress Update


base



base


--- Status --- First pass published within IS and

presented to IS Teams

Framework and ownership agreed






Operating systems

Databases

Middleware

Communication protocols

Development tools

Business reporting tools

Security

Archiving, backup & restore

Disaster Recovery

System management tools

Hardware platforms

Development & Test environments

Documentation



CapacityManagement

ContingencyPlanning

ChangeManagement


ProblemManagement

Help DeskManagement


Service Support

Service Delivery

A

R

G

R

G

G

G

A

A

A

A

A

G


Progress Update


base




base






CASEwise for initial release






Progress Update


base





base








Presented to IS management team







Highlight key architectural issues

Technical Architecture– The ‘to be’ picture is still some way off being decided– The Distribution 'Programme' is seen to be acting as the default Design Authority

e.g.: project teams are taking MIMS and UDB related decisions that will have a major impact on future architectures, and how they are supported and operated.

Information Architecture– There are too many standalone databases– There is a need for an MI architecture (a standard tool alone does not solve this

issue).

Application Architecture– There is duplicate (potential) functionality in the chosen solutions of the main

programme projects =>potential for consolidation– The existing architecture has potential for consolidation of applications to fewer

servers, beyond that currently planned.

Operational Architecture– There is a lack of coverage in key areas e.g. pre-production standards– There is process ‘overload’ on some of the functional areas


Progress Update


base






base



















Scope of current architecture deliverables limited to IS Operations– “current state” architecture

ISIS





For full benefit to be realised requires integration with business change• “to be” definition

• business ownership for architecture

• full lifecycle processes and standards

• roles and responsibilities

ProgrammeProgramme






Progress Update


base








base













Purpose of this meeting!







Purpose of this meeting!






Areas for Co-operation - Architecture

Ensuring Technical Architecture is aligned with business objectives - and reflects future state

Information Architecture definition– information model– mapping to current state

Short term requires agreement on– terms of engagement– data exchange between repositories


Areas for Co-operation - Project Lifecycle

• Architecture fit• Detailed

requirements

• Technical Design

• Architecture planning

• User procedures

• Build & test environments

• Support• Technical

Procedures

• Operational Acceptance

TransitionTransitionBuild & TestBuild & TestSolutionDefinition

SolutionDefinition

System Requirements

System Requirements

InitiationInitiation

• Scoping• Impact Analysis

Throughout project life cycle– use Summit D roles & responsibilities

Risk reduction

Cost savings (full lifetime cost)– design reuse– project “kick start”

Question: what is the Programme relationship to Projects?

Question: what is the Programme relationship to Projects?


Areas for Co-operation - Project Lifecycle





Cross Project co-ordination / integration

“United front” => greater chance of success (?)


Drivers of Change Industry Economic Technology Environment Regulation/Politics

BusinessBusinessStrategiesStrategies


Information StrategyInformation Strategy& Technology& Technology

PlanningPlanning


PlanningPlanning

Business & Business & ManagementManagement

ProcessesProcesses


ProcessesProcessesInformationInformation

ServicesServices

InformationInformationServicesServices

Technologychanges

Areas for Co-operation - Strategy

Strategic Alignment Model


Areas for Co-operation - Strategy

Strategic Alignment Model– issues with Alignment of IT and Business– no clear IT strategy– IS roles agreed, but Technical Architecture needs to be developed to meet

business objectives




ProcessesProcesses


ProcessesProcessesInformationInformation

ServicesServices

InformationInformationServicesServices

Technologychanges


PlanningPlanning

copyright 2001 perot systems europe. all rights reserved architecture model introduction tim taylor

Documents