1.2 A Briefing for Directors and Heads of IT Services

The first section covered the areas of institutional and technology development that Vice Chancellor and senior management in Universities need to consider for the future. It sets the scene for thinking about the transforming potential of technology to create more agile and progressive institutions capable of responding to the new global and national challenges.

In this section we argue that, in pursuing flexibility, and increasing the ability to cope with variety in systems and processes in Universities, we need new ways of thinking about information systems. The notion of a bipartite approach to information technology between academic and administrative computing needs to be explored, and dismantled in order to be able to build new homogeneous information infrastructures that can exploit the opportunities of internet technologies to create better, more efficient, more responsive institutions. Directors of IT Services need to think in terms of enterprise architecture, component and the service oriented approaches to create new infrastructure to facilitate more dynamic business processes . Widely adopted in the commercial world, the SOA approach seems to offer the best route for creating the adaptable processes needed for the future.

Even our concept of a University business process needs to be examined – often the term is used as a synonym for administrative process -we refer to our core administration systems as our “business systems”. Whether based on Enterprise Resource Planning (ERP) or stand alone MIS, Universities have viewed investment in information systems as being investment in administrative efficiency.

But the business of the Universities is education and research. Therefore, teaching, learning and research contains our most important business processes and with the same concepts of organisation, flow and of progressively adding value. This is important when we want to look at new models for providing access to higher education. We already know the impact that Internet and e-business has had on commercial organisations and on our own lives. E-business has created new business models, altering the supply chain, removing intermediatories, changing temporal aspects of business, changing consumer habits. There are the notable successes of new on-line businesses e.g. Amazon, but few established businesses have transformed to being 100% on line, and instead have become a mixture of “bricks and clicks”. In the same way, structuring University processes to take account of new internet based technologies, does not mean a transformation to a virtual university, but instead opens up new channels.

The problem is that Universities are not selling commodities. If Amazon sells a kettle it can use the same set of processes as it uses to sell a book. These processes are stock management, the product catalogue, shopping basket, merchant payment services, and dispatch. The value Amazon adds to the commodity is in the product reputation system, the tailored recommendations, the dispatch options. This is clever stuff, but not complex. There is limited process variety: only commodity variety.

Universities too have standard processes: validating a course, marketing a course, recruiting, enrolling a students, collecting the fee, claiming the funding, accrediting the learning, graduating the student. But the curriculum is too complex to be a commodity, and is characterised by huge variety: the different approaches of the academic disciplines, personalised in the delivery, varying in the assessment methods, adjusted for learning styles. This is where things get messy in the attempts to have consistent approaches to on-line learning activity or curriculum delivery through the single VLE system. The variety, the personalisation of delivery by teachers, and possible personalisation of learning by students seems to point to the need to support variety in learning technology and support systems.    

Dealing with complexity

Stepping back into the traditional understanding of University information systems, even the standardised processes already in place are not consistently stable but are constantly being challenged by changes in the HE operating environment. 

Higher education is being shaped by expansion, globalisation, innovation and the advances in technology. Universities are seen as the powerhouses that will deliver a viable economic future for the UK. The result is that Universities are increasingly encouraged, through funding regimes, to respond rapidly to the political agendas. Over the last 15 years higher education has expanded massively, but the unit funding for students has reduced, pushing the sector into high order efficiencies and increasing the pressure to diversify income streams. There are now complex relationships and partnership arrangements as colleges and Universities respond to the skills and knowledge transfer agendas – alliances with the NHS, with commercial companies and with partner colleges. The profile of the student population is changing as more part time and working students move into higher education. The expansion of UK HE overseas has provided new logistical, process and systems challenges. And globalisation increases the competition for international and, maybe, even home markets.

Within the sector, modularisation of programmes in HE has added not only flexibility, but also considerable complexity, influencing the structure of student record systems, administration and increased the overhead for both support and academic staff. Programmes are now routinely sliced and diced for different types of student. The same module may need to be delivered in different modes for full-time, part-time, students at partner organisations, students overseas, and for work based students. This has provided a bigger driver for e-Learning support systems: the use of technology to help support variety and different modes of study. E-learning is evolving from limited set of tools encapsulated within a single VLE, towards a richer toolset, encouraged by the growth of Web 2.0 services and the raised expectations of faculty and students.

