DIVISION OF INFORMATION TECHNOLOGY
ENTERPRISE ARCHITECTURE
Application Hosting Framework
Version 1.0 – May 2014
Page | 1
v1.0
DIVISION OF INFORMATION TECHNOLOGY
ENTERPRISE ARCHITECTURE
Contents
Introduction ........................................................................................................................................ 3
Support Model Options matrix ........................................................................................................... 4
Internal ............................................................................................................................................ 4
Mixed (Internally hosted with direct vendor application support) ................................................ 4
External ........................................................................................................................................... 4
Business Dimensions ........................................................................................................................... 5
Core versus Non-Core business ...................................................................................................... 5
Enterprise versus Departmental ..................................................................................................... 5
Authentication and Authorisation .................................................................................................. 5
Privacy ............................................................................................................................................. 5
Security ........................................................................................................................................... 5
Cost and impact .............................................................................................................................. 5
Reuse ............................................................................................................................................... 6
Support Standards .......................................................................................................................... 6
Costing Considerations ................................................................................................................... 6
Guiding Principles ............................................................................................................................... 7
Access Control Standards.................................................................................................................... 7
Operational Aspects .......................................................................................................................... 10
Infrastructure ................................................................................................................................ 10
Integration .................................................................................................................................... 14
Application .................................................................................................................................... 15
Records Management (Compliance)............................................................................................. 16
Data ............................................................................................................................................... 16
Exit Strategy .................................................................................................................................. 17
Document Control............................................................................................................................. 17
Page | 2
v1.0
DIVISION OF INFORMATION TECHNOLOGY
ENTERPRISE ARCHITECTURE
Introduction
The purpose of this document is to provide a decision making framework that what should be considered in
determining the method of hosting a solution. It also describes the approved standard options for the support
models for each solution.
It consists of:
 Support Model options
 A list of business dimensions that can be used to assist in making the most appropriate decision
 Costing considerations
 A set of Guiding Principles
 A set of Standards that define the Access Controls that need to be implemented depending on the decision
reached and
 A list of various items relating to operational aspects such as Infrastructure, Data, Integration, Application,
