UCLA – by the numbers
Budget $7.5b, but with less than 7% of UCLA revenue from California. So part of system, but not strongly dependent upon it.
Culture of distributed systems and responsibilities.
Brand is important, so risk management is important value of architecture.
IT Services doesn't tell other departments department IT what to do,.
IT is a microcosm of U: a bunch of units that function somewhat independently.
If IT says we are doing something, others will watch and see if its something worth pursuing.
Generally not "Symphonic"
ITAC (IT Architecture Committee) facilitated by presidentUCOP (Office of the President) and has campus representatives.
U-wide BoK: campus by campus decision whether to adopt artifacts.
Office of President drafts outcomes and departments campuses decide whether to adopt, reject, adopt with conditions.
Need for certain types of technology agreements for inter-campus applications and systems, e.g. Payroll.
UCOP resources assigned to ITAC may also has begun to look for author best practices that aren't necessary necessarily required for system-wide implementations.
No central function that can override individual campuses. Very few exceptions to this.
- 2012 IT architecture directed unit
- 2016 IT architecture relaunched
- no more architecture reviews
- restrict R&D
- restrict collaboration outside UCLA
- new governance with fewer directors but more campus participation
- establish collaborative groups with architectural aids e.g. models to get to value as quick as possible
- rotate leadership quarterly
- 2017 workshop
- outside consultants to define roadmap
- 2018 state of enterprise architecture (diagram)
- Potentiality limiters: Lack of political support, getting positions posted, lack of trust between architecture and IT teams ....
- Capability limiters: Not having right skills, consistent direction (due to change of leadership).
- Influence limiters: Not enough outreach, no public materials or people don't know where they are, lack of presence on campus
Are there metrics we should have about the things we should be doing?In addition to metrics on things we are doing, consider metrics on limiters that are preventing architecture from maximizing influence.
"Program value gap" determined by mapping these measures: