Earlier this year we launched a new team within IT Services: the Technical Architecture Virtual Team. I lead this team, reporting via the Assistant Director of IT Services for Services Development (the team’s Sponsor) to the Senior Management Team. The team is made up of a small number of technical experts within the department, representing key aspects of the University’s IT Architecture: Networks, Storage, Resilience, Applications, Middleware, Data Centre and Infrastructure.
The key problem the team seeks to tackle is aligning the infrastructure services with the University’s application (or “business”) services. We need greater alignment than we currently have so that we can:
- be confident that any proposed change in the infrastructure architecture (e.g. moving from an M5000 Sun Server storage solution to a Nimble storage array) will suit the requirements of the application architecture (and that we can manage the migration carefully and with predictable outcomes),
- be confident that we can plan for any design change in the application architecture (e.g. replacement of a set of finance and HR systems with an ERP system) to be supported by the most appropriate infrastructure solution, with best use of infrastructure resources and according to agreed principles around resilience and so on,
- troubleshoot effectively when systems failure occurs (e.g. discover an infrastructure layer failure that causes failure of a business service, by having accurate, realtime data on, for example, precisely which individual servers in a private cloud were supporting the business service at the time),
- maintain systems more effectively (e.g. be able to take down particular database instances for maintenance, in a modular, scheduled and managed way, with minimal impact on service),
- optimise the IT architecture holistically on an ongoing basis – i.e. create new architectural designs (taking advantage of cloud storage solutions or identifying opportunities for shared services at the sector level for example) based on a clear definition of the requirements that the IT applications architecture has on infrastructure.
We can view the relationship between these layers conceptually as in this diagram (click to enlarge):
It is important to articulate the set of conceptual Applications (or “business”) services we need to support as well as the set of physical applications we have deployed in order to realise those conceptual services. Similarly, it is important to articulate the set of conceptual Infrastructure services required to support the applications layer, as well as the physical implementation of them. This is so we can assess the design of the entire IT architecture according to an holistic, requirements-driven approach rather than being driven purely by technology favouritism for example. The team is currently documenting (using the Archimate modelling standard) our architectures according to agreed conventions that work best for us.
We will need to maintain this documentation on an ongoing basis for two key purposes: i) Troubleshooting: we are currently investigating how we can export realtime live configuration information from our virtualised infrastructure layers into this common visual format (and how to sync it with our Helpdesk application – we use a product called Topdesk – to assist IT first line and second line support), ii) Design: by being able to combine various Archimate models of our architecture into more holistic, architectural overviews, we aim to be able to focus on known weaknesses in our architecture and plan target architectures and the roadmap for change in an informed, aligned way.
At the same time we are using a Bricks approach to evaluate individual Architecture Building Blocks (see for example https://enterprisearchitecture.nih.gov/Pages/WhatIsBrick.aspx ) in detail in order to evaluate our 2 year/5 year strategy for different areas of the architecture. The Archimate work then helps us to evaluate options for each Brick in relation to other Bricks, rather than in isolation. Through this we aim to avoid the somewhat silo’d ways of work that we have found can occur rather inevitably when we have separate Applications and Infrastructure teams.
To put this piece of Enterprise Architecture work in context, see the diagram below,
Layers in the architecture stack
This diagram illustrates the positioning of the Technical Architecture Virtual Team’s work in relation to other Enterprise Architecture activities that I’ve written about elsewhere in this blog. It is also to show that all our work is done within the context of the organisation’s strategy and an understanding of the business architecture that IT Services needs to support at the University.
