Enterprise architecture at the University of Sydney

2. Enterprise architecture at the University of Sydney …Part I Enterprise Architecture in Higher Education Symposium1-2 November 2006

3. 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?

4. 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

5. 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

6. Architecture drivers & principles Review “as is” Determine “to be” Completion & approval 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. We need to understand where we’re starting from. The architecture is open for comment until mm/yy. We maintain the architecture’s currency using the processes described on page #. The workshop (with faculty & ICT representatives) defines the architecture by consensus.

7. Architecture revision published Exceptions managed continually Architecture input to faculty plans Annual review Maintaining our architecture We begin managing any exceptions to the updated architecture from its approval.All proposed exceptions are notified to Technology Governance Group. 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. ICT reviews compliance with the architecture annually, reporting status and any corrective actions required.

8. Ease of use Wherever feasible, all ICT is consistent Applications & servicesare as independent of end-user location & device as possible Our ICT has a consistent look-and-feel. 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 System vision 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. 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. Principles & drivers of our architecture

9. The technology domain/layers Source: NASCIO EA Tool-Kit Version 3.0 – Technology Architecture

10. Users: The people and organisations who access our information systems 6. Access: The face of the technology that users see through channels, e.g. desktop, portal, thin client, phone 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 7. Systems management: Tools and processes to manage the components in the layers. 8. Security: How we protect information. This includes hardware, software, policies, and processes. 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.

11. Domain example - platforms

12. Technology example - server computing

14. Source: Gartner (2006)

15. MCEETYA learning architecture • Content management • Repository • Library • Curriculum framework • Curriculum systems • Curriculum examplar • Resource assembler • Assessment • Moderation • Reporting • Digital portfolio • School review & improvement • HR system • Teacher registration • Student administration • Data warehouse • Timetable • Learning management • Messaging • Communication tools • Online professional learning • Research • Central finance • Asset management • Records management

16. University learning architecture?

17. Thanks!