and Records management aspects that need to be considered in the decision process as well as forming a
SLA checklist to underpin the hosting option decided on.
This document recognises that every situation is different and the relative weighting of considerations outlined in
this framework will determine the final decision.
Page | 3
v1.0
DIVISION OF INFORMATION TECHNOLOGY
ENTERPRISE ARCHITECTURE
Support Model Options matrix
This matrix lists the options available for hosting services and applications and reflects who has Primary
responsibility for ensuring correct functionality of the different aspects of the system. Note that the vendor may be
the originator of the application or may be an external support provider.
Operational Layers
Hardware
Operating
System
Application
(1) Internal
DIT
DIT
DIT
(2) Mixed
DIT
DIT
Vendor
(3) External
Vendor
Vendor
Vendor
Internal
CSU provides the hardware and the entire supporting infrastructure. DIT staff has responsibility for all operational
aspects of the system. Application support may leverage advice from the vendor but is executed by DIT staff. The
vendor does not require direct access to the infrastructure.
Mixed (Internally hosted with direct vendor application support)
CSU provides the hardware and the entire supporting infrastructure. DIT staff has responsibility for infrastructure
services but the vendor provides direct support for the application. The vendor connects to the server infrastructure
to manage and maintain the application and works with DIT staff to resolve issues relating to the Hardware and
Operating System.
External
The vendor is responsible for all operational aspects of the application and supporting infrastructure. The server
infrastructure may be located at either the vendor site or a CSU data centre. If the infrastructure is located within a
CSU data centre DIT staff may be occasionally required to assist in operational tasks that require physical proximity
such as cycling power, swapping hardware components etc. They may also be required to assist in analysing
connection problems resulting from the hardware’s location on CSU’s network. The responsibility for problem
diagnosis and all other system functionality remains with the vendor and they should make appropriate provisions to
deal with hardware and system support by their own staff or directly with hardware providers.
Page | 4
v1.0
DIVISION OF INFORMATION TECHNOLOGY
ENTERPRISE ARCHITECTURE
Business Dimensions
Analysis of the following business dimensions may help in the decision making process about what hosting option is
selected.
Core versus Non-Core business
Applications and services that support core business functions rather than ancillary services may be more suitable
for internal hosting. This depends on a variety of factors including legislative requirements, Privacy issues, Levels of
availability and so on.
Enterprise versus Departmental
Enterprise wide systems that are utilised by large numbers of staff and or students often require superior levels of
infrastructure support as well as high levels of integration and commonly have tight dependencies on other
applications. Departmental applications that serve the needs of smaller groups often can be provided with simpler
support levels.
Authentication and Authorisation
Applications commonly require the authentication or identification of users. CSU provide a single sign on system
using SAML2 (implemented by Shibboleth). CSU are investigating support for Microsoft Federated Active Directory.
Applications requiring authentication by students are expected to support CSU single sign on – therefore
authenticated student systems should be internally hosted unless they support SAML2.
Where applications are used only by staff we prefer use of Single Sign On but this requirement may be waived,
especially where there are a small number of users.
Authorisation is the association of roles and privileges with particular authenticated users. Internally hosted systems
may leverage information from CSU Roles, IGMS and LDAP to support groups for authorisation. Access to these
centrally managed groups is likely to be more difficult for externally hosted applications.
Privacy
Recent legislative and policy requirements require us to vigorously protect our users privacy. Whether hosting
internally or externally we must review privacy and security requirements. For external hosting this must include
negotiating contractual safeguards that adequately address our obligations in this area. Externally hosted
applications should be compliant with the CSU Cloud Information Security and Privacy Policy (Pending Publication)
Security
For the integrity of the application, the protection of the users and the reputation of the University applications must
ensure security. A number of aspects are described in the operational section of this document. Externally hosted
applications should be compliant with the CSU Cloud Information Security and Privacy Policy (Pending Publication)
Cost and impact
Differences in cost between internal and external hosting should be balanced against the potential impact of service
loss. It may be cheaper to host externally but appropriate levels of service may not be available from the vendor or
conversely an externally hosted applications may have greater service level guarantees but the costs may be
prohibitive.
Page | 5
v1.0
DIVISION OF INFORMATION TECHNOLOGY
ENTERPRISE ARCHITECTURE
Reuse
If one business unit has a business need than often other units may have the same or similar needs. Hosting
externally may limit the scope of other applications integrating with the service or other business units making use
of functionality within the application. Hosting externally may make integration more complex and therefore more
costly.
Support Standards
DIT has a set of application and infrastructure standards that define and attempt to constrain the variety of
hardware, operating systems, database environments and supporting software stack products that they have to
support and maintain skill sets for. If the application falls outside the standards than it should ideally be hosted
externally. Moreover DIT hosting will provide a best effort level of support where problems occur – external
providers cannot be expected to exceed the standards in their support contracts. Therefore careful consideration
should be given to Service Level Agreements, especially where hosting externally.
Costing Considerations
When analysing hosting costs, a comparison of internal versus external should include the aspects listed in the table
below. While many of these costs may be hidden in general hosting fees (for external providers) and centrally
provided shared infrastructure (for internally hosted systems), costs need to be clarified to assess the true impact.
Because of the dynamic nature of computerised systems and technologies costs should be considered over the
entire lifetime of the solution. Ongoing costs need to be measured not just the establishment cost. It is important to
consider the means by which ongoing costs will be defrayed.
Aspect
Description
Infrastructure Components
Server Hardware
Storage
Backup media
Archive media
Network hardware
Cabling
Power requirements
Environmentally Controlled Data centre
Licensing
Operating System
Database
Storage
Backup Client
Software
Maintenance
Hardware Contracts
Software Contracts
Vendor Support desk calls
Network
Network Traffic
Incoming Off-Net traffic
Support Resources
Analysis & Design
Implementation
Upgrades
Program development
Infrastructure support
After Hours Maintenance
Support Staff Training
Page | 6
v1.0
DIVISION OF INFORMATION TECHNOLOGY
ENTERPRISE ARCHITECTURE
Notes:
1) Business continuity infrastructure needs to be considered where required
2) Incoming network traffic uploaded to CSU hosted servers as well as data from externally hosted (outside AARNET)
systems accessed from within our network is charged to CSU. An externally hosted application primarily accessed by
staff located on the CSU network will have network data costs. Conversely a CSU hosted system to which external
users upload data will also have data costs.
Where the traffic charges are incurred as a result of external hosting or utilisation of an externally provided service
and not the result of user instigated actions the charges should be paid for Organisational Unit responsible for the
external application or service.
Guiding Principles
Solutions outside the Application and Infrastructure support standards – “External”
1. Where appropriate service levels apply, integration and data issues are manageable and cost difference is
not a substantial factor – “External”.
2. If “External” model is not applicable Off the Shelf Applications using “Mixed” model should be used.
3. If “External” or “Mixed” are not appropriate – “Internal”
4. Regardless of the hosting option all operational aspects should have good understanding through an SLA
(“External”), OLA (“Internal”) or Both (“Mixed”)
5. Operational Aspect considerations should be reflected in RFP, RFT, and RFI documents
Access Control Standards
For direct access to server infrastructure to support a CSU application or service, the following controls apply. The
following section lists categories of people that require access and the technologies that provide the various
methods of access to the solution as well as a matrix that defines the level appropriate.
Access Control Matrix
Administrative Access
DIT
Vendor
Non-DIT Staff
Consultant
Unix
(1) SSH2 or (6) OOB or (5)
VmWare
(1) SSH2 and
(2) VPN
(1) SSH2
X
Windows
(3) RDP or (5) VmWare or (7) KVM
(4) Term
(3) RDP
X
Application Support Access
Unix
(1) SSH2
(1) SSH2 and
(2) VPN
X
(1) SSH2 and (2) VPN
Windows
(3) Term
(4) Term
X
(4) Term
Administrative Access
Highly privileged access such as” root” on unix or “Administrative User” on windows. Allows full control over all
operating system functionality
Page | 7
v1.0
DIVISION OF INFORMATION TECHNOLOGY
ENTERPRISE ARCHITECTURE
Application Support Access
Direct access to the Operating System through an account (personal or generic) that has restricted privileges. This
access should be restricted to only the privileges necessary to support the relevant application.
DIT
DIT staff who may be accessing the system from inside the CSU network or externally
Vendor
Support Staff of the application vendor that are providing direct support. They usually access the infrastructure from
outside the CSU network
Non-DIT- Staff
CSU employees that are not DIT staff who are allocated infrastructure for personal use. Examples may include
Academic Platforms and the Innovations environment.
Consultant
Non-CSU staff engaged on a consultancy basis to support applications, develop code, or provide any service that
requires access to the operating system.
Access Technologies
1. SSH2 (Secured Shell)
a. Used on mainly on Unix/Linux systems
b. Encrypted end to end communication
c. Text (CLI) based access
2. Virtual Private Network (VPN)
a. Encrypted End-to-End network connection
b. Needs enabled CSU account in Radius
3. RDP (Remote Desktop Protocol)
a. Full desktop access to server with privileges of account used to log in
b. Encrypted end to end communication
c. Local drive Mapping
4. Terminal Services Gateway
a. Uses RDP protocol
b. Policy Based control of connections
c. Controls Drive Mapping Options
d. Controls User account access to servers
5. VmWare Console
a. Control of Virtual Environment
b. Stop, Start and monitor Virtual Machines and underlying hardware
c. Direct console access
6. Out of Band Management (E.g. Advanced Lights Out Management (ALOM) console)
a. Sun Server Infrastructure
b. Stop and Start Operating System and control hardware (Power Cycle) remotely
c. Direct Console Access
Page | 8
v1.0
DIVISION OF INFORMATION TECHNOLOGY
ENTERPRISE ARCHITECTURE
d. Interfaces in Secure Subnet
7. Remote KVM access
a. Remote Console access to windows servers
Notes:
 Duration of access is limited to the association that the person has with the University. I.e. staff lose access
