Category Archives: IT 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:

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

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

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.

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:

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

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!

Enterprise Architecture Approach in an HE Institution: 10 Practical Steps

What’s particular about doing EA in a research-intensive HE Institution like the University of Bristol?

For one thing the HE sector has some interesting dichotomies to grapple with such as the dual activities of a University like Bristol of both research and education. In a sense we are two businesses: the business of conducting research and the business of educating students, however these two activities do overlap (the researchers are often also the educators and some of the students we educate may well go on to become researchers). This has implications for our identity management and business intelligence strategies.

Another dichotomy is at the sector level at which Universities both compete and at the same time collaborate with each other. This means that we want to share considerable information about our activities (e.g. we partner up with other Universities in bids for research grants and then share research data with one another), but we may keep other information private, such as our research strategy, our IT strategy, or our student recruitment strategy and so on. Because of the nature of collaboration in our sector (plus the need to provide regular reporting to the government), some of the onus in IT terms is on data standards for interoperability and on secure, online collaboration tools to support researchers who may be geographically separated but who need to conduct research collaboratively.

There are many other complex aspects to doing EA in a University setting of course, and with a tightening of budgets and a change in the funding structure in recent years (students are now paying large sums of money for their University education) there is great pressure to rationalise IT architectures and IT support within an institution, whilst at the same time providing enough flexibility to cope with changing demands for information from the government (e.g. the REF, the KIS) and to future proof ourselves to cater for next generation research and education.

The University of Bristol is more than 100 years old and it has developed over that time with devolved budgets and much autonomy at faculty or department level. Support services at Bristol were reviewed a few years ago and a mission to centralise support, including IT, was launched. From an IT perspective it has felt rather like we have undergone a merger in an attempt to bring several, disparate organisations, all conducting their research and teaching in quite different ways into a single, harmonised organisation. So where does one start with EA in this situation?

