Standard: Enterprise systems management
- Enterprise systems are business critical software applications that have broad institutional impact, support campus-wide administrative and academic functions, and address key University needs.
- Governance and management arrangements for enterprise systems are required to give the University confidence that:
- enterprise system functionality is aligned to business requirements and strategy;
- operational responsibility and authority are clearly assigned;
- effective planning processes are in place;
- system support and architecture documentation is complete and comprehensive;
- system risks have been identified and are being managed;
- systems are current and fully supported by a vendor;
- systems are responsive, available, robust, and secure;
- system security and data breaches are managed appropriately; and
- system performance is monitored.
Enterprise systems tiers
- 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.
- 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.
- Tier 1 systems are the authoritative source of information for the University and data can be used to assist ANU to meet statutory requirements.
- 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.
- A Tier 1 system requires:
- a Business Solutions Group (BSG) to manage the system lifecycle and prioritise work in alignment with University requirements;
- full-time support staff;
- 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;
- development, test, production, and disaster recovery environments;
- load testing, to establish the peak load capacity for the purpose of major system upgrades;
- a Disaster Recovery (DR) plan including contacts, required Recovery Point Objective (RPO) and Recovery Time Objective (RTO);
- management of data including defined back up, archiving, and retention levels; and
- up to date and comprehensive documentation.
- Tier 1 systems undergo full failover and failback testing at least once every two years, and within six months of any major change.
- 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.
- 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.
- 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.
- A Tier 2 system requires:
- a BSG to manage the system lifecycle and prioritise work in alignment with University requirements;
- development, test, and production environments;
- full compliance with standard University architecture;
- load testing, to establish the peak load capacity for the purpose of major system upgrades;
- a DR plan including contacts, required RTO and RPO; and
- data management including defined back up, archiving, and retention levels.
- 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.
- 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.
- A Tier 3 system is any system not captured in Tiers 1 or 2.
System owner responsibilities
- All enterprise systems have a system owner.
- System owners are responsible for the implementation and operation of their enterprise system, including:
- 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;
- the quality of data held in their system;
- identifying and managing DR plans and business continuity requirements for their system;
- ensuring that risk management, including risk assessment and mitigation, and change management processes, are undertaken for their system;
- 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;
- 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;
- 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
- that relevant applications and operating systems in each area remain the responsibility of that area.
- System owners comply with the following:
- a process for user access to information and application functions is implemented, documented, and reviewed on a regular basis;
- user administration controls in place including formal procedures and processes for granting, removing, and modifying users
- formal change control procedures documented and enforced; and a formal document change process, including risk assessment, and impacts of change, implemented
- 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.
- The system owner establishes a BSG for every enterprise system, regardless of tier.
Business Solutions Group responsibilities
- A BSG may be responsible for multiple enterprise systems within a business area.
- The BSG will provide operational support for business processes within the business area, including:
- ongoing business process review;
- system lifecycle and strategic direction planning;
- risk planning and mitigation including business continuity planning;
- proposals to support new and improved functionality;
- configuration and updates, e.g. modifying the enterprise system without writing new code;
- helpdesk support;
- preparation of system/technical change requests;
- information architecture and data stewardship, relating to the validation and management of data integrity, quality, access, ownership, and usage;
- non-technical change and communication management;
- system acceptance testing, user acceptance testing, and quality assurance, including test script preparation;
- reporting against statutory requirements;
- role based security;
- training and implementation; and
- user documentation.
Information Technology Team responsibilities
- An Information Technology Team (ITT) supports the function of the BSG. An ITT will either:
- 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
- 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.
- The ITT manages:
- system establishment;
- system access and security
- maintenance and upgrades;
- customisation and development as appropriate;
- upgrading production and version control;
- system risk mitigation including disaster recovery (in collaboration with the system owner);
- third tier support;
- unit integration and testing;
- major change and technical life cycle support;
- performance monitoring; and
- systems documentation.
- 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.
- All changes to enterprise systems follow the ITS change management process as described in the Change Advisory Board Terms of Reference.
- 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.
- Minor changes are approved by the system owner or their nominated delegate, and follow business change management and technical change management processes.
- Minor changes to enterprise systems are to be undertaken with consideration of the capacity of the ITT and the BSG.
- 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 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.
- 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.
- 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).
- Business re-engineering proposals are prepared by the system owner, and are based on:
- solving pressing problems;
- ensuring University objectives are met in a timely way;
- realising potential efficiencies;
- estimated returns viewed as an ‘investment’; and
- meeting University and IT strategies.
- A steering committee is required for all service improvements. The committee:
- ensures that the project plan is closely coordinated to ensure that value-add is achieved;
- ensures adequate resource management;
- reviews control changes and recommend additional organisational changes;
- gives authorisation to proceed with each phase of the project or implementation; and
- consults as necessary to flag major policy issues and/or conflicting priorities.
- A funding model is established that supports the development and life extension of enterprise systems. Typically:
- 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;
- 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;
- minor change commitments are carried within BSG and ITT resources based on availability and other commitments;
- service improvement commitments are carried by projects resourced by the University at the time of commitment to the improvement;
- platform (back-office) costs such as infrastructure, are carried by the Director (ITS) where the enterprise system is managed within ITS;
- life-cycle and life-extension analyses is used by the University to provide for future service improvement budgeting where prudent to do so; and
- 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.).
- 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.
- The initial vendor relationship and contract is established jointly by the system owner with the support of the Director (ITS) or nominated delegates.
- Vendor payments:
- initial payment and funding is managed by the system owner with the support of the Director (ITS); and
- ongoing payments to the vendor is funded via the ITS recurrent budget.
- ITS is responsible for the ANU Enterprise Architecture (EA) strategy and roadmap. Individual enterprise systems have a roadmap that aligns with this.
- 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.
- 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.
- All changes to licencing relating to enterprise systems are agreed by the Director (ITS) and the system owner, and follow ANU procurement processes.
- 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.
- The BSG provides solution architecture, in conjunction with the ITT, for each new system or change to existing architecture, including DR architecture.
- Where possible all enterprise applications are mobile responsive, in particular in the case of student-facing systems.
- All other enterprise applications are mobile compatible and configured in alignment with the Information technology security policy.
Enterprise system responsibilities
- 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:
Database administration and tuning
Helpdesk services (Levels 1 and 2 ITIL support)
Level 3 ITIL support
Migration between development, testing and production environments
Application of patches and fixes
Testing and quality control
User documentation/version control
System documentation/version control
System support – primary support to keep the system running
Update role-based security (profiles)
Update and maintenance of access controls (mechanism for access)
Application specific security
Intrusion and breach monitoring and prevention
Specification of change requests and transmission using service management system
Applying configuration changes
Customisation: Coding and application of change requests
Testing and acceptance of changes
Migration of approved changes to production
Technical change management
Preparation of proposals and associated business cases to support major functional change
Preparation of proposals and associated business cases to support major technical change
Managing the technical installation and upgrade projects including establishing the project and project team and undertaking technical and load testing
Managing the functional installation and upgrade projects including establishing the project and project team and undertaking UAT testing
Managing staff in business area
Managing technical staff
Managing business communications and business change
Managing technical communications and technical change
Managing technical life of system from purchase to retirement or decommissioning
Managing functional life of system from purchase to retirement or decommissioning
Reporting against performance measures i.e. up time
Reporting against functional audit recommendations/reviews
Reporting against technical audit recommendations/reviews
Reporting against statutory requirements
Reporting against business metrics
Standard support hours
System support provided during agreed hours
Provision of after-hours help desk support (seldom offered and requires discussion)
Provision of after-hours technical support
Identify risks and plan for risk mitigation
Keeping current with sector knowledge ie. application functional knowledge and its fit for purpose status
Keeping current with technology knowledge
Keeping current with technical roadmaps
Keeping current with vendor roadmaps
Strategy and planning
Sets service strategic direction
Sets technology strategic direction in conjunction with Enterprise Architect including 3 year portfolio and system planning
Determines priority of changes in conjunction of resourcing bandwidth
Determines bandwidth of resources to manage changes
Minor changes to enterprise architecture
Development, updating and storage of enterprise architecture strategy and roadmaps
Development of technology roadmaps
|Printable version (PDF)|
|Title||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. These are required to ensure the security, availability, and integrity of enterprise systems.|
|Audience||Staff, Students, Alumni, Affiliates|
|Topic/ SubTopic||Information Technology - Security|
|Effective Date||2 Apr 2019|
|Review Date||5 Apr 2022|
|Responsible Officer:||Director, Information Technology Services|
|Contact Area||Information Technology Services|
Information Infrastructure and Services Statute 2012
Information Infrastructure and Services Rule 2015
AS ISO/IEC 27002:2015
Australian National University Act 1991
Australian Government Protective Security Policy Framework
Public Governance, Performance and Accountability Act 2013
Public Governance, Performance and Accountability Rule 2014
Australian Government Department of Finance and Deregulation Finance Circular No. 2009/08
Crimes Act 1914 (Cth)
Privacy Act 1998
Telecommunications Act 1997
Telecommunications Regulations 2001