Category Archives: What is EA?

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.

Looking back on the first year of my EA role at Bristol

Presentation to the JISC Transformations Programme

A couple of weeks ago I presented some thoughts on what I’ve learned through doing Enterprise Architecture in my new role at the University of Bristol this last year. The event was the JISC “Doing Enterprise Architecture workshop” and the slides to my presentation can be found here: Slide Presentation on The First Year of EA at Bristol. Nikki presenting at the JISC EA workshop 2012

The common question: How did we get started on EA at the University?

Several people have asked me how we got the Enterprise Architecture post created here at Bristol – how did we convince senior management that it was needed and that they should invest funds towards formal adoption of the EA approach? I suppose the lead up to this happening at the University goes back nearly a decade, when several initiatives started to come together, including formal adoption of the Prince2 methodology for managing projects, formal agreement on a clearly defined business case process route (supported with expertise from a growing team of in-house business analysts) and then the creation of a senior management governance group, to evaluate whether to approve business cases or not. The latter is called the Portfolio Executive, a more recent and certainly vital piece of the governance landscape at Bristol. Given the financial pressures on the HE sector at large and the increased competitive focus of our institution, the appetite for adopting standard approaches – proven elsewhere to help create efficiencies and achieve strategic success – has grown significantly. In the last few years Bristol has undertaken a large programme of work called Support Services Review which has helped the University to evaluate its strengths and weaknesses across support functions including IT Services. You can read more about this together with details of our experience participating in the JISC EA Foundation Programme in Luke Taylor’s, 2009 blog entries. Part of the review resulted in the creation of a new Enterprise Architect role within IT Services.

So, essentially, the time was ripe for making the case that Enterprise Architecture is needed to help increase the organisation’s ICT maturity, to avoid money wastage where there is investment in IT systems and to improve the likelihood that the organisation uses its IT capability effectively and to increase its competitive advantage. I would emphasise to others looking to establish EA roles that it is of great value to point out where things have gone wrong in your institution to date and how using an EA approach could have ensured they didn’t. For example, if your problems have included difficulties in retaining IT developers, that’s probably not an EA issue. However if, for example, your problems include failed/poor IT projects due to a lack of joined up thinking across the organisation, or over-expenditure as a result of a lack of precision in defining the roadmap from the “as is” state to the “to be” then you can describe how EA could have helped, and so on. One of the things I started collating early on was “lessons learned” from conversations with a wide range of people. If noone owns the EA problem specifically then it may be that the EA approach is not governed or conducted successfully within an organisation.

We now find ourselves at the end of year one of my new role as Bristol’s EA. We’ve made some good EA progress already (more on that in a minute) and are now ready to define and propose general adoption of our tailored EA methodology. Whereas one might find whole teams of architects in industry sectors here we have just one post, so it is essential at this point to integrate how EA operates in a standardised way alongside other frameworks and standards that we have adapted for use at Bristol, such as ITIL (adopted throughout IT Services), Prince2 for project management (adopted by our Strategic Projects Office), and a standard IT project development methodology (for our now centralised IT developer teams).

Some key things I tackled in Year One

I approached the first year by trying to balance my efforts across strategic activity (engaging senior management, understanding and mapping strategic agendas across Education and Research and linking them to our ICT strategy) and tactical activity (applying EA to specific University projects). It takes longer than you might first imagine to understand how a large, complex organisation like the University of Bristol functions, both strategically and in terms of its business processes and IT systems.

Strategic Successes

I undertook an unofficial tour of the University, ensuring that I met with the director and senior team of our Research, Enterprise and Development department, engaged with key committees and the senior personnel on the Education side, and also met with senior people not in IT Services, but very closely related, for example the Head of our Strategic Projects Office. This sort of senior engagement is only possible (given how busy people are) either if the EA is in a very senior position themselves, or (as in my case) the organisation has endorsed EA at a senior level, and the director of IT, say, opens doors for you. The engagement is not one-off, it is ongoing.

My mission was to gain trust across the organisation and to show why and how EA activity is to help a two-way dialogue between IT Services and various parts of the organisation. Sometimes the discussions stimulate more than an understanding of EA and lead on to realisations that change may be necessary, perhaps to cause orthogonal business processes to segue at key points, or to solve gaps in existing processes, for example. On some occasions there has been only a short space of time to convey complex ideas to people. I have found that non IT people who are nevertheless highly intelligent(!) engage very well with reasonably complex ideas that are introduced simply, for example through lifecycle diagrams or the simple ICT Maturity graph below. I was extremely pleased when I was able recently to describe Enterprise Architecture to our Portfolio Executive in just 10 minutes. The 10 minute discussion that then ensued resulted in me being invited back to run a two hour workshop with the same group so that they may explore in depth how EA may benefit the strategic decision making process. I look forward to blogging more about that at some point.

Tactical Successes

It has not been my goal to document every system and every process with Archimate models. That would be impossible time-wise, and would create a repository of resources that would (at this stage in our use of EA) very quickly go out of date. However, applying EA to specific projects has been very helpful firstly in helping me learn the Archimate language (see other posts in this blog on this), but also in helping us to understand the advantage of applying EA to specific areas so as to build up a picture of more general and cross-cutting concerns.

