Standard: Enterprise systems management

Purpose

This standard provides a framework for the governance and management of enterprise systems and defines the roles and responsibilities of Information Technology Services (ITS) and other business areas within ANU. The purpose of this standard is to ensure the security, availability, and integrity of enterprise systems.

Definitions

Definitions of additional terms used in this document are provided in the overarching policy, Information technology security.

Business continuity: the capability of the organisation to continue delivery of products or services at acceptable predefined levels following a disruptive incident. The emphasis in business continuity is on business operations.

Business re-engineering: changes that improve the cohesiveness between enterprise systems and University business processes.

Business Solutions Group: an individual or group that supports tier 1 and/or tier 2 systems.

Configuration: changes to an application via pre-set choices.

Customisation: changes to the application via coding and integrating this with the system. Includes data integration between two or more systems.

Disaster Recovery: both preparation for the recovery of an Enterprise System after major failure, as well as the actual process of recovering should a failure occur. This includes ensuring the right processes, policies and procedures, as well as software, hardware are in place and people are on hand and trained. The emphasis in disaster recovery is on technology.

Enterprise Architecture: defines the technological structure and operation of an organisation for the purpose of determining how it can most effectively achieve its current and future objectives.

Information Technology Team: as not all ANU systems are managed by ITS, this is a more generic term.

ITIL: Information Technology Infrastructure Library. A set of detailed practices for IT service management that focuses on aligning IT services with the needs of business.

Major change: a major change involves a significant amount of preparation, planning and work with complex situations or major expenses (see the Change Management Module Manual for further details).

Minor change: A minor change is a change, where there is minimal risk and impact (see the Change Management Module Manual for further details).

Mobile compatible: A website that is viewable on a smartphone or tablet, but is not optimised for mobile viewing (i.e. ‘mobile friendly’).

Mobile responsive: the layout and/or content responds or adapts to the size of screen they are presented on.

Operating Level Agreement: an agreement between areas that are providing a service together, describing how they will achieve the joint level of service.

Recovery Point Objective (RPO): amount of acceptable data loss.

Recovery Time Objective (RTO): time to restoration after a disaster recovery event is declared.

Service Level Agreement (SLA): an agreement between ITS and another area to which ITS is providing services.

System support: Day-to-day monitoring, maintenance and back end technical support of the system application and infrastructure.

Technology uplift: changes that improve technology platforms to ensure the stability of business processes. The majority of technical uplifts will also require business re-engineering.

Standard

1. Enterprise systems are business critical software applications that have broad institutional impact, support campus-wide administrative and academic functions, and address key University needs.
2. Governance and management arrangements for enterprise systems are required to give the University confidence that:

1. enterprise system functionality is aligned to business requirements and strategy;
2. operational responsibility and authority are clearly assigned;
3. effective planning processes are in place;
4. system support and architecture documentation is complete and comprehensive;
5. system risks have been identified and are being managed;
6. systems are current and fully supported by a vendor;
7. systems are responsive, available, robust, and secure;
8. system security and data breaches are managed appropriately; and
9. system performance is monitored.

Enterprise systems tiers

3. Enterprise systems are divided into three tiers; Tier 1, Tier 2, and Tier 3. Whether those systems are hosted off-site or run on-site, the following classifications are still applicable, although the approach as to how the recommendations are applied may vary.

Tier 1

4. A Tier 1 enterprise system is a University-wide system that supports the core business of the University – research, teaching, and/or learning – with data critical to the University as a whole. A system is considered to be Tier 1 if the University would suffer a critical loss if the system were to be unavailable for two days.
5. Tier 1 systems are the authoritative source of information for the University and data can be used to assist ANU to meet statutory requirements.
6. All Tier 1 systems are endorsed by the University Information and Communications Technology Governance Committee (UICT). A business unit may request that UICT consider a system to be Tier 1 by presenting a business case detailing what it would take to move an application and its supporting infrastructure to Tier 1, including funding to provide the appropriate level of support.
7. A Tier 1 system requires:

1. a Business Solutions Group (BSG) to manage the system lifecycle and prioritise work in alignment with University requirements;
2. full-time support staff;
3. full redundancy, in separate data centres - “warm” standby that can fail-over to disaster recovery with some human input, or fully active-active where no human intervention is required;
4. development, test, production, and disaster recovery environments;
5. load testing, to establish the peak load capacity for the purpose of major system upgrades;
6. a Disaster Recovery (DR) plan including contacts, required Recovery Point Objective (RPO) and Recovery Time Objective (RTO);
7. management of data including defined back up, archiving, and retention levels; and
8. up to date and comprehensive documentation.

8. Tier 1 systems undergo full failover and failback testing at least once every two years, and within six months of any major change.

Tier 2

