You are currently browsing the archives for the JISC InfoNet 10 Steps to Improving Organisational Efficiency category.

Archive for the 'JISC InfoNet 10 Steps to Improving Organisational Efficiency' Category

Core Data – an important asset in terms of efficiency, agility and strategy

Sunday, October 21st, 2012

Earlier in this project I read the JISC infoNet “10 Steps to Improving Organisational Efficiency” with interest, and considered where this project and other activities we are doing at the University of Bristol fit in with the ten steps summarised.

Step 1 contains the instruction “Review a copy of your college or university’s strategic plan”. This is indeed one of the first jobs I undertook when I started as Enterprise Architect at Bristol in 2011. I have been doing some benefits maps work since to help understand our overarching strategy better – see my blog post about this at

Step 2 recommends: “Create a basic view of the functions carried out by the institution”. There is a recommended JISC infoNet Business Classification Scheme to help with this. I am not sure we have done this step explicitly so far, although one of my early pieces of work on Lifecycles looks at IT systems from a stakeholder perspective and more recently I have been working with the Director of Planning who is using the balanced scorecard approach, so I think it would be useful for me to review how far we meet this objective with clarity.

Step 3: “Create a basic view of your IT Architecture showing the applications and services, the interfaces between them and the data transferred”. Well, it takes so few words to describe this step and yet this is a massive step for IT Services in my organisation. We have documented applications and services and are applying ITIL to good effect in terms of using a service catalogue as a central record for all IT systems offered as services within the organisation. However, the interfaces between our systems are absolutely key for us and the focus of this project. I have documented what we’re doing with our Interface Catalog in my other blog: and we’ve now started a data dictionary (a summary overview of which is offered via an Entity Relationship diagram for the data model) in relation to the data entities exchanged/manipulated at the interface level. I will blog soon on how we are agreeing on the data dictionary template as a standard and what data entities need to be documented in the data dictionary and why. This work is one of the main thrusts behind this JISC project.

Step 4: “Identify any ‘bloated’ or redundant applications that consume resource far in excess of their actual value to the organisation and plan to phase them out. In time you will look at the business processes that drive this.” This step is about looking at return on investment and although I wouldn’t say we are managing this step through a formal methodology at the moment, we are looking at benefit in terms of benefits maps and we are also developing extremely useful documentation about the costs of our services (especially in terms of developer FTE’s required to manage the systems that constitute those services or the costs of theĀ  outsourced support costs, in addition to any software licensing costs after upfront investment).

Step 5: “Use the IT architecture conclusions as a starting point for discussions involving management, teaching and administrative colleagues about architecture at enterprise level. ….. to build a roadmap of integrated process and ICT change.” This is a valuable step and at the moment this is happening through benefits work taking place with the Education, Research and Support areas of our organisation. When the three sets of benefits maps come together I think we will have an incredibly useful piece of dialogue around the priorities around IT support for strategic requirements considered holistically at the University.

Step 6: “Identify the likely lifespan and replacement cycle for existing applications.” This is happening as part of our application of the ITIL standard across IT Services.

Step 7: “Consider how a service-oriented approach (SOA) to your data layer could streamline the architecture and reduce the need for interfaces/data retyping. Plan to turn the ‘spaghetti’ into a ‘lasagne’.”. Although there are 3 steps after this one, I will stop at step 7 in this blog post because this is very much the focus of this JISC project. The documentation in our interface catalog is showing us where, say, ten different interfaces are exchanging the same student entities, in which case we could abstract out the common functionality and offer it via a single API, possibly via a Web Service. That way, should we change the structure of a student entity in our master data system, we can manage the propagation of that change through the systems that consume that data far more safely, easily and efficiently than at present. We can do this in turn for every piece of functionality that we see is highly used. We can also consider the need for realtime data updates across our systems and where we might start deploying ESB solutions in earnest. For more information about our interface catalogue please see: