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.

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