9. A Tier 2 system is a non-core University-wide system. The effect of a Tier 2 system’s failure on the University is not as critical as a Tier 1 system. Although inconvenienced, the University would be able to function without a Tier 2 system for up to one week.
10. A Tier 2 system will have a lower outage restoration priority than a Tier 1 system in a circumstance in which multiple systems have been impacted by a failure. It will have priority over lower tier systems.
11. There are certain Tier 2 systems that are considered to be Tier 1 at specific times during the year, such as the student admissions system. System requirements and the level of support provided will be determined for each of these systems individually.
12. A Tier 2 system requires:

1. a BSG to manage the system lifecycle and prioritise work in alignment with University requirements;
2. development, test, and production environments;
3. full compliance with standard University architecture;
4. load testing, to establish the peak load capacity for the purpose of major system upgrades;
5. a DR plan including contacts, required RTO and RPO; and
6. data management including defined back up, archiving, and retention levels.

13. A Tier 2 system does not require redundancy infrastructure. If there is no redundancy infrastructure incorporated into the system architecture, recovery time for that system will be slower in the event of a system failure.
14. Tier 2 systems undergo full failover and failback testing at least once every two years, and within six months of any major change. If there is no redundant infrastructure supporting the system then a failover test from system backups must be performed.

Tier 3

15. A Tier 3 system is any system not captured in Tiers 1 or 2.

System owner responsibilities

16. All enterprise systems have a system owner.
17. System owners are responsible for the implementation and operation of their enterprise system, including:

1. ensuring authorised users are advised of all relevant ANU policies and related documents, and are provided with adequate training and support on the use of information infrastructure and security of information assets;
2. the quality of data held in their system;
3. identifying and managing DR plans and business continuity requirements for their system;
4. ensuring that risk management, including risk assessment and mitigation, and change management processes, are undertaken for their system;
5. procedures and processes are in place for the operation and security of the enterprise system, including standard operating procedures and privacy impact assessments; and that such procedures and processes are consistent with current University IT security and privacy policies and procedures;
6. adequate measures are taken to ensure that the application system is protected from unauthorised access by: (1) any utility, operating system or malicious software that is capable of overriding or bypassing application controls and (2) unauthorised users;
7. appropriate steps are taken to ensure the integrity and security of all applications, including that the application does not compromise other systems with which information resources are shared; and
8. that relevant applications and operating systems in each area remain the responsibility of that area.

18. System owners comply with the following:

1. a process for user access to information and application functions is implemented, documented, and reviewed on a regular basis;
2. user administration controls in place including formal procedures and processes for granting, removing, and modifying users
3. formal change control procedures documented and enforced; and a formal document change process, including risk assessment, and impacts of change, implemented
4. audit and monitoring activities logged and recorded; audit and monitoring logs include user activity, exceptions, and events including user ID, date, time, and detail of event.

19. The system owner establishes a BSG for every enterprise system, regardless of tier.

Business Solutions Group responsibilities

20. A BSG may be responsible for multiple enterprise systems within a business area.
21. The BSG will provide operational support for business processes within the business area, including:

1. ongoing business process review;
2. system lifecycle and strategic direction planning;
3. risk planning and mitigation including business continuity planning;
4. proposals to support new and improved functionality;
5. configuration and updates, e.g. modifying the enterprise system without writing new code;
6. helpdesk support;
7. preparation of system/technical change requests;
8. information architecture and data stewardship, relating to the validation and management of data integrity, quality, access, ownership, and usage;
9. non-technical change and communication management;
10. system acceptance testing, user acceptance testing, and quality assurance, including test script preparation;
11. reporting against statutory requirements;
12. role based security;
13. training and implementation; and
14. user documentation.

Information Technology Team responsibilities

22. An Information Technology Team (ITT) supports the function of the BSG. An ITT will either:

1. be established within ITS by the Director. This team may be overseen by an external group or entity at the direction of the Director(ITS) or Chief Operating Officer; or
2. consist of IT technical support staff that are external to ITS. If these groups require support from ITS they will require an Operating Level Agreement (OLA) to define the level of support and responsibility offered between the two teams.

23. The ITT manages:

1. system establishment;
2. system access and security
3. integration;
4. maintenance and upgrades;
5. customisation and development as appropriate;
6. upgrading production and version control;
7. system risk mitigation including disaster recovery (in collaboration with the system owner);
8. third tier support;
9. unit integration and testing;
10. major change and technical life cycle support;
11. performance monitoring; and
12. systems documentation.

24. Privileged access and elevated access accounts can potentially allow access to the entire system, especially if the account provides access to financial, confidential, or otherwise sensitive information or data. Therefore, these accounts need to comply with the Information technology account management and access procedure.

Change management

