Enterprise architecture at
the University of Sydney
… Part I
Enterprise Architecture in Higher
Education Symposium
1-2 November 2006
Houston, we have an architecture!
• The fundamental organisation of a system,
embodied in its components, their
relationships to each other and the
environment, and the principles governing its
design and evolution
ANSI/IEEE Std 1471-2000
• Deliberate process or inevitable result?
28 June 2016
3
Architectures ain’t architectures
• We develop 4 enterprise
architecture domains in
parallel, iteratively.
• The value proposition is in
the use of the framework,
not in the framework itself.
Framework selection is
less relevant than the use
of its contents
Gartner
28 June 2016
Technology
Business
Applications
Information
4
A few hypotheses
• ICT is jointly delivered by the central ICT
department and faculties. The enterprise
architecture describes it all
• ICT architects are partners, not police
• We cannot eliminate heterogeneity, and nor do
we want to, but it will diminish
28 June 2016
5
Developing our architecture
The University applies
ICT to deliver its vision
and priorities, so we
ground ICT architecture
in the University’s
requirements. This
phase teases out the
architectural
implications of these.
The workshop (with
faculty & ICT
representatives) defines
the architecture by
consensus.
28 June 2016
Architecture drivers
& principles
We need to understand
where we’re starting
from.
Review “as is”
The architecture is open
for comment until
mm/yy.
Determine “to be”
Completion & approval
We maintain the
architecture’s currency
using the processes
described on page #.
6
Maintaining our architecture
We begin managing any
exceptions to the
updated architecture
from its approval.
All proposed exceptions
are notified to
Technology Governance
Group.
ICT reviews compliance
with the architecture
annually, reporting
status and any
corrective actions
required.
28 June 2016
Architecture revision
published
Exceptions managed
continually
Architecture input
to faculty plans
Annual review
After the architecture
revision is approved, it is
complete. The completed
and approved
architecture drives
technology decisions
across the University.
The architecture is a
major technology input
into the faculty planning
process. It drives all ICT
decisions for the
University.
7
Principles & drivers of our architecture
•
Ease of use
•
– Wherever feasible, all ICT is consistent
– Applications & services are as independent
of end-user location & device as possible
– Our ICT has a consistent look-and-feel.
•
– We consider the particular needs of
faculties
– All applications support the business
– We consider the here-and-now in
designing and implementing our
architecture
– Technologies provide net benefits
within three years.
Flexibility
– We provide for exceptions
– We expect new schools and technologies.
•
Minimise cost and effort
–
–
–
–
•
Our ICT is easy to implement & support
We manage ICT infrastructure centrally
We prefer to co-operate
We share components for shared needs.
Reliability
– Mainstream standards when cost allows
– We prefer simple designs
– We buy rather than build whenever possible
28 June 2016
System vision
•
Stewardship
– We make information available in a
timely manner
– We maintain consistent, adequate
security that meets Uni requirements
– We enforce data privacy by adhering
to appropriate privacy policies.
– We choose ICT that provides the
highest value to the University.
8
The technology domain/layers
Source: NASCIO EA
Tool-Kit Version 3.0 –
Technology Architecture
28 June 2016
9
5. Applications: Guidelines for software, including general (e.g.
word processors) and special purpose (research & innovation,
learning & teaching).
4. Integration: ICT such as
middleware, that combines &
connects applications & data
3. Data: The information stored on client computers and servers.
This includes content management, data warehouses,
databases, backup/restore.
2. Network: Campus LANs and the university wide WAN and
the equipment used to support them (cabling, hubs, switches,
and routers).
1. Platforms: Server and client hardware and software. Also
includes user devices such as mobile phones and PDAs.
28 June 2016
8. Security: How we protect information. This
includes hardware, software, policies, and
processes.
6. Access: The face of the technology that users see through
channels, e.g. desktop, portal, thin client, phone
7. Systems management: Tools and
processes to manage the components in the
layers.
Users: The people and organisations who access our information systems
10
Domain example - platforms
Description
Server and client hardware and software. Also includes user
devices such as mobile phones and PDAs
Associated
1.1 Server computing (includes hardware and software)
disciplines and 1.2 Client computing
technologies
1.3 Peripherals (includes printers, personal digital assistants
and mobile phones)
Current state
Diverse platforms, except virtual server environment
Strategy
Purchase limited platforms
Principles,
boundaries
Ease of use. Minimise cost and effort. Applies to enterprise,
departmental.
28 June 2016
11
Technology example - server computing
Current
0 – 2 years
3+ years
Baseline environment
Tactical deployment
Strategic direction
• Windows NT, 2K server
• Various Linux, Unix
• Tru64, and many more!
• MS Windows Server
• MS Windows Server
2003
Vista
• Linux server appliances*
Retirement targets
Mainstream platforms
• Non Red Hat Linux
• Windows NT, 2K server
• Red Hat Linux, MS Windows Server 2003
• Enterprise server = HP, Sun; departmental = HP
Containment targets
Emerging platforms
• Physical server deployments in departments
• Linux
Implications and dependencies
• * Note: “Server appliances” are single-purpose, closed-box servers with no access
to the underlying operating system
28 June 2016
12
Internet
Public users (Students and Staff)
Sydnet
ICT Staff
Staff
ICT ERP Production
ICT ERP Development
Access Perimeter
Development
Departmental
DMZ
Production
Departmental
DMZ
FlexSIS Access Tier
FlexSIS Access Tier
FlexSIS Application Tier
Environment
Perimeter
Application Perimeter
FlexSIS Application Tier
Data Perimeter
FlexSIS Data Tier
28 June 2016
FlexSIS Data Tier
13
Source: Gartner (2006)
28 June 2016
14
MCEETYA learning architecture










Assessment
Moderation
Reporting
Digital portfolio
School review &
improvement
HR system
Teacher registration
Student
administration
Data warehouse
Timetable
28 June 2016


Assessment
and
reporting

Content
management



Staff and
student
management

Learning
systems
Finance and
assets




Central finance
 Asset management
 Records management


Content management
Repository
Library
Curriculum framework
Curriculum systems
Curriculum examplar
Resource assembler
Learning management
Messaging
Communication tools
Online professional
learning
Research
15
University learning architecture?
Collaboration
Research and innovation
•
Messaging
•
Repository
•
Collaboration environment
•
Library
•
Web sites, intranets
•
Research management
•
Video conferencing
Learning and teaching
Finance and administration
•
Learning management
•
Finance
•
Assessment
•
Faculty management
•
Resource assembler
•
Asset, records management
•
Online professional learning
•
Maintenance
•
Learning delivery
Staff and student management
General purpose
•
HR system, OHS
•
Office productivity
•
Accreditation
•
Multimedia
•
Student administration, timetable
•
Reporting
28 June 2016
16
Thanks!