Funded by the: JISC Flexible Service Delivery programme.
Lead Institution: Roehampton University.
Partner Organisations: Unit4 (System Supplier), Canterbury Christ Church University, De Montfort University, University of Lincoln, and University of Nottingham.
Key Words: Enterprise Architecture (EA), cloud, getting more from existing investments and working with commercial suppliers.
Background
Aims and Objectives
Project Cumulus is about opening up access to business functions which currently are embedded in large single vendor applications and therefore do not feature as realistic business solutions for “other vendor” institutions. Cumulus explores what it takes to enable access to such business functions through the identification of the “service” which meets the particular business need and to offer it through deployment in the “cloud”, with standard interfaces to the application and its data which will make it universally available as a software solution option.
Cumulus addresses the business need to develop, manage and control an institution's curriculum data so that this data can become the single point of truth for use in other business areas such as prospectus publications, the student records system and timetabling. The project shows how this business requirement can be identified as a “software service” which will meet the business need whatever the institution's other software might be; a “service” which has a start point, an end point and a user definable workflow in between. Cumulus shows how cloud deployment creates choice in systems for business services, choice in deployment options, shows how standards can be adhered to and ultimately, offers the opportunity for simpler and more cost effective licensing options. Cumulus helps to expose and further develop the technology needed to support, and make effective, business services hosted in the cloud.
The project achieves the hosting of the UNIT4 Curriculum Management Module (ACMS) in the cloud and the development of interactions with the "outside world" using web services orchestrated by an Enterprise Service Bus (Biztalk). The project is a consortium effort; Universities of Canterbury Christ Church, De Montfort, Lincoln, Nottingham and Roehampton working with the ACMS vendor, UNIT4.
Context
Cumulus is a logical extension of previous work done as part of the JISC EA/SOA/FSD Programmes. In Project Cairo, the University of Roehampton pushed out along its own Roadmap using EA and TOGAF to reorientate from an IT driven development scenario to one driven by business needs. The EA initiative encouraged a focus on data principles, strategic vision, on adherence to data and process standards and on the clear specification of the level of change expected from projects.
Project EWES, also carried out with JISC funding and as a consortium effort lead by Roehampton, represented the first steps in exploring further along the Roadmap, looking at the value of the idea of Software as a Service using the "service" functionality of a Student Information System Module provided by UNIT4. The project explored the focus and functionality of a set of web services delivered by the supplier. Project EWES found that the "service" layer and the web services were not really very useful or effective in the context of the particular business module, not because the technology or the development was in any way inadequate, but because there was a lack of clarity about what the layer was trying to achieve.
Further down the University of Roehampton’s Shared Services Roadmap is the concept of individual modules being released from their proprietary, wrap around, vendor specific environments, being accessible through industry standard software and operating to recognised data and information standards in an unrestricted environment so that business need can more closely be matched to business “service”. Project Cumulus is the embodiment of that thinking and resulted in the project which is outlined above.
The business case
A number of HE institutions have identified an SOA approach in their strategic visions, but moving towards this has been hindered by the push from vendors of enterprise systems to adopt their full system and module portfolio. Cumulus identified curriculum management as a service and developed the hosting and the web services to allow the module to be deployed in the cloud, or on-premise within an SOA environment, forming a building block in an institutions roadmap in classic Enterprise Architecture style.
In Roehampton, Project Cumulus is the continuation of work on the University’s Shared Services Road Map which charts the University's progress from developing an Enterprise Architecture approach, through process modelling improvements to IT systems, to developing SOA to standardise integrations on web services, evaluation of a vendor "Services Layer", to developing systems built on shared services principles with external partners. The roadmap continues beyond Cumulus into the offering and use of business services using Cloud deployment and Enterprise Service Bus technology to achieve agility in IT response to business needs and independence from vendor lock-in.
The business case in Nottingham focuses around the University’s plans to implement a stand-alone curriculum management system that will provide data to its other core administrative systems within a SOA environment. Project Cumulus has contributed to advancing thinking along this stage of the University’s road map for modernising its academic student systems.
De Montfort University (DMU) has been very successful in several SOA and Cloud base projects funded by JISC. Part of DMU’s strategy is to continue to be involved in SOA projects that can be beneficial both to the University and the sector. DMU has contributed and led on JISC FSD Projects Cumulus, Step-C, and Step-F which were successfully received by the HE sector. The University hosted several workshops promoting SOA as an alternative approach to delivering Information Technology. DMU will continue its collaborative working with JISC, HEFCE and Vendors in working together to deliver efficient and effective projects that provide invaluable learning resources to the whole sector.
The University of Lincoln operates a portal website to manually store approved programme information, and does not have a curriculum database or automated programme management system. However, it has for some time recognised the limitations of such an approach and wishes to have a single source of information for programmes and modules to facilitate management of the information and processes, and to enable the same information to be available across the institution. The University of Lincoln currently has an EU invitation to tender open to work with a solution provider to supply and support it with an ‘Academic Programme Management System’, and will be considering various options presented by solution providers, including any cloud hosted solutions. The fact that an EU tender is underway limits to a certain extent what can be openly said at this stage, and the Cumulus project and Academic Programme Management System project have been intentionally managed separately, but Cumulus has reinforced the view that such systems must provide appropriate web services using appropriate standards such that they can be incorporated into an institution’s architecture without the need for multiple point-to-point interfaces, and that cloud hosting is certainly feasible with the end-user being more concerned with usability and the services a system provides than where it is served from.
There are no uncertainties to attach to Cumulus and none either to attach to the concept of Cloud deployment. It is just another option in the toolkit with far fewer complexities attached to it than to Enterprise Architecture for example. There are, however, a number of considerations to which thought should be given and these are discussed more fully in the outcomes section.
Key drivers
The increasing complexity of business requirements makes a single supplier solution to all business needs virtually impossible. Traditional forms of supplier lock-in, through the ERP approach, work against efficiency, choice and value for money. These traditional application delivery methods contribute to the monolithic environment and domain structures within HE institutions, tortuous integrations, complex support and maintenance arrangements and long lead in times for service development.
In particular, the speed with which IT responses seem to need to be developed now can make in-house deployment, never mind in-house development, problematic. Business managers are responding to an increasing number of fast moving changes and stimuli in the marketplace and to support them they expect quick response times for service delivery from IT. Cloud computing is seen as one way of achieving this. Cumulus is an exploration of whether this new form of deployment can address these issues.
An important aspect of the project which has increasingly emerged over the last few months, with other projects such as CAIRO as well, is the difficulty of engaging with the business at a system level. Increasingly, computer systems, not just spreadsheets, support more and more areas of the business. The business itself is organised into more specialist units with no single unit at an operational level having overall ownership of all aspects of the business. So much of IT is too big for the business people, for the best of reasons, and this exacerbates the problem of developing and maintaining stakeholder buy-in. Engaging people at the system level is difficult, it is too big at that level. It is altogether the wrong level of granularity to assist in successful engagement with the business stakeholders.
What Cumulus shows is that there is a way of breaking down systems into component "services" which carry out discrete business transactions and for these to be delivered in an easily supported environment which is totally transparent to the user, quick and easy to set up with ready-made, standards based integration. Cumulus is just one example of system disaggregation producing an effective business service. It should therefore indicate one way forward in development of the impact of business and the business strategy on IT provision.
Technologies used
Web Services/SOA/SOAP/REST/DotNet.
However we like to think that technology is not a boundary or a problem - it is nothing more than an issue to be dealt with and any problems with it can be solved. The concept of the cloud is not technology specific and neither are the inputs and outputs from systems hosted in this way.
The REST technology was not used in this project because the Industry Standard SOAP (Simple Object Access Protocol) is a superior method in the “fire and forget” data transfers involved in Cumulus.
Wikipedia gives the following example of the use of the “fire and forget” principle:
“As an example of how SOAP procedures can be used, a SOAP message could be sent to a web-service-enabled web site such as a real-estate price database, with the parameters needed for a search. The site would then return an XML-formatted document with the resulting data, e.g., prices, location, features. With the data being returned in a standardised machine-parseable format, it can then be integrated directly into a third-party web site or application.”
In other words the SOAP procedure has discharged its function fully and accurately by requesting the data and ensuring its safe delivery. No follow up actions are required.
Outcomes
Achievements
Development of business functionality in the cloud is not new. It is, however, relatively new in large core business information systems in HE. The headline achievement of Project Cumulus, therefore, is that it has conceived and brought about a singular and focused development and deployment methodology for a major HE business service and has done this in a spirit of cooperation with, and in the mutual interest of, several Universities and a major sector supplier.
Project Cumulus enabled a consortium of Universities to work with a major supplier (UNIT4) to provide a business solution to Curriculum Management demonstrably deployable in the cloud. The module facilitates the development and management of information on curriculum modules and programmes so that the database develops as a single source of truth, offering data for consumption in other major business systems, such as Student Records, Timetabling and Prospectus production.
For the purposes of Cumulus, the business software (Agresso Curriculum Management System, ACMS) was made accessible to users over a URL to a remote site where a single version of the ACMS Module was hosted. This single version of the software application accessed different databases for each of the participating institutions and each institution had its own separate web service functions within a single web service to achieve export and import of data from the module.
As the project evolved it was realised that the interfaces to other systems were entirely controlled by 'worksteps' contained within the internal, user-definable workflow of the ACMS system and were required only for single curriculum units as they moved through the various stages of readiness to be usable with student records systems and other dependant business processes. A modus operandi was therefore devised, in conjunction with UNIT4, that wherever required, the web services could be activated from within the worksteps themselves through the orchestration of the ESB (Biztalk). If necessary multiple calls to the web service could be made in the same workstep. To achieve this, the workstep was designed to include a call to the ESB, if required, to activate a specific web service. At the point in the workflow when a data file is required (to be passed to another application for example) the workstep functionality calls the ESB and passes it a user coded value required to define the data schema to be used and to provide 'intelligence' about why the data is being made available. In the current deployment of the system only 2 values were defined - to call the full ACMS Schema (all values on each individual curriculum unit in the module) or the full XCRI r1.0 schema which meets standards requirements for curriculum management information and, within that, for XCRI CAP prospectus based data. The ESB therefore orchestrates the extraction, calling the requisite Web Service and storing the resulting XML data file in a depository within which the ESB can control onward processing of the data.
Working with the consortium has enabled UNIT4 to gain new insights into the technical management of data and processes in a cloud-based, web services enabled environment. In their own words:
'Specifically, on Cumulus we have learnt that it is important for an application to communicate with other associated systems regarding when and why data has changed. This has been implemented through encapsulating intelligence into workflow processes so that dependent systems understand that they are being told with authority why they need to act on a change.
Downstream applications can also derive intelligence through being told why a change has happened. The event itself and the trigger for that event are equally important.
This is leading UNIT4 to reassess the balance of its development efforts around providing service tiers, event mechanisms and workflow processes. The Cumulus project has made clear that these items must be considered in conjunction with one another. It is no longer sufficient to present a web service to the outside world and expect the dependent processes to be able to understand why they have to take an action. In the Cumulus project this capability was introduced with the reason codes and custom workflow steps.'
In its initial response to this case study, the JISC indicated that other institutions had identified the need for a proper workflow solution to support the approval and review function in relation to Curriculum Management and that core administrative systems on the market, currently, did not meet this need. Project Cumulus has shown that workflows can be build flexibly to enable institutions to support these business processes in this work area, with data extracted at specific user defined opportunities, at appropriate times and with a defined status and specific, defined end points. In conjunction with the ability of the ACMS module, deployed in the cloud, to supply all the data required under XCRI r1.0, this forms a comprehensive solution for those institutions which took part in the consortium and in the project without further customisation of the product. We do not, however, attempt to speak for the requirements of other institutions which must make their own decisions and judgements.
Testing on this architecture has been completed with mixed success. The ACMS module, was hosted at the UNIT4 offices in Swansea, all 4 testing Universities accessed the module from their sites and could, through their individual logins, see only their own specific dataset. Because none of the Universities were in a position to implement a test version of the ACMS software to create the workflows, it was arranged that software tools would be used to simulate calls to the ESB (Biztalk). The Biztalk instance was also hosted in the Cloud. No on-premise instance of the ESB was deployed because of lack of time/skills on each institution site.
The tests were run separately and in conjunction using SOAPUI software to activate the ESB and make calls to the web services directly. Infopath was used to simulate the workflow call and also to simulate a call for data from another application. The tests using SOAPUI were designed to enable the selection of the relevant schema, full ACMS or XCRI r1.0 and XCRI CAP, to select the reason field which is passed to the ESB from the point of activation in the workstep. The Infopath test was designed to provide a more user friendly interface to display a subset of the data in the web service.
The Infopath test successfully demonstrated that web services could be called from the ACMS environment hosted for each of the institutions on the cloud. Tests of the data extraction using web services via SOAPUI and Infopath technology were successful. Testing of the web service for compliance with the XCRI r1.0 and XCRI CAP standards was somewhat inconclusive because institutions varied in their degree of maturity with the ACMS product implementation on their sites which impacted on the quality of data used in the testing (ACMS environments were set up using data from Unit 4’s Student Records System, or data input by Unit 4 based on a programme specification supplied by the institution). The ACMS product is highly flexible and work to date indicates that we will indeed be able to get XCRI r1.0 and XCRI CAP data back from the web service. Further work is required to confirm the initial ACMS to XCRI r1.0/XCRI CAP mapping to ensure that it is implemented correctly. This would involve reviewing the information in the ACMS user interface for data entry, relating this to where the data is actually held in the ACMS database and mapping this to XCRI r1.0/XCRI CAP.
No onward manipulation of the data was deemed to be required as the tests proved the functionality of the cloud deployment and the operability of the web services. Transformations of the data and deployment to other systems lay within the remit of the ESB’s proven functionality, not the cloud deployed ACMS module.
Benefits
Tangible
The project has produced the following deliverables:
- A standalone business module, with a specific set of business processes, deployable in the Cloud
- A set of Web Services embedded in the whole Agresso Business World product which can be called from anywhere within that product and from external sources as well. Fully tested and implementable in the live environment
- A resilient architecture which makes in-house developments easier and control of versioning simpler
- A set of Web Services which will adjust to changes in business logic, data metadata and schema in a controlled and resilient manner
- Proof in this context of the capability of the ESB to orchestrate the data management processes for a cloud based Module
- Outputs and inputs of curriculum data in an XML data format to specific, recognised UK and evolving pan-european standards
A deployment document discussing the various options for the architecture of a cloud hosted business module. This document is available at www.roehampton.ac.uk/cumulus.
Currently Project Cumulus has delivered a giant step forward in confirming the suitability of certain business functions to be made available from the Cloud.
The project has benefitted the contributing Universities who use the UNIT4 Student Product Suite despite the fact that their deployments of the ACMS module are still on-premise. The interoperability of the web services which were developed through the project for a cloud deployment have now been added to the ABW Services Layer and can be used in on-premise implementations.
For the Sector, the availability of significant business services from the cloud opens up choice. Previously significant implementation and deployment issues are reduced in impact and Universities can choose the most appropriate deployment method, whether on-premise or hosted off premise but with seamless integration through 'intelligent'data transfers.
The project has been of benefit to UNIT4. The company has offered the following statement for inclusion in the Case Study.
'By participating in the Cumulus project, UNIT4 Business Software Ltd (UNIT4) has gained knowledge and is adopting strategies in its development processes which are derived from that knowledge.
UNIT4 is confident that it can support the sector through initiatives such as RMAS because the Cumulus project has been implemented as a service oriented application in the cloud with the same principles and aspirations as the RMAS project.'
And
'Participation has helped UNIT4 ratify our Education Campus Platform strategy and confirm that the provision of multiple applications as part of a Campus Platform solution is the correct strategy for the sector.
A platform solution is one where the applications are provided via the most appropriate deployment method be that on-premise, hosted or in the cloud but working seamlessly together, and is a fundamental requirement for shared services.'
The company has a wide range of cloud based implementation/deployment options to offer potential customers and sophisticated technologies to maintain site variation information, easier upgrade options, wider support arrangements and more controllable versioning. The deployment configurations offered for ABW, the ACMS products and the BizTalk ESB along with the web services offer fully discovered implementation options.
Project Cumulus has begun to open up the path towards a different type of licencing model for HE sector business applications. Details are yet to be fully worked through but suppliers will be able to offer a greater range of licensing options from completely hands off, a fully vendor offered and supported deployment which will facilitate licensing by how much processing power is actually used by individual institutions based on, for example, usage by month, to the more traditional on-premise supported model.
A key feature of cost reduction in the area of system support will, however, be the extent to which individual institutions will require customisations to the base product. Differentiation because of customisation will make the cost calculation for support much more complex. This, in turn, reflects on and informs the issue of selection of appropriate 'software as a service'.
The success of Cumulus adds to the pressure to discover those 'services' which can be offered in a productive way through cloud deployment. Cumulus identified a specific business service and helped a supplier to bring cloud deployment of that service into reality. It was possible, within the overall common level of requirement which makes cloud deployment a realistic option, to identify and develop features, the workflow/step approach, which means that institutions can develop their own use of the module. This in effect shows that differentiation can be achieved within a common delivery framework.
Cumulus has shown also the way in which the delivery of a 'service' can be released from a whole range of restrictions and circumstances which are found in on-premise implementations. Ultimate beneficiaries will be the HE sector if the lessons learned about identifying 'general use' services can be built on, identifying the commonality of approach which underpins Shared Services and which in reality covers a very high proportion of the software 'services' used by HE institutions. The ACMS module shows how a module can be built to be standard but that the processes within the standard module can be built to reflect individual institutions work process requirements. Of vital importance in the identification and exploitation of 'software as a service' in the HE Sector is the development of data standards, in this case XCRI in its various manifestations. Without such standards the interfaces between systems both within and, more importantly, between institutions becomes problematic. This issue is discussed in more detail in the Summary and Reflections section later.
UNIT4 has expressed its appreciation for the opportunity to work closely with the Institutions on this particular business service as it has increased the contribution of 'the business' to module development. In particular the company and the sector have benefitted from the exposure to developing sector standards in curriculum information (XCRI CAP and XCRI r1.0).
The Cumulus Project explored the use of the evolving XCRI standards in relation to the ACMS module. The project set out to develop 2 schemas to satisfy these standards, one for XCRI CAP, the curriculum information structure for prospectus management and XCRI r1.0, the full curriculum information set. In the end, one schema was produced which best satisfied both requirements. It was discovered that XCRI CAP is a very flat structure which made it difficult to place the module/course within a relevant context of parent child/pre-requisites/co-requisites and so on. The XCRI r1.0 schema enabled this 'structure' to be fully represented. It was therefore agreed that the single schema would be produced from the ACMS module and that data transformations would be required within the ESB to achieve a satisfactory outcome for XCRI CAP. The XCRI r1.0 schema was the schema used for the testing of the web services for XCRI data.
Intangible
The Cumulus project is a proof of concept as well as a deliverer of a module which could realistically be used from a cloud environment. The project shows that thinking about 'services' rather than systems is productive and useful way forward and that exploitation of common services across several institutions is a real achievable end based on the acceptability of the 'service'. Thinking about 'services' removes any 'loyalty' which an institution may have with a long term supplier and delivery through the cloud removes any hardware/OS restraints which might be perceived as stoppers to the development process. Working on 'services' introduces a new level of increased granularity which better focuses both institution and vendor and provides a better focus for work on standards, which the Step-F project is showing also. Intangible benefits are the evidence that a major HE business Service can be made independent and supported by web technologies and an Enterprise Service Bus. This raises issues relating to the ongoing validity of this sort of service delivery, contests Vendor lock-in and challenges traditional implementation and support models.
Project Cumulus threw up no insurmountable or critically difficult issue and clearly suggests:
- That issues of security of access/Identity Management/integration with Active Directory or other LDAPs/multi-tenancy, can be overcome
- That Cloud computing and SOA can effectively support the operation of significant HE business systems
- Convincing evidence that this is a productive and worthwhile avenue for HE to follow
Project Cumulus has not been able to prove absolutely:
- That hosting in the cloud assists and encourages competitive pricing of business services
- That hosting in the cloud assists in product support and maintenance
However, UNIT4 strongly insists that the former is something which must be addressed, positively, from the supplier side. In support of the latter point, UNIT4 points out that support can be offered to cloud deployed software from the place where the most skills and the most appropriate software are immediately available and where on site costs are lowest – the company development office.
New skills
The project has involved the universities joining with a vendor to produce a viable outcome. It is fair to say that whilst there was a variable level of knowledge amongst the institutional personnel relating to Cloud deployment, the opportunity to work closely with a supplier on a technical solution of this nature is something which has benefitted the institutions concerned. In a similar vein, UNIT4 have gained through working with the institutions, particularly those which brought XCRI standards knowledge to the table and the exploration of the issues from the institution stakeholder point of view. Developmentally, UNIT4 used the opportunity to acquire and develop the skills required to build a competent cloud deployed module which will lead to the greater use of this methodology in the future with other business modules.
New skills were developed by working closely with the supplier in problem identification, defining processes and input/output requirements and working through problems to achieve resolution.
Key Lessons
Besides lessons learned there are some key question which have arisen through the execution of this project. Cloud computing is not a complex area. The cloud delivers 'software as a service' so the delivery of the service has to be reliable and secure. The Cumulus Consortium worked with an experienced HE service provider for whom there was no need to carry out due diligence for the purposes of the project. Prior to contracting for this type of service, institutions would be advised to carry out their due diligence procedures with any supplier. The issue gains prominence in a technology world of 'apps' and in a HE business world of fast moving, fast changing and transient business requirements. If the sector just uses 'cloud' as a substitute for heavyweight on-premise applications then there is little likelihood of great benefit, the big providers still need to make their returns on investment. But if the sector uses the 'cloud as an adventurous means of gaining competitive advantage then the issues of trust, dependability and due diligence must receive significant attention.
The benefits of cloud delivery in economic terms focus around 3 specific areas, scalability, elasticity and Utility Pricing. This is based around a business model which requires fluctuating levels of capacity, the ability to grow quickly and effectively and to pay only for what is used, like a gas or electricity bill, but on a huge scale. It is arguable that these parameters are less relevant in the HE world than in the commercial sector. Implementation planning encompasses reasonable estimates for growth and Universities do not have large variation in numbers over short periods of time. Nor are storage and power of particular importance. It is not common experience these days that systems slow down significantly because of pressure from the number of transactions and if there is slowness it is likely to be a result of database design rather that hardware inadequacy. Similarly, universities do not have the cash flow issues which makes utility pricing an attractive option.
However, it may be rash to dismiss benefits to be gained from these areas and research and discussion should take place with suppliers to place these issues clearly on the agenda. Otherwise it is difficult to see how there could be significant benefit in the HE sector for expansive cloud deployment of larger business systems. Clouds deliver 'services'. The sector, and the vendors involved, should assess their portfolios to determine which of their business 'services' are suitable for cloud deployment and why and how that could be an advantage to customers. Perhaps, in the vendor constricted world of HE systems, the emergence of new levels of choice is the payoff. Such developments imply that there will be a number of hybrid architectures developed to satisfy requirements on different sites. The supportability of such a world also becomes a large area of concern and reflects keenly on work done through the JISC programmes involving Enterprise Architecture and Flexible Service Delivery.
The potential for hybrid architectures is mirrored in the potential for hybrid 'data' as well. This is probably a more serious problem which could bring the whole thing to its knees. The work on development of standards in this context is absolutely vital and must continue around a core set of student, course and achievement related data. Cloud hosting, spoken quickly, appears to have a number of advantages. But such deployment of services raises specific problems as well.
Lower support costs at the institution end may well result in a greater emphasis and greater resource input on the development and policing of satisfactory SLA's. It is frequently difficult to identify reasons for failure of a module or system when deployed on site with hardware, software and networks all part of the potential mix. It will become harder still to manage a failure situation with cloud deployment with its extensive infrastructure of software, networks and servers off site, as well as corners and reputations to be defended.
In addition, the competitive world of mixed and flexible service delivery often seems to forget that it may still be necessary to deploy multiple API's on site and to train staff in different styles of operation with all the complexity and support which that entails.
Looking Ahead
Sustainability
Sustainability measures relate to a number of project areas. There is philosophical sustainability which relates to whether or not the concept of the project will live on as the project ends, there is the physical access to the project deliverables which must be retained and there is the position of the project concept as a provider of a business solution into the future. Project Cumulus scores highly on all three aspects of sustainability.
With reference to the philosophical sustainability, the deployment of business modules in the cloud is now a well established modus operandi. There are circumstances in each individual site which will argue for and argue against cloud deployment, nevertheless the increased options which Cumulus has demonstrated are possible, mixing a variety of hardware and software architectures, simply extends the range of choice available to an individual institution.
Project Cumulus produced a number of deliverables detailed above. In brief these are:
- A standalone business module
- Sustainability: The cloud hosted business module is available as a production system
- A set of Web Services embedded in the whole Agresso Business World product
- Sustainability: The web services are available for implementation on either cloud hosted or on-premise hosted as part of the Agresso Business World suite of products
- A resilient architecture
- Proof in this context of the capability of the ESB
- Sustainability: Industry Standard software available from Microsoft
- Outputs and inputs of curriculum data in an XML data format to specific recognised UK and evolving pan-european standards
- Sustainability: tested web services
- A deployment document discussing the various options for the architecture
Finally, will cloud deployment become a significant architecture for the provision of business solutions into the future for the HE sector? The deployment option has been proved technically. Institutions will need to work with individual providers and vendors to reach take-off thresholds. From a purely business and sales point of view, however, our vendor, UNIT4 has been prepared to say:
“UNIT4’s Education Solution is based upon systems integration practices that arose through the Cumulus project. Participation has helped UNIT4 ratify our Education Campus Platform strategy and confirm that the provision of multiple applications as part of a Campus Platform solution is the correct strategy for the sector.
A platform solution is one where the applications are provided via the most appropriate deployment method be that on-premise, hosted or in the cloud but working seamlessly together, and is a fundamental requirement for shared services.”
Summary and reflection
The Cumulus Project board, at the final meeting, came to the realisation that the single most important element in the whole “Services Layer/Web Services/Cloud deployment “ scenario is not the technology. As an implementation issue cloud deployment is not complex. It is supported now by many industry standard tools which have been proved many times in many scenarios and which allow a range of deployment options. It is not, after all, surprising that an HTML call can be made to a service which then performs an extraction of data from a database located in some accessible place in the cloud and that that information can be made available to other systems.
What is key to the success of the whole venture is the fact that the data is set to recognised standards for status, content and definition and that that standards can vary with the reason (maybe just the relevant timeframe) for which the data is being extracted.
Without the meeting of the “standard” then it is clearly a danger that all that is being constructed are point to point integrations using state of the art technology.
It is the adherence to standards which makes the difference. So regardless of how an institution runs (say) its curriculum management system internally, if the data and information produced in the process is clearly defined then any satellite system knows exactly what it is receiving and why it is receiving it.
It was requested by the Board that the Case Study emphasise the contribution Cumulus has made to the development of standards and the importance with which these should be viewed. Cumulus has produced a way of providing open information with a standard presentation of transformable, defined data. This architecture explicitly avoids the recreation of the “spaghetti” point to point integrations of the past and also avoids the recreation of this type of architecture under the newer technology of web services and cloud deployment. The Board was anxious to state that, in fact, despite the technology involved, the cloud deployment, the Enterprise Service Bus, the web services, it is the operation of the module to data and information standards which is the key to success.
In this context, the Consortium members are keen to see further trialling work on the emerging XCRI standards. XCRI r1.0 is not yet a formal standard. However, in the opinion of the Cumulus Project Board, XCRI r1.0 should indeed be regarded as the Curriculum Management data standard and the Board recommends this way forward. Further trialling should prove that it is indeed fit for purpose. The Board requested that the Case Study emphasises this strength of feeling about the XCRIr1.0 schema and that the contribution of the Cumulus Project to assisting in the development of this proto-standard should be clearly stated in the Case Study. The schema represents what the consortium institutions regard as required for curriculum management and that this is an effective starting point based on successful mapping from the ACMS module.
Unit4 raised the issue of concern about how the company could be kept up to date so that it could maintain the schema and transforms. With the identification of the vital role that standards must play in these new architectures this is an extremely important issue which must be resolved. The Cumulus Project Board felt that there was a role for the JISC CETIS in this context.
Appendix
The University of Roehampton has its own roadmap to exploit SOA and Enterprise Architecture in order to facilitate the development of IT services as business rather than technology lead.
Alternatively you can access a PowerPoint version from www.roehampton.ac.uk/cumulus
Supporting Documentation
Project Website
www.roehampton.ac.uk/cumulus
