Standard: Enterprise systems management
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.
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. (Source: ISO 22301:2012). The emphasis in business continuity is on business operations.
Business re-engineering: changes that improve the cohesiveness between enterprise systems and University business processes.
Configuration: changes to the 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’).
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: amount of acceptable data loss.
Recovery Time Objective: time to restoration after a disaster recovery event is declared.
Service Level Agreement: 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.
- 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 are fully supported by a vendor
- systems are responsive, available, robust, and secure
- system security and data breaches are managed appropriately
- 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 running on- or off-premise (e.g. in the cloud), 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 must be 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
- up to date and comprehensive documentation.
- Tier 1 systems must 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
- 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 must 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.
Enterprise systems management
- All enterprise systems must 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 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 that such procedures and processes are consistent with current IT security policy 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
- that relevant applications and operating systems in each area remain the responsibility of that area.
- System owners must comply with the following:
- a process for user access to information and application functions must be implemented, documented, and reviewed on a regular basis
- user administration controls must be in place including formal procedures and processes for granting, removing, and modifying users
- formal change control procedures must be documented and enforced; and a formal document change process, including risk assessment, and impacts of change, must be implemented
- audit and monitoring activities must be logged and recorded; and audit and monitoring logs must include user activity, exceptions, and events including user ID, date, time, and detail of event.
- The system owner must establish a BSG for every enterprise system, regardless of tier. 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
- user documentation.
- An Information Technology Team (ITT) will support 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 will manage:
- 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
- third tier support
- unit integration and testing
- major change and technical life cycle support
- performance monitoring
- 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 must comply with the Information Technology account management and access procedure.
- All changes to enterprise systems must follow the ITS change management process as described in the Change Advisory Board Terms of Reference.
- Changes to enterprise systems must be 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 must 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. They should submit a change record 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 must 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 should be sought as early in the planning process as practical from UICT.
- Technology uplift proposals will be 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 will be prepared by the system owner, and will be based on:
- solving pressing problems
- ensuring University objectives can be met in a timely way
- realising potential efficiencies
- estimated returns viewed as an ‘investment’
- meeting University and IT strategies.
- A steering committee is required for all service improvements. The committee will:
- ensure that the project plan is closely coordinated to ensure that value-add is achieved
- ensure adequate resource management
- review control changes and recommend additional organisational changes
- give authorisation to proceed with each phase of the project or implementation
- consult as necessary to flag major policy issues and/or conflicting priorities.
- A funding model must be established that supports the development and life extension of enterprise systems. Typically:
- the BSG role will be 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) will be carried by the Director (ITS) for recognised Tier 1 and 2 systems
- minor change commitments will be carried within BSG and ITT resources based on availability and other commitments
- service improvement commitments will be carried by projects resourced by the University at the time of commitment to the improvement
- platform (back-office) costs such as infrastructure, will be carried by the Director (ITS) where the enterprise system is managed within ITS
- life-cycle and life-extension analyses will be used by the University to provide for future service improvement budgeting where prudent to do so
- if not included as part of major project, education and training costs will be 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 must be 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 will be established jointly by the system owner with the support of the Director (ITS) or nominated delegates.
- Vendor payments:
- initial payment and funding will be managed by the system owner with the support of the Director (ITS)
- ongoing payments to the vendor will be funded via the ITS recurrent budget.
- ITS will be responsible for the ANU Enterprise Architecture (EA) strategy and roadmap. Individual enterprise systems must have a roadmap that aligns with this.
- In conjunction with ITS, the BSG will identify services and capabilities required to deliver both University and local strategies. The BSG and ITS will jointly develop the EA vision, including plans and roadmaps to deliver future services that can be achieved within the University’s resource constraints. They will select opportunities and solutions to cross the gaps between the current and future state.
- The ITT will develop 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 will be agreed by the Director (ITS) and the system owner, and must follow ANU procurement processes.
- Existing building block components such as systems, templates, integrations and tools should be used to increase agility, improve quality of information and generate potential cost savings wherever possible.
- The BSG will provide solution architecture, in conjunction with the ITT, for each new system or change to existing architecture, including DR architecture.
- All enterprise applications must be 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 will also be 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
Student and staff support provided during agreed hours
i.e. 9:00am to 5:00pm Monday to Friday
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||1 Nov 2017|
|Review Date||1 Nov 2018|
|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