when their employment is finalised and Vendors and consultants lose access when the relevant contract
expires.
 Vendor and consultant access should be on an ad-hoc basis by arrangement and should be enabled as
required to carry out the necessary work not left open for extended periods.
 Dial-back modem arrangement is in place for storage vendors to perform pre-emptive fault monitoring and
maintenance tasks. This type of access should be contained to the hardware involved.
 Where possible access from a predefined IP range should be enforced to ensure that client machines that are
potential security risks are not being used. (E.g. On consultants home computers or Airport Internet terminals
etc.)
 Supporting vendors and consultants need accounts within the CSU Authentication System. These accounts
need to be created by the business owner and any costs incurred by that account charged to their cost centre
code.
 These controls should be used in conjunction with the “Policy for Remote Access Connection to CSU Network”
(Pending Publication)
Page | 9
v1.0
DIVISION OF INFORMATION TECHNOLOGY
ENTERPRISE ARCHITECTURE
Operational Aspects
Infrastructure
Operating System Patching
The operating system needs to be patched to resolve functional bugs and security vulnerabilities. Patches are
provided by Operating System Vendors and can be applied via several different methodologies.
These include
 Single Patches
 Generic Patch Clusters (Eg Solaris Recommended Patch Clusters)
 Tailored Patch Clusters (Eg. xVM Ops centre)
 Automated Patch Deployment (WSUS, Windows Update)