25. All changes to enterprise systems follow the ITS change management process as described in the Change Advisory Board Terms of Reference.
26. Changes to enterprise systems are approved by the BSG and prioritised with the ITT, based on the ITT’s capacity and the priority of the change.
27. Minor changes are approved by the system owner or their nominated delegate, and follow business change management and technical change management processes.
28. Minor changes to enterprise systems are to be undertaken with consideration of the capacity of the ITT and the BSG.
29. Major changes to enterprise systems can involve significant preparation, a high level of work complexity, and/or major expenses. A change record is to be submitted to the Change Advisory Board to communicate the change as early as possible, with a minimum of 1 weeks’ notice prior to implementation.

Service Improvements

30. Service improvements can include technology uplift and business re-engineering. These may be incorporated into a single project to take advantage of their interdependencies, in which case the Director (ITS) will prepare the proposal.
31. Requests to perform service improvements are to be documented via a project proposal or business case (as appropriate) with endorsement from the Director (ITS) and approval from UICT. These proposals, accompanied by a detailed project plan, are to be submitted to UICT in accordance with procedures on the UICT webpage. In principle approval for funding is sought as early in the planning process as practical from UICT.
32. Technology uplift proposals are based on systems cost and risk to the University of not making the change, and will be prepared by the Director (ITS).
33. Business re-engineering proposals are prepared by the system owner, and are based on:

1. solving pressing problems;
2. ensuring University objectives are met in a timely way;
3. realising potential efficiencies;
4. estimated returns viewed as an ‘investment’; and
5. meeting University and IT strategies.

34. A steering committee is required for all service improvements. The committee:

1. ensures that the project plan is closely coordinated to ensure that value-add is achieved;
2. ensures adequate resource management;
3. reviews control changes and recommend additional organisational changes;
4. gives authorisation to proceed with each phase of the project or implementation; and
5. consults as necessary to flag major policy issues and/or conflicting priorities.

Funding management

35. A funding model is established that supports the development and life extension of enterprise systems. Typically:

1. the BSG role is resourced within the recurrent budget of the system owner’s Director, based on annualised system support estimates. If the ITT is located with ITS, the Director (ITS) will resource these roles;
2. software licensing and vendor costs (including ongoing vendor maintenance and support costs) are carried by the Director (ITS) for recognised Tier 1 and 2 systems;
3. minor change commitments are carried within BSG and ITT resources based on availability and other commitments;
4. service improvement commitments are carried by projects resourced by the University at the time of commitment to the improvement;
5. platform (back-office) costs such as infrastructure, are carried by the Director (ITS) where the enterprise system is managed within ITS;
6. life-cycle and life-extension analyses is used by the University to provide for future service improvement budgeting where prudent to do so; and
7. if not included as part of major project, education and training costs are carried by the Director (ITS) or the system owner’s Director, depending on content (business processes or technical skills etc.).

36. Funding to achieve business transformation is included in the project budget to ensure the investment in technology aligns with the strategic objectives of the University.

Vendor management

37. The initial vendor relationship and contract is established jointly by the system owner with the support of the Director (ITS) or nominated delegates.
38. Vendor payments:

1. initial payment and funding is managed by the system owner with the support of the Director (ITS); and
2. ongoing payments to the vendor is funded via the ITS recurrent budget.

Enterprise architecture

39. ITS is responsible for the ANU Enterprise Architecture (EA) strategy and roadmap. Individual enterprise systems have a roadmap that aligns with this.
40. In conjunction with ITS, the BSG identifies services and capabilities required to deliver both University and local strategies. The BSG and ITS jointly develop the EA vision, including plans and roadmaps to deliver future services that can be achieved within the University’s resource constraints. They select opportunities and solutions to cross the gaps between the current and future state.
41. The ITT develops the underpinning technology roadmaps and work with the BSG to implement the EA vision. This may be achieved by the selection and implementation of new enterprise systems, changes to existing enterprise systems, or by leveraging underutilised functionality.
42. All changes to licencing relating to enterprise systems are agreed by the Director (ITS) and the system owner, and follow ANU procurement processes.
43. Existing building block components such as systems, templates, integrations and tools are used to increase agility, improve quality of information and generate potential cost savings wherever possible.
44. The BSG provides solution architecture, in conjunction with the ITT, for each new system or change to existing architecture, including DR architecture.
45. Where possible all enterprise applications are mobile responsive, in particular in the case of student-facing systems.
46. All other enterprise applications are mobile compatible and configured in alignment with the Information technology security policy.

Enterprise system responsibilities

47. The responsibilities between the BSG and ITT are defined below. Agreement through Service Level Agreements (SLAs) and OLAs is established where responsibilities vary from the service catalogue, or more system specific information is required. System responsibilities include: