Nikki Rogers' blog describing EA activity at the University of Bristol

Archimate

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.

Mobile Strategy Update

A couple of months ago I blogged about our Mobile Strategy development here at the University  http://enterprisearchitect.blogs.ilrt.org/2011/11/18/our-mobile-strategy-at-bristol/. Since then, several conversations have taken place with the CMS project, the Student Portal service, and with the TEL advisors network, with a view to planning our next steps in line with both systems architecture plans and the new e-learning strategy in the coming months.

MyMobileBristol (MMB) is a pilot service – part of an iterative, tactical approach we’ve taken so far to exploring the role of University-provided access to information, tailored to a range of mobile devices (often devices that are personally owned by students – smartphones, tablets and so on).  Behind MMB, there is at the middleware layer a Semantic Web based data aggregation service, developed by our R&D group (ILRT). This service successfully aggregates data in a very flexible and extensible way, integrating externally hosted data (such as Bristol City Council “Next Bus” transport info) as well as internal data (such as newsfeeds about University events or service status updates). It exposes the data it holds to consumer services via a RESTful interface meaning that this data becomes highly reusable, whether by smartphone apps, the Mobile Web or even the Student Portal. Bringing this content to the latter is now a priority.  The Student portal concept is naturally correlated to the goals of MMB in that it is based on the principle of collecting together functionality and information that students need in a one stop location. It also permits personalization – for example personalized student timetables. Not surprisingly, these are the next big “want” from the student mobile user community, according to surveys and user engagement studies conducted by the MMB project last year.

Continuing dialogue is taking place across the organization, facilitated by my Enterprise Architect role. With the CMS project we have agreed that the Mobile Web as far as the University Web is concerned should be underpinned by using responsive design as far as we can (http://coding.smashingmagazine.com/2011/01/12/guidelines-for-responsive-web-design/) .

I also met with the SITS (Student record system software) suppliers, Tribal, this week to find out whether or not they are putting thought into how students may want to access course or fees and fines information using a range of mobile devices. We had a useful discussion about how we can collaborate in this area.

The more we can integrate our mobile solution across a range of applications and scenarios, the better. For example we need to link the MMB solution easily to the recently acquired Blackboard Mobile Learn application and also to Library resources.  Conversations are still to take place with the UG and PG Customer Relationship Management projects (to discuss the mobile experience in relation to Hobson’s  software used for CRM at Bristol).

So what are the next steps for mobile provision, which has so far been focused on the student experience at Bristol, for obvious strategic reasons? Well, prioritisation is the key. There are lots of things we could do next based on our assumptions about student needs or our desire to focus on institutional strategy or even our excitement about breaking technologies such as NFC (Near Field Communication)! But we want to get next steps as “right” as possible, given that managing, and hopefully fully meeting, student expectations, as we move from pilot to service will be essential. A really useful discussion tool is our student lifecycle diagram with a mobile information view filled in (see image). This gives a way to talk about precisely which strategies are the most key – impressing students during freshers week with funky campus orientation games using mobile device GPS features? or giving students better timetabling information and reminders about assignment deadlines? Or what?

Mobile Solutions considered in relation to the Student Lifecycle

Mobile Solutions considered in relation to the Student Lifecycle

Key

This week I presented the student lifecycle view of options and discussed potential next steps in the area of mobile support with TELAN (Technology Enhanced Learning Advisers Network), previously eLAN. This approach to discussing priorities went down very well with the group. There are some interesting developments taking place in e-learning. Professor Nick Lieven, PVC (Education), has tasked the group with a mission to develop a new e-learning vision and strategy for the University by Easter 2012. The group would like me to convene a focus meeting with them in March to look in depth at what the Mobile Business Case should prioritise, together with a specially invited group of student representatives. Meanwhile the Student Portal service will be looking to upgrade to the latest version of uPortal and will conduct more user analysis, increasing our understanding of student requirements. We will also have the opportunity to analyse uMobile (from uPortal) to see how easily this new platform will help us to support the student mobile environment.

 

Our Mobile Strategy at Bristol

I attended the very enjoyable UCISA Conference in Manchester this week and gave a presentation on how we are focussing on the student experience with our mobile strategy currently. Incidentally, the rumour going round was that Lady gaga was staying at the same hotel as the conference – I think I went up in the “cool” stakes accordingly as far as my kids are concerned!

In my presentation I talked through how we had started tactically with JISC funded projects to drive our pilot service for students – see http://m.bristol.ac.uk/ for example and feel free to try it out on your phone’s browser. Following lots of user feedback and some requirements-gathering workshops run by our Usability consultant, we then began to create a Mobile Strategy using an Enterprise Architecture approach. This involved defining principles to underpin our strategy, working on our information model, developing our vision of where we are now and where we want to get to and devising a roadmap to get us there. This is encapsulated in a business case for the senior decision-making body to evaluate and approve, watch this space!

Thank you to those who gave me useful feedback and discussed their own related work (for example a similar initiative at St Andrews University) and this blog post by John Townsend: http://jwt23.wordpress.com/2011/11/18/ucisa-cisg-day-two/

Conference tweetsI found other presentations on the Student Experience very useful,  for example a thought provoking presentation by Paul Taylor at the University of Warwick, who described the notion of the Student as a collaborator as opposed to a consumer or a learner, and how physical and online spaces can be created without layouts that dictate a sense of hierarchy or constraint in terms of how learning may take place. Very interesting thoughts on how the design of the physical and online environments can affect opportunities for co-creation in HE.

 

 

The pleasures of having an intern come to stay!

Last week Sara Price “shadowed” me as I went about my normal business, going to various meetings and processing information, sometimes producing diagrammatic models to help build up pictures of our systems, processes and strategies and their interrelationships… Sara blogged about her experience here: Sara’s blog post.

In fact Sara quickly got up to speed with the Archimate modelling language and by the end of the week gave me a neat appraisal of how Archimate compares with Triaster process mapping (undertaken extensively by our team of Business Analysts here at Bristol).  She said she thought that Triaster process maps are an excellent entry point to understanding complex business processes, and, as a linguist (Sara is studying for an MA in English Literature at Exeter University) they were intuitive and helpful. She said she thought that Archimate modelling on the other hand gets further in to the nuts and bolts of information modelling and that moving from Triaster models to Archimate models forces one to become very precise at a number of levels (ranging from specifying who exactly interacts with a process, down to the tool and underlying systems that are used). All very interesting stuff – thank you Sara and good luck with your dissertation!

Post card from Sara

Post card from Sara