It also helps to justify the role of EA by offering examples of practical achievements. For example, on a project that launched a new online tool for departments to use in curriculum design I was able to point out via Archimate models that in the “to be” picture there was ambiguity about who was performing certain business tasks (according to the business process layers) and a technical problem regarding the reconciliation of course codes generated by the tool when uploading changed course information to SITS (our student records system). The separation of layers in Archimate models really helps people to separate out concerns and issues when discussing problems on projects. It helps avoid the possibility that the IT department blames the business analysts for project failures or vice versa (or that they blame the end-users for not using the new service correctly!) because the combined view of people, business processes and systems and infrastructure, helps pinpoint the nature of any problems in planned new service delivery.

My favourite top 5 success stories so far:

Using Lifecycle diagrams to help decision makers think about the dichotomy regarding how we plan to make our administrative systems more cost-effective or fully-functioning versus the impact, ultimately, on user experience (from a holistic – cradle-to-grave – perspective). See elsewhere in this blog for lifecycles (or the link to my presentation at the JISC workshop).

Using a simple ICT maturity discussion diagram adapted from the excellent book “Enterprise Architecture As Strategy” to encourage non-IT seniors to think about long term IT investment and IT as an enabler for strategic business change. The JISC ICT Maturity toolkit is also helpful here.

Getting people to talk about operating models, as captured in the simple diagram below, again adapted from the Ross, Weill and Robertson EA book. Highlighting that there are four possible operating models to choose from can elucidate what are often sticking points or what tend to be circular arguments in debates about how to improve systems architectures. It took a while for the penny to drop for me as to why the operating model conversation is so fundamental, but it became clear the more I often I heard the question “what is the IT solution for this ‘mess’?”. Frequently my answer was “well, what do you want to achieve?”. For example, when asked what we should do about the overlaps and integration problems between SITS, Blackboard (our VLE) and several bespoke (and often very good) marks and assessment systems dotted around the University, part of my answer was: do you want to unify the systems you’ve got into one corporate solution that all departments are asked to use from now on (simplifying matters and saving IT support costs), or is it the case that some departments have such discipline-specific needs around marks and assessments and their products are so strong that to remove them would cause reputational damage/failure to deliver on strategic goals? Do you want a coordinated solution that integrates all marks and assessment results at the summary level and leaves some departments to manage the process leading up to summary marks using their chosen systems, for example?

Having this sort of conversation – and fundamental decisions made and then governed by the right people structures – in a sense protects IT Services. Because if a decision has been taken to support a central, corporate system for some business function and to phase out local implementations, then the next time a department requests support from IT Services, IT Services knows they can say “no, sorry, we have been told to dedicate support to the central system not local implementations, person X has been talking to you about the migration plan”. Without a clear decision on whether the business operating model for some area will be diverse, unified, coordinated or replicated, then IT Services cannot be clear about where it should invest its resource, ie whether it should be investing time in data integration, or supporting many different systems (and probably a range of developer skills sets), or migrating legacy systems to centralised solutions, therefore investing in core developer skills sets and so on.

Helping to establish a common language. A lot of the EA role is about communication, and I think that good communication is facilitated by the use of precise language. By speaking with precise terminology personally it has been encouraging to see others connect with that terminology and reuse it themselves. Now when I talk with the business analysts for example, we all clarify whether we’re talking about the “as is” or the “to be” when looking at their process maps. When helping to develop business cases for new projects we clarify with senior management whether we’re developing a strategic or tactical project. Elsewhere, in discussions I ask do you want a solution that caters for diversity or that supports a unified business process or some variation (i.e. the operating model discussion).

Resolving Boundary Disputes. These are where projects, for example, overlap in their goals, potentially resulting in a variety of problems such as confused business processes (multiple systems for the same task), inconsistent data (data in certain systems not updated at the same rate as in others), inefficient spending (buying and supporting more than one system with very similar functionality) or strategic disadvantage (such as surfacing several Web views of the same key University information with unintentionally diverse branding, ultimately offering a confusing/poor user experience across sites). I’ve tended to run workshops to help resolve boundary disputes. The EA role here is one of facilitation – helping stakeholders to see their position in relation to holistic (i.e. enterprise level) goals, helping them to understand the strategic implications as well as the technical impact of options and to come to a joint consensus where possible. Sometimes a consensus is not possible and on these occasions decisions most likely have to pushed upwards for resolution at the appropriate senior level. In my experience so far, EA is as much about communication and understanding strategy, governance structures and processes within the organisation as it is about technology.

All in all a very enjoyable first year. The intern who resided with me in the early part of the first year rather aptly produced this picture of her impression of how hard a job being an EA can be in terms of balancing the range of activities that need to be undertaken:
Over time I hope to paint a more elegant picture of the balancing act, I wonder if my yoga practice can help me here!:

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

Welcome!

Hello, I’m Nikki Rogers, Bristol’s Enterprise Architect, and this is the blog I maintain to share information about our EA activity at the University of Bristol.

If you wish to know about EA in the wider setting of UK Higher Education then please take a look at the JISC Infonet introductory pages on this topic: http://www.jiscinfonet.ac.uk/flexible-service-delivery/ea.

And if you’re wondering about what I do, here are some indications ….

The EA can help these Towers of Babel to communicate - and thus align strategy

Modelling with Archimate - I currently use the Archi tool for this.

More to follow!

Models and related documentation are held in the University’s Enterprise Continuum, which is growing over time, currently at https://wikis.bris.ac.uk/display/EntContinuum/Home#.