Partnership arrangements and the exchange of information between partner organisations also adds to complexity (see section 2.3.2). As well as making statutory returns, Universities supply information to other organisations e.g. course details to Hot courses, UCAS and Learn direct; student and course details to the student loan company. At the moment much of this sharing relies on manual manipulation of data or even rekeying. In future, there are proposals for exchanging student transcripts and portfolios between organisations.

Where are we now?

Unfortunately, most of our systems infrastructure isn’t designed and built to deal with the new and fast evolving complexity. At the core of University systems is a set of assumptions or constraints about how courses, programmes, events and calendars are built that fit a majority model. More radical course proposals from within the University are often trimmed to fit this model, which is also constrained by the HEFCE method of funding of credit bearing courses.

Complexity arises when we try to automate processes against the majority models. There are plenty of examples of the exceptions that challenge us daily – enrolments in July, enrolment of students overseas for on-line courses; students or support staff who are also lecturers; commercial partners who deliver programmes. These would be simpler to deal with in a paper- only world; apply technology and we have problems of process sequencing, information security, and negotiating the implicit and explicit business rules that have been articulated over the years. But there isn’t an easy option to reverse back the technology because we have already built in dependent and time critical relationships e.g. the enrolled student needs a network account and module selection to obtain a timetable, access the VLE and needs to be able to pass through front door using the access control system.

 

Figure 1: Core record systems and their sub applications

The core administrative computing systems grew out from the need to demonstrate compliance, probity and accountability for government funds. They are invariably monolithic applications, student record systems (SRS), HR, finance, library systems, mainly bought in from third party suppliers. In some cases two or three products will be from the same commercial supplier. Often they're from different suppliers, each selected because they represented the best of breed for that administrative area. These systems are usually supplemented with a variety of local systems created to compensate for the deficiencies of the former. For example in the management of course lifecycle, the processes of validation, advertising and enrolment may all be covered by separate systems. 

Within third party supplied, core, applications, are workflows and structures designed from the assumed best practice at the time they were programmed and designed to meet the needs of the majority of customers. It is these workflows that often frustrate users who have to adapt their processes and fall in line with the way the system works. This is the accepted compromise in buying software rather than building it yourself. It is one the reasons that Nicholas Carr (2004) [1] claimed that third party software systems cannot give competitive advantage because everyone must use the same IT system driven processes. 

Within the monolithic systems are the sub-applications, plug in modules that use part of the common database, to provide additional functions. So the student record system may have functionality for admissions, student management, module management, assessment recording, awards and alumni. Access to these functions is only available through the interfaces provided by the supplier, usually the client software or to a web client. The result is that occasional users, e.g. academic staff who need to look up a student, have to battle with a complex client to carry out a simple task. 

The need for change

So the current picture for most Universities is of a collection of monolithic core information systems, each of which have multiple proprietary sub-applications embedded and built over their own core databases. These support the big processes: application, enrolment, paying staff etc. A tight integration between the sub-applications within a product is assumed; the ability to join the product with other third party software is often trickier, relying on supplier partnerships or bespoke customisation. And this is the case with the variety of software applications, created or bought in, which may have to import data from the core systems e.g. the alumni system.

As more of these applications are introduced into the mix a number of problems arise. Data movements become harder to track and manage. Plumbing in each application introduces new risks around security transfer of data. Each application may have it’s own user control and registration system. There is a danger of multiple application competing to pull data from the primary systems, often the student record database, leading to degradation of performance.

