Category Archives: Technical Architecture

Looking Back on Year 4

This post is part of a fond farewell to the University of Bristol as I have now finished a very enjoyable 4 years as Enterprise Architect there and I have just moved on to the role of Senior Enterprise Architect at the University down the road – UWE! UWE are building quite a significant EA capability as from this year, recruiting 3 EA’s in one go, led by an Assistant Director of IT dedicated wholly to Strategy and Enterprise Architecture. It was an opportunity I couldn’t turn down, but it was a difficult decision to leave the University of Bristol and I will really miss my fantastic colleagues there. IT Services at Bristol has recently recruited an excellent new CIO, Darrell Sturley, and I think he will help improve all aspects of IT considerably over the next few years. I will watch with interest!

So, back to the real subject matter of this final post on my blog: what did we achieve through Enterprise Architecture in my fourth year in the role of Bristol’s EA? The two key achievements of this year were the successful launch of Master Data Governance at the University and the beginnings of a robust Technical Design Authority capability from within IT Services. I’ve blogged quite a lot about Master Data Governance so I will focus here on the major aspects I put effort into to enable governance of our IT Architecture – through a Technical Design Authority.

Technical Design Authority – how?

To establish a Design Authority capability I focussed less on ‘who’ should be ‘the’ authority figure, saying yea or nay to all proposed IT implementations and standards, and instead on how such a design authority should behave at the University. Or, put another way, I believe the tools and processes are as important as the roles and governance structure put in place for the TDA. I designed a process (including a form for people to complete) through which all IT Change Proposals can be submitted – big or small, and whether originating from within IT Services or from elsewhere (for example through the University’s business case approval process). But I was particularly concerned with the appraisal process being based not on educated guesses, personal views, gut feelings, or even how well presented a proposal might be, but instead on a formal evaluation of the proposal against three things: 1. clearly specified IT Architecture Principles, 2. an understanding of all Architectural Dependencies, and 3. agreed Target Architectures.

For this to work, documentation is needed. Over the year we created the following resources to use in the TDA process.

1. IT Architecture Principles

I was given a Technical Architecture team to work with in the last year of my role and this great group of technical experts and I came up with a set of draft principles that we felt were particularly pertinent to the University at this time:

IT Architecture Principles

 

 

 

 

 

 

 

 

These top 8 drill down into sub principles, but we wanted this small number of summary principles so as not to bamboozle people submitting IT proposals! I should say that they were linked to higher level, overarching principles published by IT Services more generally. I am a big fan of how TOGAF encourages the writing of principles, so we then articulated each principle more precisely. I’ll give one example here (further articulation of the third principle in the list above):

Architecture Principle 3

 

 

 

 

 

 

 

 

 

It is interesting to note that the implications can often result in actions that need to be taken! Implication 3. is particularly relevant to the Design Authority decision making process.

2. Architectural Dependencies

It is all too easy for, say, someone in the Server Infrastructure team or the Databases team, to come up with an architectural improvement without appreciating the knock on effect on the applications architecture. Or vice versa. For example, upgrading to the latest release of Oracle or SQL Server would seem to be a good idea, but clearly not if there are business applications which for ever reason aren’t yet compatible with it and which might stop functioning correctly. Similarly, one area of the University might think it a great idea to purchase a new Web Portal to surface content from their system on the Web without realising they are duplicating another Web view of information offered via an existing system – ultimately creating an ill-planned web experience for visitors to our website and potentially confusion all round. I have encountered many many examples of where a lack of an holistic understanding of our IT architecture has allowed for bad decision making.

To counter this we drew up Archimate diagrams of our systems architecture. The Technical Architecture team and I received excellent training from Bizzdesign back in January in order to ensure we had several experts within IT Services able to maintain this documentation centrally going forward. We mapped out our entire infrastructure (virtualised and non virtualised server environments, storage, network, backup services, databases and so on). Then we mapped our critical services to it. Initially we used the free tool Archi to analyse our architectural dependencies, here’s an example (click to enlarge):

Explaining Archimate Tool Advantage

 

 

 

 

 

 

Then, after explaining to the Senior Management Team how valuable it is to be able to understand which architectural components are interrelated to others using a fuller-featured product, we were given the funding to purchase Bizzdesign Architect licenses. I explained that with good documentation we were also able to understand more about dependencies within our architecture generally – for example here I can show that our student administration system depends on a lot of infrastructure components; we can show very simply via the diagram that if the linux virtualisation platform supporting the web farm should fail, then the web client to the system (SITS:eVision) would fail too. However, the desktop client (SITS:Vision) would be unaffected so certain users would still be able to access the system via this.

SITS archimate diagram depenences

 

 

 

 

From a design authority point of view, it is valuable to use these architecture documents to ask pertinent questions about the potential for undesirable knock on effects that might occur if a particular IT change is approved.

3. Target Architectures

We could draw out target architectures using Archimate – these are useful. But I wanted something more accessible for those not familar with that language. I follow work by ITANA and decided to go with the Architecture Bricks approach they were evaluating at the time.

I developed a template that the NIH in the US were using at the time:

Brick Template

 

 

 

 

 

 

 

 

and the Technical Architecture team and I produced bricks for 20 major architectural areas we support. Here’s an example:

Storage brick

 

 

 

I ran a session with the IT Senior Management Team where we reviewed the 20 bricks together. It revealed key issues such as the number of retirement targets we had not planned for so far, and the number of – thus far uncoordinated – plans to move to Cloud services.

From a Design Authority point of view, once they have been evaluated holistically and approved centrally, the Bricks become ‘the bible’. They describe future plans and containment/retirement targets. Therefore, for example, if a proposal is offered that attempts to build a new service on something we’ve marked as a retirement target we can have a fully informed conversation about whether to recommend against that.

In this respect, the Design Authority isn’t functioning to try and stop all IT plans that run counter to the existing plans. Instead it is about making a clear and informed response about the implications to the organisation of deviating from the well thought out IT architecture plan.

So that’s my top 3 contributions to the establishment of a Design Authority capability at the University. There are several other governance aspects of course, but as I said earlier, I felt it was key to reduce ambiguous decision-making by having a clear decision framework within which to operate first and foremost.

Thank you for taking the time to read my blog and to all the colleagues from Bristol and around the sector that I’ve had the pleasure to work with in my role… I hope to work with many of you still as I stay in the HE sector in my new role! Bye for now!

 

 

 

 

 

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.