Backups / Restores
Taking copies of data to Tape media at regular intervals to protect against disk failure, corruption or accidental
deletion as well as restoring the data back to disk on request.
There are different backup methods utilised depending on the importance of the data and the different type.
Unstructured data located on File-systems often utilises incremental backups where only changed files are copied to
tape where this makes little sense for an oracle database for example as all files change regularly and the database is
not in a consistent state unless specific intervention is made prior to the commencement of backups.
Backups are supported by underlying storage technologies such as replication, cloning, and Snapshots
Network Integration
Servers are located in different logical isolated network segments depending on security requirements. Physical
wiring to ports on network devices as well as network card and router configuration determines this. Speed settings
and other network traffic parameters need to be set on the server and the router to ensure correct functionality
Page | 10
v1.0
DIVISION OF INFORMATION TECHNOLOGY
ENTERPRISE ARCHITECTURE
Security
Servers, associated storage, and network traffic are all security touch-points that need to be considered to ensure
applications and data are protected from accidental or malicious activity.
Security Categories include:
 Network
o Firewalls (ACL’s)
o Packet Inspection
o Sub-netting
o Intrusion Detection
o Transfer Encryption
 Server Based Security methods
o Host Firewalls
o Port Activation
o Database Security
o File- System permissions
 Client based security
o Anti-Virus
o Malware protection
o Usage of Public Access Computers
o Data storage on mobile devices
 Physical Security
o Data Centre Security
o Cable Security
 Confidentiality Agreements – should cover not just what use is made of data but how it is accessed.
Monitoring
Network, Server, Storage and Application layers need to be proactively monitored to ensure short term optimal
performance.
Monitoring types include:
 Availability – Uptime of the application and associated supporting infrastructure
 Performance - Adequate application response times
 Resource - CPU, Memory, Storage, network etc are not exceeding predefined limits
Page | 11
v1.0
DIVISION OF INFORMATION TECHNOLOGY
ENTERPRISE ARCHITECTURE
Capacity management
Network, Server, Storage and Application layers need long term resource monitoring and statistical analysis to
ensure infrastructure resources are sufficient to maintain optimal application performance.
This includes:
 Trend analysis
 Demand forecasting
 Resource forecasting
 Modelling
Licensing
Applications and all components of the supporting infrastructure and software stack need to meet the licensing
requirements of the relevant software and hardware vendors. Licensing compliance is an ongoing process.
Authentication
Access to applications as well as the supporting infrastructure needs to be limited to authorised people.
Authentication is the process of ensuring the person requesting access is who they claim to be. Externally hosted
solutions potentially introduce the need for sharing authentication data in a secure method.
Authorisation
Once authenticated a user must be limited to the set of functions they are allowed to perform. This can be based on
group membership of individual permissions.
System Logging
Operating System events such as successful and failed access requests, system errors, issued commands etc are
logged in a variety of system log files.
Uses of these files include
 Detailed Access Auditing- may be requested internally or subpoenaed
 Statistical Analysis
Physical Access
Physical Access to infrastructure and the media that contains data needs to be rigorously controlled
 Data Centre Access
 Media handling and Disposal
Page | 12
v1.0
DIVISION OF INFORMATION TECHNOLOGY
ENTERPRISE ARCHITECTURE
Business Continuity
Business continuity is a wide range of strategies and technologies that allow the business functions of an enterprise
to continue in the event of failure. The extent of the anticipated failure may vary from localised infrastructure failure
to a catastrophic event that requires full geographically remote Disaster Recovery infrastructure. The level of
Business Continuity should be relevant to the business value of the solution
Aspects of Business Continuity include
 Redundancy
 Clustering
 Data Replication
 Failover / Failback
 Alternate business methods (eg Paper Based)

Business continuity requirements are largely driven by the definition of two significant aspects.
 Recovery Time Objectives (RTO)
o What is the guaranteed timeframe for restoration of a working system in the event of catastrophic
failure?
 Recovery Point Objectives (RPO)
o What is the guaranteed minimum period of data loss in the event of catastrophic failure?
Problem Analysis
All solutions encounter problems from time to time. Problem analysis involves identifying faults and failures within
often very complex systems. The “Root Cause” of a problem may cross several infrastructure layers between
Application, Operating System, Storage and Network or could be related to Application Code or application
dependencies. Who is responsible for identifying and resolving system problems should be well defined.
Application Environments
Applications often require different environments with varying degrees of support levels. The following Matrix
defines the supported application environment types.
Application Environments
Environment
Description
Production
Clients conduct business
Quality Assurance
Functional testing of in-house enhancements
Development
In-house enhancements developed and tested
Training
Client application training
Implementation (Build & Test)
New versions implemented and tested prior to migration to
production
Page | 13
v1.0
DIVISION OF INFORMATION TECHNOLOGY
ENTERPRISE ARCHITECTURE
Integration
Authentication and Authorisation
Authentication and Authorisation is currently provided by a set of technologies that are consumers of data located in
the CSU central authentication system (www_access & associated tables). In the future this will evolve into a more
sophisticated Identity Management (IDM) System. Applications where possible should leverage the existing and
future systems to utilise existing usernames and passwords as well as authorisation to services and privileges
associated with their role. If the solution is hosted externally to CSU this may be more difficult and may require
transfers of sensitive data between the application and the CSU IDM system that have the potential to dilute security
or require additional software such as Shiboleth to conduct that exchange in a more secure way.
Data integration
Most applications are either providers or consumers of data in an end-to-end business process. If an application is
hosted externally than the ways in which data is exchanged between applications involved needs to be rigorously
controlled.
 Secure transfer methods need to be implemented to protect privacy and integrity of the data
 Transformation of data between applications needs to be well defined and reflect the appropriate business
rules.
 Dependencies on other CSU applications as well as the timeliness of the data sharing need to be well
defined.
 The differing way the data is represented or interpreted (transformation) between applications needs to be
clearly defined and articulated to ensure business rules are being satisfied and no data is being
misinterpreted.
Program Integration
Some applications provide Application Programming Interfaces (API) with their products. This allows customer
organisations to extract and contribute data in meaningful ways using well defined methods. It can allow nonstructured reporting with a third party tool for example. It also allows the development of supporting functionality
and other dependent applications without having to alter the data structures or modify the baseline code of the
application. Any API’s should be considered when assessing how the application fits into business processes.
Multi-Mastering
Applications that provide an entry point for data that is held in another repository has the potential to reduce data
integrity. If there is a two way data flow between applications there has to be strict business rules to resolve any
data conflicts resulting from concurrent changes.
Page | 14
v1.0
DIVISION OF INFORMATION TECHNOLOGY
ENTERPRISE ARCHITECTURE
Application
Auditing
Many applications log information in Operating System files or in database tables that are not readily accessible to
application users. These files and tables are often interrogated for auditing purposes to establish who accessed
what parts of the application when, where they accessed it from etc. Access to this data may be required for internal
business reasons, by the Universities auditing bodies, or may be subpoenaed in a legal matter. Who has
responsibility for extracting and providing this data needs to be defined
Statistical Analysis
Many applications log information in Operating System files or in database tables that are not readily accessible to
application users. These files and tables may need to be interrogated for statistical analysis purposes. Who has
responsibility for producing the relevant statistical reports needs to be defined
Application and Software Component Patching
Most applications and solutions are built on supporting software components (Software Stack) such as common
application servers, web servers and databases as well as operating system libraries. As well as operating system
patches there are often software stack patches released to address bugs and security vulnerabilities. An agreed
balance must be struck between disruptions to the service, optimal performance and integrity of the data
Installation and Upgrades
Of The Shelf applications introduce unique operational aspects that are not inherent in In-House developed
solutions. One of the major considerations is the original installation of the software and associated Operating
System integration as well as the ongoing implementation of application upgrades.
Responsibility and timing needs to be defined for:
 Who does software installs
 Who does upgrades
 The method of upgrade E.g. Vendor sends out disks or vendor logs on directly
 How often upgrades are performed
 What are the demarcation points? E.g. who prepares Operating System for application install etc.
Page | 15
v1.0
DIVISION OF INFORMATION TECHNOLOGY
ENTERPRISE ARCHITECTURE
Records Management (Compliance)
Retention Periods
There are legislative requirements to maintain certain data for differing periods of time. It is necessary to ensure to
solution and application vendor agreements have the capacity to meet those requirements during the lifespan of the
product as well as after it is decommissioned if required.
Archiving
Archiving usually involves extracting data from an application for the purposes of long term storage to meet the
defined retention periods of the affected data. Data may also be deleted from the application if the retention
requirements are met to improve system performance.
The following need to be considered:
 Media Type – E.g. paper, Magnetic Tape, Optical disk or movement to Records Management solution.
 Record Location – For environmental control, security, access etc
Data
Regulatory requirements
Any regulatory requirements that prescribe where data is to be maintained need to be considered when assessing
the hosting Solution.
Privacy
Privacy legislation relevant to any data stored in the solution or data transferred to and from it need to be
considered and compliance guarantees sought from the vendor and consultants. DIT Staff should be referred to
Confidentiality Agreement arrangements.
Sensitivity
The sensitivity of data should be assessed to ensure adequate levels of security are implemented for the solution.
Some Examples of sensitive data include:
 Profession - E.g. Policing students
 Medical Records - E.g. Dentistry Clinics
 Personal identity E.g. Tax file number, date of birth or other personal details that may be used for identity
theft or Social Engineering purposes
 Financial data E.g. Bank account Details or Credit card Details
 Authentication Data E.g. Usernames and Passwords
Ad Hoc reporting
Solutions hosted externally may have a reduced ability to do unstructured reporting or data mining with nonapplication provided interfaces.
Master Data
Consideration must be given to data held in the solution to determine if it is enterprise or master data that may be
used by another application. If data is held externally than it may be more difficult to conduct data exchange in a
timely or secure manner.
Latency (timeliness of shared data)
The timing of data exchanges may be extended if solution is external.
Page | 16
v1.0
DIVISION OF INFORMATION TECHNOLOGY
ENTERPRISE ARCHITECTURE
Exit Strategy
Any external hosting agreement will need to carefully consider an Exit Strategy in the event of termination of the
contract or insolvency of the company etc.
Contingency strategies need to be in place for:
 Recovery of data or to ensure that the external company no longer maintains CSU data
 Replacement Application
 New Integration interfaces
Document Control
Version
0.1
0.2
1.0
1.0
Page | 17
Author
Kieran Fromholtz
Kieran Fromholtz
Kieran Fromholtz
Kieran Fromholtz
Issue Date
23/04/2010
28/04/2010
29/05/2014
06/02/2015
Revisions
Initial draft.
Cost considerations added
Incorporate feedback/additions from Paul & Luke
Minor adjustments
v1.0