The degrees to which these systems integrate or interoperate will vary. Enterprise Resource Planning (ERP) systems integrate through a common data warehouse, but these usually cover only finance, HR and perhaps student records – integration services are still needed for other systems. There is still a heavy reliance on moving data in batch between systems. Although batch can still be the most efficient way, it introduces delays which will frustrate users in certain time critical processes. So If I make a payment on-line against my fees, I want an acknowledgement and a confirmation of the effect of the payment straight away. The further removed from campus the process user is, the greater the need for a timely feedback. A lack of response or discernable action leads to lack of confidence in the process.

So the case for change is that

1. to develop agility we need to be able to create or reconfigure processes quickly
2. Processes are constrained by the capabilities, inbuilt workflows and configuration choices embedded in information systems
3. Because of this, processes areas with wide variety e.g. education processes, may need a wide variety of supporting systems
4. Student support consists of a mix of standard processes and variety processes
5. With variety comes the complexity in managing, linking and automating processes
6. Automating processes is core to extending services beyond the campus and these have to be responsive
7. Complexity and volume can effect: process and system performance; responsiveness; and the ability to implement changes quickly.

We need ways to simplify and organise the University system and process environment in order to be able to support greater variety in future.

The seeds of change

Within the UK HE sector, and often supported by JISC project funding, Universities have been experimenting with new ideas around supporting students, researchers, academics and administrators, by applying technology to try to address different problem areas. On the positive side much creativity has been applied to improve the experiences of these consumers of processes. Unfortunately, the success in transferring good ideas, or even sustaining the project outcomes has been limited. What works in one place isn’t easily transferred to another because of system, technology, or configuration dependencies or the difficulty of making the adaptations to accommodate new systems.     

The Managed Learning Environment was one such idea that was taken up, reinterpreted locally and implemented with variety. Originally, itself intended for organisational and business process transformation, the MLE was interpreted as the stitching together of the SRS and the VLE, or as the VLE itself (Boys, 2002) [2]. Beyond the modules provided by the commercial suppliers there has been little exporting of method or tools for this integration, pretty much everyone has adopted their own ways of exhanging data. Interoperability standards are not widely used, although they exist. The idea of organisational transformation through the MLE has still not taken wing.

From the MLE concept, and particularly in relation to the desire to support a wide variety of learning support tools, PDP, assessment, content managements, has grown the e-framework [3]. The e-framework seeks to express the future of university processes and systems as a set of services that can be mixed and matched. From this has grown the notion of the service oriented approach as a possible solution to agility, supporting variety and to organisational change.

A number of Universities are already experimenting with SOA, sometime as an extension of the ERP systems [4] and sometimes through technology platforms such as IBMs Websphere. Some of these are technology implementations using "pure" SOA technologies and the focus is often on well contained and accessible business processes such as provisioning and student identity management, key elements of the MLE. But these experiments are showing the quick wins and improving the student experience [5].   

A useful analogy

For IT Service Directors there is a very good analogy for creating an information systems infrastructure in the way Universities built high quality communication network infrastructures. Originally focused on school computer clusters, with separate terminals in offices to access centralised mainframes, Universities had disjointed internal networks and software application “silos” e.g. SPSS is only available on the social science computer rooms. JANET access was through mini or mainframe computers.

A number of technologies and standards enabled a major change in approach: PCs, Ethernet, and HTTP, TCP/IP. From these IT departments have evolved almost ubiquitous connectivity on campus. We now have a network infrastructure that has:

1. consistent cabling through UTP and fibre cables;
2. network traffic managed by routers and switches;
3. file, print and software delivery services managed by fileserver;
4. Users access, authentication and provisioning managed by directory systems
5. security managed through firewalls, permissions, etc; 
6. applications such as email, web browsing and voice over IP.

University networks have a good conceptual model such that new services can be built onto the network infrastructure easily and the network can support a variety of technologies e.g. CCTV or door access systems. But this is not unique to universities (although they had a big hand in pioneering the technologies): standardisation has led to network technology as a commodity available to all with services that are platform independent – we can email anyone.

As a University network manager, you would not have known in 1991 that this was going to be the future. Your task would have been to simply decide how best to connect the Dean of Faculty to both the proposed student record system and to the academic server, which were on separate networks.

  

A design, a concept, an architecture?

