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 eg space, 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?

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