Monthly Archives: April 2014

Aligning the Infrastructure Architecture with the Systems Application Architecture

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):

techarchiVTdiaIt 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

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.

Spaghetti Grows in System Architectures – not an April Fools’ Day joke

A replay on breakfast TV this morning of the well known Panarama hoax (1st April 1957) reminded me of the mission we’re on at Bristol to “turn spaghetti into lasagne”. This mission is number 7 on the JISC 10 pointer list for improving organisational efficiency: spaghetti refers to the proliferation of point-to-point (tightly coupled) integrations between our University’s many IT Systems and lasagne refers to the nicely layered systems and data architecture we’d like to achieve (see elsewhere in this blog).

However, transforming our data architecture overnight is not achievable, instead we’ve developed a roadmap spanning several years in which reform of our data architecture fits into the wider contexts of both Master Data Management and Service Oriented Architecture.

In November last year our senior project approval group (now known as the Systems and Process Investment Board) agreed to resource a one year Master Data Integration Project. We will return to the same board early in 2015 with a follow on business case, but this year’s project is concerned with delivering the following foundation work.

  • The establishment of Master Data governance and process at the University (the creation of a Master Data Governance Board and the appointment of Data Managers and Data Stewards as part of existing roles throughout the University – responsible for data quality in their domains and for following newly defined Change of Data processes),
  • Completion of documentation of all the spaghetti (aka the integrations between our IT systems) in our Interface Catalogue, and also the documentation of our Master Data Entities (and their attributes and relationships) in an online Enterprise Data Dictionary (developed in-house),
  • Development of a SOA blueprint for the University, including our target data architecture. This with the help of a SOA consultant and to inform the follow on business case for SOA at Bristol, which we hope the University will fund from 2015.

We are undertaking this work with the following resources: Enterprise Architect (me) at 0.3FTE for a year, a Business Analyst (trained in Enterprise and Solutions Architecture) at 0.5FTE, a Project Manager at 0.3FTE, IT development time (both for developing the Enterprise Data Dictionary and for helping to populate the Interface Catalogue with information) and approximately £60K of consultancy.

We had some very useful consultancy earlier this year from Intelligent Business Strategies: several insightful conversations with MD, Mike Ferguson, and a week with Henrik Soerensen. From this we were able to draw up a Master Data Governance structure tailored to our organisation, which we are now trialling. Master Data Governance Structure v3
This work also helped us to consider key issues around governance processes and how to capture key information – such as including business rules around data – in the online data dictionary.
Later this year we will be working for an extended period with an independent SOA consultant based in the South West, Ben Wilcock of SOA growers. We have already worked with Ben in small amounts this year and I am very much looking forward to collaborating with him further to develop our target data architecture (most likely a set of master data services, supporting basic CRUD operations) within the context of a SOA blueprint for our enterprise architecture.