As the plexus of teaching, learning and admin processes and systems evolves, we need to establish some order over how new capabilities are added with minimum disruption, and how changes are managed. The first issue is of design of the IS and process framework, and has the word “architecture” associated with it. The second is around control of the IS and process framework and is given the associated term “governance”. 

IT architecture

From an IT point of view, architecture has been associated with building hardware and software. The term has been used in relation to how different components are linked and interact with each other to produce something bigger. In IT infrastructure, the architecture is the framework that encompasses the networks, the IT equipment and how it connects, IT security, the IT standards and the controls.  

In software development, the architecture refers to the structure of the software e.g. the separation of data, logic and user interface and how the software components are linked. The design process uses familiar tools such as flowcharts, entity diagrams, functional specifications etc. Since the 1980s, object oriented approaches to programming have dominated design because of the efficiency with which new software can be assembled from objects, and the economies that come from their reuse.

Business architecture

The term architecture applied to business has come to mean the framework and structure of the business and encompasses areas such as the organisational structure, governance and management, strategy, operations, and business processes. There doesn’t have to be a technology dimension to the business architecture. The tools of business architecture are organisational charts, business process maps, and corporate documentation.

Service oriented architecture

SOA is the confluence of business and information systems architecture where processes are mapped out in terms of component services. From a business perspective SOA gives the prospect of building or reconfiguring processes. Any business process can be reduced to a sequence of activities or steps. With an SOA approach the steps can be rendered as discrete services. Stringing together, or “orchestrating” services in a workflow creates a new business process.

From an IT perspective SOA is the logical development of the classical software architecture into a distributed software architecture such that software components (services) can be called across a network. A consumer service passes data and parameters to the provider service which produces an output. The data sent between service is packaged up into messages.

Using internet based technologies including HTTP, XML, JAVA etc, software components can be created as web services, so that is no longer matters what language they were written in or what platform they sit on. This indifference between the service consumer and provider is what is termed “loose coupling”. SOA has become synonymous with web services, which increase the potential of location independence as they can be accessed via the world wide web. This extends the potential sharing of services between partners without needing to build point to point network routes. It also enables the use of third party web services. Particularly powerful has been the ability to use freely available web-services such as Google maps to produce mash-up of data e.g. tracking the position of railway trains. Whilst SOA does not have to include web services, web services have made it easier to build and deploy an SOA.

 

Elements of an SOA

SOA is supported by a large IT industry, rich in vendors, approaches and definitions. The purpose of this toolkit is not to dwell deeply on the technology of SOA but to suggest the adoption of the approaches of SOA. However, it might still be useful to explain very briefly the technology involved in pure SOA. 

The technology elements of a pure SOA are;

1. Messaging to encapsulate the data passed between services. SOAP (simple Object Access Protocol) formatted XML messages are used in the case of web services.
2. Enterprise service bus (ESB) –provides the messaging services that ensure that the data message is passed efficiently to the correct service. Often represented as a tube or bus the ESB can be seen as a black box that deals with message validation, priority, security, transformation
3. Workflow engine – for business process managing, it creates the workflow pattern
4. Service broker – middleware for sequencing services together based on the workflow pattern
5. Service registry – a central catalogue of published services including interface details, component definitions and locations. It tells the broker where and how to access services and how to format messages for that service
6. Service adapters – these are software modules which attach to applications to allow access to their functions using a standards based interface e.g. an SMS text message service could have a web services adapter, that enables its to be used as if being called as a web pages.
   

 

Each of these SOA elements can be unpacked into more detail through the SOA literature and in Section 4 of this booklet.

There are debates as to whether you can have an SOA without some of these elements like the Enterprise Service Bus. If there is an ESB then usually this would be a commercial product supplied by the likes of IBM. It is worth noting that there is currently a project underway by the not-for-profit foundation, ITHAKA , to build a Higher Education ESB [6].

Conceptual SOA

In the SOA industry there are lots of takes on what SOA has to be and little clarity about what exactly it is: a technology approach, a construction method, a means of business transformation or as conceptual model.  