Map the existing (“As Is”) University’s Systems Applications Architecture to the Business Architecture: Get the 1000 feet view – with EA we are going to think global even if we act local. Lifecycle diagrams (I’ve blogged about these elsewhere) are useful (an example here) in getting an initial overview of the systems architecture.
Assess the how well the Applications Systems architecture “suits” the University’s Requirements Discover what are the University’s core IT systems that underpin its core processes. Do we have resilience in IT terms for supporting those core processes (note that Universities have a sense of an academic calendar, so some IT Systems are critical at certain times of the year, for example when making offers of places to students or timetabling their exams, or in some cases every few years for example in the critical period leading up to a REF submission). Do we understand the University’s required operating model and do the IT Systems we have support this? For example, is it part of the University’s strategy to offer highly customised or even personalised services for students or to offer standardised services across the board? If we analyse different areas to interpret the University’s intended operating model for each then this should show where cost savings could be made – unifying IT solutions is often cheaper, however it is essential to also understand where a diversity of technical solutions must be preserved for strategic reasons. For example, whilst it might make sense to have a unified solution for student administration, there could be good reason to allow for several different student assessment tools – because assessment might need to be carried out differently for Drama students than for Chemistry students, say. In assessing how fit for purpose the applications architecture is, there is also the significant area of information architecture which should also be reviewed – something we have only partially taken on so far at Bristol.
Assess the Health of the University’s Data Architecture: if data is the life blood of the organisation then how do you measure how healthy your data architecture is? We have developed an Interface Catalogue to help understand our current data integration architecture more transparently and therefore how to improve it. In tandem we are developing an online Enterprise Data Dictionary in an attempt to centralise and maintain agreed data definitions across the organisation. We are working towards a data-centric SOA architecture in the longer term.
Document Infrastructure Architecture encapsulated as a set of Services on which the Applications architecture depends – network, storage and servers. This can be shown as a layer of abstraction without worrying initially about the live, rapidly changing environment where we have deployed virtualised server solutions for example. I have documented recently about why we are doing this at Bristol – to support the analysis and the design of future improved architectures. This is the work of our Technical Architecture Virtual Team currently.
Agree the level of IT innovation the University wants This is a strategic discussion to be had with senior management. Gartner Hype Cycles can be a useful way to initiate dialogue on this area as Gartner release hype cycles not only specific to the HE sector but also in relation to particular technologies. A good question is what does the technology hype cycle look like for our University? For example, will we be early or late adopters of 3D Printing, what is our strategy for MOOCs and how advanced is our Big Data strategy? Deciding where we are on new technologies is a key aspect to planning – will we need to be supporting 3D printers in every office around the University in five years time for example? And in which case what is the plan for that and what will it cost? The appetite for embracing newer technologies might vary in terms of existing skillsets and levels of resource in the IT Services department. It will also be affected by whether senior level management view IT as simply a functional thing or whether senior management are interested in what cutting edge technology can do for the University – how it could enable differentiation in an increasingly competitive sector. Our technical architecture virtual team is currently thinking about IT “horizon scanning” and documenting our thoughts using a “bricks” approach. We plan to develop the target architecture plan by examining our 2 year/5 year plans for each architectural brick, prioritising them and costing them so that we can determine a sensible roadmap for change using an holistic view of the IT architecture. We will then propose the roadmap to senior management, and aim to improve it continuously over time. Within a research intensive institution like Bristol, developing innovative IT solutions can also be part of research proposals. Similarly, the level of time that IT Services spends collaborating with the University’s research community like this should be agreed in principle with senior management at the institution.
Develop the blueprint for SOA maturity and discover opportunities to partner up; Developing our University’s SOA (Service Oriented Architecture) blueprint is something we will be doing this year with the help of a product-agnostic consultant. Inputs to this process come from 1., 2. and 3. above. We will be keen to collaborate with other Universities at a similar level of SOA maturity in future and to look for opportunities for shared services going forward – with the goal of creating efficiencies. A well aligned business architecture and a flexible data architecture across institutions will be needed to cope with this sort of endeavour, and this is no small “ask”. The UCISA EA group has plans to develop our opportunities for SOA at the sector level – the spirit of collaboration in the HE sector reaches far, even in to the realm of IT Support services!; there are many of us undertaking Enterprise Architecture initiatives in our institutions and we are keen to continue to meet, share and learn.
Develop the target (“To Be”) Technical Architecture for the University. The abstraction of required infrastructure services in 4. plus the SOA blueprint in 6 should help indicate the required To Be architecture, when appraised within the appetite-for-innovation context of 5. For example, we have several server virtualisation solutions at Bristol which we could rationalise, we have database vendor diversity which we would like to reduce without damaging corporate services and we have diverse CMS solutions and we should be initiating end of life plans for the older, legacy ones. We also want to explore continued opportunities for Cloud solutions at the different architectural layers. We have moved email and calendaring into the cloud without too much difficulty as this was a fairly discrete part of the technical architecture to deal with. However other services have more complex interactions with each other currently and will require increased SOA maturity so that we can become agile enough to move services into the Cloud as and when we see fit. I consider the “to be” architecture to to be the reference architecture, with particular solution architectures developed to fulfill it.
Encourage Senior Level Management to Engage fully with the concept of Total Cost of Ownership (TCO) Senior level management need to fully understand what this is and to be cognisant of the fact that when they approve a third party system the initial purchase is probably only the tip of the iceberg in terms of what the costs of supporting the product, upgrading it and most likely purchasing extension modules for it over time will be. For example, we are currently developing our roadmap for the launch of a second data centre and questions such as whether our products can support active-active are coming to the fore. If they are not able to then we may have to build solutions to compensate and this could add a cost to the data centre solution – a cost that we might have predicted when we first purchased the products in question. Other questions we might ask of product is whether it’s backed by only one database option and does IT services currently support that? Does the product come with a suitable web services api or will we have to augment it at our own cost? There are many such questions and it is worth looking at “non standard” products as incurring a support debt – a higher TCO – and making this transparent to senior management up front. Otherwise IT Services could find itself struggling to cope with support demands for which no budget was specifically allocated, whilst at the same time the IT architecture becomes harder to mature.
Develop the IT Architecture Roadmap using all of the above. IT architecture should be a key plank of the IT strategy and the strategy should indicate what the vision of the IT plan is – the way to get from A (our current IT architecture state) to B (the future, desired state) being via a roadmap. Articulating principles (e.g. describing whether IT Services is mainly committed to building in-house solutions versus procuring third party solutions) is a key aspect of articulating the overall vision. It could be that we’re looking to create benefits such as cost reduction and so the vision will help describe where, say, moving to cloud services will reduce spending. The roadmap will likely indicate timings, dependencies and key milestones. Use of Archimate can be handy to present, visually, future architecture states along the roadmap. The 1 or 2 year projections may be clearer and more specific; longer term projections may be more generalised and allow for flexibility as the University’s strategy – as well as technology – will likely change in that time.
Ensure the IT Architecture Roadmap is communicated and Service Development and Delivery Managed in Sufficiently devolved way: We are using ITIL as a framework in this respect at Bristol. Clearly there’s no point creating a roadmap if it isn’t to be fully communicated and all areas of IT Services committed to supporting it. This may mean a fresh commitment to documentation and formal processes regarding compliance with agreed IT standards and target architectural designs. Other stakeholders around the University will also need to understand the roadmap and its implications where relevant to them. The overall plan needs to be understood by senior level decision making bodies (at our University we have the Systems and Process Investment Board) such that they endorse it and accept that diverging from the blueprint could incur ‘IT debt’ as discussed above.