Category Archives: Student and Researcher Lifecycle Diagrams

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?

  1. 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 gloStudent Lifecycle view of IT Applicationsbal 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.
  2. 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  anOperating Models adapted from "Enterprise Architecture As Strategy"d 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.

Mobile Strategy Update

A couple of months ago I blogged about our Mobile Strategy development here at the University  https://enterprisearchitect.blogs.bristol.ac.uk/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.

 

Why is a lifecycle diagram handy?

Inspired by some work the ITANA group have been doing in the USA (https://spaces.internet2.edu/display/itana/Lifecycle+Management+and+Analysis) I’ve been developing two main lifecycle diagrams here at the University of Bristol. These are proving invaluable in discussions with a very wide range of stakeholders across the institution – both within and outside of IT Services.

We are developing our understanding of both the Research and Student lifecycles currently, and with each we are considering the administrative/management “pipeline” that runs in parallel to those lifecycles – on the same diagram (see below).  As regards the latter, these are processes in support of the key activities typically undertaken as part of the “cradle to grave” continuum for students and researchers.  It is proving very useful to consider both the relationship and the difference between these two perspectives – otherwise it is all too easy to neglect to consider what the Student, say, is experiencing in relation to the IT systems they need to interact with at the University, and instead to become preoccupied with creating administrative efficiencies and ensuring that we manipulate Student data according to our own reporting, management and business intelligence agendas.

Student Lifecycle Summary Diagram

Things get interesting once we start to fill out different versions of these lifecycle diagrams, showing information in the central blue area of the diagram. For example, in our Enterprise Continuum we hold diagrams that show all the systems that are interacted with along the lifecycles, colour coded according to diversity or uniformity of use across the institution. This depiction has sparked striking reactions from a range of personnel with comments such as “I never realised that students interact with so many systems”, “Why haven’t we had diagrams like this before now?” and “Can we use the systems view to analyse what impact an increase of student numbers would have on the performance of our systems?”.

Things we want to do next include showing the unit costs of systems as best we can, showing the business value that systems contribute and projects currently running that target parts of the student or researcher lifecycles. From this we hope to get a clearer, holistic picture of whether we are making investments in a truly strategic way and if not how we would get closer to that situation.

Researcher Lifecyle Summary Diagram