1 / 10

IT Architecture at Imperial College

IT Architecture at Imperial College. Paul Allatt, Head of IT Services and Deputy Director ICT. Approach. High Level Architecture Group – Director, Head of Sections plus some seniors Architecture Team to support above – 2 people Involved with JISC EA group

azura
Download Presentation

IT Architecture at Imperial College

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. IT Architecture at Imperial College Paul Allatt, Head of IT Services and Deputy Director ICT

  2. Approach • High Level Architecture Group – Director, Head of Sections plus some seniors • Architecture Team to support above – 2 people • Involved with JISC EA group • Started with Technical Architecture • Enable better understanding between Business Systems (choosing products on functionality and business requirements) and Technical Operations (who had to run the systems chosen but had no input into the choice) • Annual Architecture Objectives – either investigative or project based • Eg server virtualisation, common sign on

  3. What we achieved • Architecture principles – eg single version of the truth; common sign on; easy to use software • Technical Architecture – which OS, which database technologies, web stacks, browsers, authentication protocols etc • Checklist for use by Business Systems to guide suppliers • This asks the right questions to ensure best fit with technical infrastructure • Mechanism for handling exceptions (risk based) • Commissioned projects eg common sign on (single username and password to access all central systems), virtualisation

  4. TOGAF • Architecture team and some others went on TOGAF training • IT Architecture = Business + Data + Applications + Technology • Realised we did rather more ‘architecture’ then we thought particularly in the business architecture area inside Business Systems (process and functional analysis and requirements) • TOGAF Principles – very powerful • Name, Statement, Rationale, Implications

  5. Example • Statement • Data is an asset, it has value and should be managed accordingly • Rationale • Data is a valuable corporate resource to aid timely and accurate decision making • Implications • Data stewardship not ownership • Each data item has a clearly defined source which is documented and readily available

  6. Issues • Mostly in Data Architecture area • Definitions – we have multiple definitions of FTE, hierarchies • Central and Deptal systems – duplication of data; lack of trust in central info, gaps so need to ‘enhance’ locally etc • Interfaces/data feeds – lots of these which pull/push data from one system to another; many are very similar (we never remove old ones) • https://share.imperial.ac.uk/services/ict/BusSys/ApplicationSupport/default.aspx

  7. Where Next? • We have defined the architecture vision within ICT • We now need to embed the architecture approach into our delivery • Business Systems have reorganised into product domain based support teams egspace, finance, people • Beginning to look at all systems in a ‘domain’ • What data is held in which system? • Is data in the right place? • Are there things missing? • What is our ideal architecture? • How do we move this forward in a planned, organised way?

  8. Where Next continued • SOA, part of our applications architecture, requires standardisation of data to enable effective linking of systems and provides an opportunity to sort out the data feed ‘spaghetti’ and replace with small number of services (lower maintenance) • Can we identify opportunities to sort some of our data issues? • - if you talk about architecture no one wants to know/understands • - But if you can demonstrate benefits, cost savings etc then they listen

More Related