Stepping away from the pure technology aspects, there seems to be a set of principles to SOA that have a wider appeal for business architecture. These principles are;

1. Services align closely with the steps of business processes
2. Loose coupled self-contained services give the capability to build flexible processes
3. The use of a single connector between a service and the infrastructure, simplifies application integration into the SOA thereby reducing the integration complexity
4. Flexibility derives from re-use, substitution and re-orchestration therefore business processes can be less constrained by the big technology systems
5. There is the potential to use services that exist beyond the boundaries of the organisation
6. Services that you publish can be easily used by customers and partners.

 

 

For HE these principles open the door to

• Supporting variety in e-learning tools by simplifying the integration processes
• Supporting variety in administrative processes for different student groups
• Introducing new standards based tools created elsewhere
• Using third party services such e.g. software as a service, cloud computing
• Greater potential for shared services
• Services shared with partner organisations

 

The JISC has produced a neat animation to demonstrate these concepts [7].

 

It may be useful to conceive of SOA as a layered approach with data as the lowest layer and service rendering and consumption as the highest layers. The middle layers consist of services, orchestration and business logic.

Figure 2- SOA layer model (adapted from number of sources)

Integration can take place at a number of levels. Much of our current application integration activity occurs at the data level, passing batch data between say the student record system and the VLE, or we integrate services at the point of delivery, typically, in web portals. SOA also allows for integration at the data layers, using data messaging, and integration is still common in the “last mile” through end user mash-ups, portals etc. But real flexibility comes from the creation of new composite applications for new business processes which takes place in the Business logic and services layers.

 

Which SOA?

There are three levels of SOA have been suggested by Miko Matsumura, deputy CTO of Software AG and John DaVadoss of Microsoft [8] [9].

1. Little SOA
2. Big SOA 
3. Middle-out SOA

 

Little SOA is implemented at the IT level the creation of an infrastructure is probably what IT departments should be doing technology wise, building the infrastructure as we built the networks using the latest principles of segmentation, open standards and open architecture.

Big SOA aims at business transformation, and the IT service infrastructure is only part of that transformation. Big SOA drives towards the formal methods of Enterprise Architecture as the preferred approach.

Enterprise Architecture

The Enterprise Architecture concept has grown out of John Zachman's (1987) work for IBM [10]. He anticipated the impending spread of very large, and complex Information systems extending across organisations and the need to incorporate smaller, economical and quick to deploy systems. Zachman first drew parallels between the architectural processes involved in traditional building and those of Information systems construction and design, identifying that there are different perspectives and representations in the design process which have meaning to different professions but which have to be coordinated e.g. the concept model, the construction drawings, the floor plan, the cabling and services layout etc.

Information systems and Business architecture ideas have since evolved into Enterprise Architecture which combines concepts from both areas and applies them as a strategic approach encompassing the whole organisation, its processes and systems. Like most strategy techniques it aims to move the organisation from a current to future state, describing both as part of the process. The EA framework has the concepts of a design process with different representations of the design captured through a set of tools. 

There are now a small number of JISC earlier adopter projects [11] at Liverpool John Moores University, Cardiff University and Kings College London, piloting formal approaches to Enterprise architecture using The Open Group Architecture Framework (TOGAF) [12] [13]. There are other EA approaches including;

• Atos CLEAR – Comprehensive, Landscaped, Enterprise Architecture Representation
• SAP Enterprise Architecture framework

The dilemma for Universities in using tools such as TOGAF as a starting point, is that these formal methods are heavy and challenging . The advice on EA is that it should be driven from a high level business management perspective, rather than an IS perspective and it needs a skilled enterprise architect. This raises two problems: engaging and sustaining the university senior management in a fairly lengthy and detailed process and project; and obtaining the necessary expertise in enterprise architecture. The challenge will be how to reconcile long lead times and high costs for an AE project at time of rapid change and the need to react quickly to new situations. And at the heart of this there seems to be a paradox of building agility though a long drawn out process.

