1 / 30

Architecture Model Introduction

Architecture Model Introduction. Tim Taylor. 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

muhammed-femi
Download Presentation

Architecture Model Introduction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Architecture Model Introduction Tim Taylor

  2. 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! Tools CASEwise repository diagramming MS Office data collection and input reporting Output HTML CASEwise model MS-Office documents (standards) The Model

  3. G G R G A A A G R A A A G 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

  4. Database Management Availability Mgmt Capacity Mgmt Backup ……... .DOC Hyperlinks To Help Navigation DBMS - Oracle .DOC link to document link to document link to document link to document link to document Archive, Backup & Recovery .DOC Standards - Linking To The Model

  5. Database Management Availability Mgmt Capacity Mgmt Backup ……... link to document link to document .DOC Hyperlinks To Help Navigation DBMS - Oracle .DOC link to document link to document Archive, Backup & Recovery .DOC Standards - Linking To The Model

  6. 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

  7. Issues - Model • Relationship with other current / planned initiatives • Business Process Modelling • Systems Integration • 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)

  8. Distribution IS 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

  9. IS Planning & Strategy Implementation - Architecture 2) Possible Phase 2 • indicative Client Server configuration • bed in processes before “hard coding” business rules Architecture Costs • Software Server Option, (Oracle) per Server £10,000 1 x Enterprise edition client £ 5,000 3 x Professional client £ 7,750 • Hardware Oracle server £ 2,000 (free?!) Total £20 - 22k IS Application IS Operations IS Technical Services Services Oracle

  10. Metadata - processes - roles - groups IS Planning & Strategy Implementation - Architecture 3) 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 Workflow IS Application IS Operations IS Technical Services Services Oracle Notes server

  11. Current State Future State Architecture • Definition • Impact Analysis Configuration Management • Applications • Network • Operations • Security/Access • etc Enabling new Projects • Check-out/ Kick-start • Reuse • Project Deliverables • Check-in • Impact Analysis • Costs (IS) vs Benefits (Process) Reuse (design objects) Reduced timescales Facilitates standards Consistency Single source of data Facilitates standards Event Management • Operational Processes • Application Specific Events Tools / Interfaces • CASE tools etc. • DBMSs Implementation - Benefits

  12. Model Scope Programme IS 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 • 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

  13. 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

  14. 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

  15. Distribution ISSupporting the Programme 5 December 2000

  16. --- 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 Progress Update

  17. 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! Tools CASEwise repository diagramming MS Office data collection and input reporting 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 Collate inventory of current technology base

  18. --- Objectives --- Collate inventory of current technology base Define IS Standards and Processes --- Status --- First pass published within IS and presented to IS Teams Framework and ownership agreed Progress Update

  19. G G R G A A A G R A A A G Define IS Standards and Processes 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

  20. --- Objectives --- Collate inventory of current technology base Define IS Standards and Processes Create an accessible repository for this information --- Status --- First pass published within IS and presented to IS Teams Framework and ownership agreed CASEwise for initial release Progress Update

  21. --- 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 --- Status --- First pass published within IS and presented to IS Teams Framework and ownership agreed CASEwise for initial release Presented to IS management team Progress Update

  22. 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

  23. --- 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’ --- Status --- First pass published within IS and presented to IS Teams Framework and ownership agreed CASEwise for initial release Presented to IS management team Presented to IS management team Progress Update

  24. Programme IS Highlight any gaps in the coverage of the IS ‘life-cycle’ • Scope of current architecture deliverables limited to IS Operations • “current state” architecture • 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

  25. --- 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 --- Status --- First pass published within IS and presented to IS Teams Framework and ownership agreed CASEwise for initial release Presented to IS management team Presented to IS management team Purpose of this meeting! Progress Update

  26. 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

  27. Areas for Co-operation - Project Lifecycle • Throughout project life cycle • use Summit D roles & responsibilities • Risk reduction • Cost savings (full lifetime cost) • design reuse • project “kick start” Initiation System Requirements Solution Definition Build & Test Transition Scoping Impact Analysis Architecture fit Detailed requirements Technical Design Architecture planning User procedures Build & test environments Support Technical Procedures Operational Acceptance Question: what is the Programme relationship to Projects?

  28. Areas for Co-operation - Project Lifecycle • Cross Project co-ordination / integration • “United front” => greater chance of success (?)

  29. Areas for Co-operation - Strategy • Strategic Alignment Model Drivers of Change • Industry • Economic • Technology • Environment • Regulation/Politics Information Strategy & Technology Planning Business Strategies Technology changes Information Services Business & Management Processes

  30. 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 Business Strategies Information Strategy & Technology Planning Technology changes Information Services Business & Management Processes

More Related