Enterprise Architecture in Higher Education, CSU Nathan Bailey, Enterprise Architect, Monash Univers

1
(No Transcript)
2
Enterprise Architecture in Higher Education,
CSUNathan Bailey, Enterprise Architect, Monash
University ITS1st November 2006

• Top-down and bottom-up -- our story
• Monash IT Architecture
• Identifying and adopting reusable best practice

3
Defining the outcome

• Why architecture?

4
The dode
5
Architecture

• reduce implementation and maintenance costs
• improve responsiveness and service
• align university-wide activity (economies of
  scale)
• define growth paths (dept gt fac gt uni-wide)

6
Is architecture about

• the design activity (design)
• the implementation activity (engineering)
• the maintenance activity (service management)
• all more?

7
Top-down

• Governance (Okay)
• Strategic Planning (Good)
• Capital Projects (Good-ish)
• Procurement / acquisition (Good)
• Changing 30 major and 300 minor fiefdoms (Mmm)
• gt Ensuring consistency

8
Bottom-up

• Source code control
• Design and maintenance documents
• Service management documents (ITIL)
• gt Improving reproducibility

9
In the middle

• Information management
• Application portfolio
• Duplication of solutions (shared services)
• Technology and skills register
• as is gt to be impact

10
Data

• RQF
• LTPF
• AUQA
• gt Increased focus

11
Data

• Unified and cleansed
• Building data-mart approach (client facing)
• Building BPEL/SOA approach (back end)
• Still need data model, data dictionary, data
  business owners and rules, etc. (eg. who owns ID
  numbers and how can they be used?)

12
How are we doing?
13
Measuring maturity

• By CMMI
• By artifacts (roadmaps, blueprints, etc.)
• By activity (eg. review sign offs, consults,
  sponsorships, proposals, etc.)

14
Still worry about

• Getting ITS to change (silos and control)
• Identity management
• Data governance
• Risks in compliance (records, IP management, etc.)

15
We have thousands (tens of thousands?) of these
bespoke solutions

• A dozen or more groups managing networks
• Dozens of storage management solutions
• Over 100 groups managing servers
• Hundreds of separate data models stored in
  hundreds of separate databases
• Hundreds of application servers running hundreds
  of separate application frameworks
• Thousands of separate applications written in a
  dozen or more separate languages
• Dozens of different ways of identifying,
  analysing, designing, building, implementing and
  maintaining solutions to business problems

16
Preferred architecture
17
Focus Consolidation and reuse
18
Changing our modus operandi

• Commoditise everything
• Create value in discrete business components (not
  bespoke silos)

19
Big picture
20
Big picture
21
Commoditise compute and storage (cf. grid)
22
Commoditise data models
23
Build discrete, reusable business components
24
Deploy in user-centred, audience targeted,
homogeneous environment