Middle-Out SOA

“Middle-out” takes an incremental approach to introducing SOA, a compromise between little soa (which builds soa infrastructure onto which services can be loaded), and the enterprise level of big SOA [8]. Development effort is concentrated at creating new service process at the edges as they are required rather than seeking to restructure the core business applications. The principle of middle-out is to build the SOA functionality as it is needed, in vertical slices, through data, business logic, and services to the rendering layer where they can be consumed. Middle-out follows one of the philosophies of agile development, “model and do”, seeking to realise the business benefit of the service slice as quickly as possible (3-6 months) and to build out in iterations. A second principle may be more obviously needed for HE and that is to service enable existing central assets, databases and the legacy applications. Some HE sector suppliers are now starting to respond to this need. For example Tribal has now released a service adapter for the SITS:Vision product called StuTalk with a number of associated web services. Through this it is theoretically possible to treat the legacy system as a composite application and to draw off individual functionality and treat them, in turn, as services.

To scale the implementation still requires elements of the SOA architecture such as the ESB and other middleware components. The value in middle-out is in delivering recognisable benefits quickly but there has to be some recognition in development, that services are designed for reuse. The downside to designing for reuse is that the typical development costs can be twenty to fifty percent higher (Source: Gartner consultant David Norton).

 

Role of Governance

Governance is a term used to cover a variety of activities concerned with control and direction around the production of business process and services. As with our political governance, which works at international, national, and local levels to set laws, policies, and actions, SOA governance works at different levels as well. We understand IT governance as the means by which we connect IT strategy to corporate strategy, the decision making processes, the policies and procedures used to guide the implementation and exploitation of IT and manage risks. SOA brings additional levels of complexity because it focuses on both business processes and IT based services. The objective of SOA is to create agility, fast reconfiguration, and new end to end processes and governance encompasses SOA at the strategic, tactical and operational levels.

In our current, pre-SOA state, with those much criticised business application and process silos, we know who nominally owns a process and we rely on them to know and enact the business rules around that process. For example, the Registry may own the substantial part of the enrolment process and make decisions on who can enrol, how the fee is to be calculated, and on allocating status codes to students. In implementing SOA, some of these rules may be codified into services to enable say, on-line enrolment or to create a fee calculator. With the reuse of services, those rules may appear in a composite application for a slightly different purpose. In that respect the business rules may be applied in a way not previously considered. Similarly, services and applications may use the student status code from the student record system for say, provisioning. Were Registry to introduce new codes without communicating the change, those dependent services could fail. Therefore as SOA breaks down the business silos, SOA governance has to gear up to ensure that appropriate change controls are effected. 

Other areas that need are attention, especially if development, use or re-orchestration of services is spread across the University, is the agreement and adherence to standards of development (e.g. naming conventions, versioning, release control) on interoperability, and security models.

There is more detail on SOA governance in later sections of the toolkit. 

 

The role of the IS Director

For those involved in IS development over a number of years, there is an irresistible logic and history that has brought us to SOA. Segmentation into components, distribution, standards for being able to co-operate and connect systems, are all emergent technology ideas that converge in SOA: it was always the next logical step for IS architecture. So the idea that SOA is business driven, can seem strange from an IT perspective, especially when the concepts are foreign to non-IT colleagues. Most IS Directors or CIOs appear happy to buy into this rhetoric. But is “business driven” a phrase we truly believe and understand? Is “business driven” a attempt to take the pressure off IT, or a smart, subliminal, sales pitch from suppliers and consultants, which we condone? “IT driven, business led” seems paradoxical.

A second lingering doubt in the minds of IS Directors, may be that SOA is another industry fad that may well be doomed. In fact there are already articles and blogs predicting the death of SOA as too big a commitment in times of economic stress. Perhaps this view is not helped by the variety of SOA approaches and a commercial industry that is always looking for the next, best thing.

