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
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
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
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
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
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
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?
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