If you do believe the potential of an SOA approach for your University then the first challenge is how to educate others and get them to buy into the agenda [14] [15]. The truth is that this may become a personal battle for the IS Director, to fully convince yourself, then to sell the story, and show others the potential. This is a new area for IT, administration, or educational technologists and there have to be close working relationships. However you decide to champion an SOA approach, an early aim must be to challenge the conventional, acquired wisdom in the sector about the way technology is applied to business processes. Challenge the notion of best of breed applications; of simple importation of best practice; or the assumption that the market will deliver the right solution, eventually. These may be sometimes true, but especially in the areas that are uniquely yours, you may be better off constructing your own.

To convince yourself of SOA, try reading some of the case studies suggested in this toolkit, where others, some from HE describe their experiences [4] [5]. Next you need to start selling the idea at 360°, to those in the IS and IT department, to other business service heads, and to senior management and executives. An effective way to do this is to build a narrative that targets the topical business areas, and especially where changes are imminent, and to keep telling the story. Where a new system is to be introduced it is worth investigating the potential of SOA capabilities in a functional specification [15].

It would be great to find a small, constrained but visible process where you could pilot and demonstrate a SOA approach even if it is a quick win like a mash-up. Some of the identity management work and account provisioning within Universities is already using SOA ideas, although those who see the results, might not realise it. If considering a development project, then be aware that SOA and agile software development fit nicely together. Both imply close working between the process owner and a small development team, to rapid deliver functions (or services) and deliver benefit quickly .

And what would be truly brilliant would be to share your SOA successes, small, medium or large with colleagues in the sector, in the way that so much excellent work already is demonstrated.

References

[1] Carr, N.G (2004) Does IT Matter? Information Technology and the corrosion of competitive Advantage,

Harvard Business School Press, Boston, p82

[2] Boys, J (2002) Building MLEs in HE, JISC, http://www.jiscinfonet.ac.uk/Resources/external-resources/mle-joined-up-systems

[3] Olivier, B (2007) Having Your Cake and Eating It: The e-Framework’s Service-Oriented Approach to IT in Higher Education http://connect.educause.edu/Library/EDUCAUSE+Review/HavingYourCakeandEatingIt/44596

[4] SOA integrates university's ERP project http://searchsoa.techtarget.com/news/article/0,289142,sid26_gci1314263,00.html?track=sy191&asrc=RSS_RSS-21_191

[5] Developing an SOA at SUNY; Lessons learned (2007)and article on e-Learning Focus http://www.elearning.ac.uk/features/masson#ref1

[6] Technology Innovation & Development :: Enterprise Service Bus Project http://tid.ithaka.org/enterprise-service-bus-project

[7] JISC SOA animation (2007) http://www.jisc.ac.uk/whatwedo/programmes/eframework/soa/

[8] Ward-Dutton, N (2007) Little SOA vs Big SOA, http://www.it-director.com/blogs/MWD/2007/4/little_soa_vs_big_soa.html

[accessed 27/2/09]

[9] Microsoft Advocates Real-World Approach to SOA for Increased Business Value http://www.microsoft.com/presspass/features/2006/oct06/10-04SOA.mspx

[10] Zachman, J.A. (1987) A framework for Information systems architecture, IBM Systems Journal, Vol 2, No 3 p276-292

[11] Enterprise Architecture Group Pilot Study http://www.jisc.ac.uk/whatwedo/programmes/elearningcapital/enterprisearchitectures.aspx

[12] JISC Introduction to Enterprise Architecture – management briefing http://www.jisc.ac.uk/media/documents/publications/bpenterprisearchitecturev1.pdf

[13] TOGAF or not TOGAF: Extending Enterprise Architecture beyond Rational Unified Process approach http://www.ibm.com/developerworks/rational/library/jan07/temnenco/index.html

[14] A First phase SOA implementation case study http://www.opengroup.org/projects/soa-case-studies/uploads/40/11405/SOA_Agility_in_Practice.pdf

[15] The Business Case for SOA http://www.glintech.com/downloads/The%20Business%20Case%20for%20SOA%20-%20Rationalizing%20the%20Benefits%20of%20Service-Oriened%20Architecture.pdf