Chris Eagle - years in industry and now 3 months in Higher Ed.
Maturity Model Discussion:
Starting with the Carnegie-Mellon Maturity Model for software development:
Initial (chaotic, ad hoc)
Repeatable (etc...
There are many different maturity models that people have developed.
UW-Madison's maturity model looked at 11 different areas in EA. Five steps for each layer mostly.
Artifacts: several people state that they are at level 1 Ad Hoc on development of artifacts in projects
Workgroup discussion:
Maturity Model Group Work
The attendees were broken out into tables based on how long they have had an architecture group on their campus. They then looked through the UW-Madison EA Maturity Model and picked three items they would most like to have. They then picked what level of maturity they most wanted.
Table 1 (Old Timers) |
Table 2 (Newbie Group Yet to begin) |
Table 3 |
Table 4 (Newbie) |
Table 5 |
Table 6 |
|---|---|---|---|---|---|
Governance -- Level 4 managed |
Governance - want to achieve 4-managed |
Governance |
Artifacts |
Governance 4 -- context driven. |
Programme Management 4/5 |
Toolkit -- level 3 standardized |
Business Leadership 2/3 Basic/Standardized Important for starters. Setting sights low as a start point. Political issues seen as an impediment. Just about everyone comes out of IT. Where does IT sit in the organisation. |
Repository |
Toolkits 3.5 |
Programme Management 4 (stretch), 3 (realistic) |
Governance 4 -- requires leadership across campus + portfolio management |
Engagement -- Level 3/4 (minimum/ideal) |
Engagement - level 4 desired. |
Business Leadership |
Engagement |
Engagement 3/4/5 |
Toolkit -- if you get to 3, you mights as well go for 5. 3 -- define what the standard is and 5 would be actually using it. |
Development of assessment of maturity in EA. JISC have one. Van Den Berg has one. We should look at this as a group probably. COBIT 5 covers some of this.
HE institutions may be somewhat distinct from businesses in that having a unified strategic governing body for everything is not achievable; these strategic drivers within HE may not be hugely visible or easily translated to action: "we want to be a leading research institution" given as an example - how do you translate these to implementations? Strategies such as "increase overseas provision" or "increase online teaching" are easier to get to grips with and align against, but can lead to multiple units acting towards these goals in non-unified ways.
A new book, "Bad Strategy, Good Strategy" by Rumelt, talks about these challenges and how aspirations are often mis-sold as strategy.
Table 1) EA Old Timers
Governance -- ideal target Level 4 managed
Views were that they had to keep it real for Higher Education
Level 5 doesn't make sense from a governance perspective
Thinking that this should be across domains (SIS + ERP at ARB)
Getting to adaptive may be a very expensive route. However, disagreement in that level 5 should give you sustained governance. Dream state
Toolkit -- level 3 standardized
Don't seem to be many standardized toolkits like you would find in PMO. May be some templates or stuff they could share.
Didn't seem to make sense in an academic space to try and achieve standardised tools, unless tools == whiteboard.
Engagement -- Level 3/4 (minimum/ideal)
Wanting to be at a 4 where there would be standard metrics applied to understand the value of EA. Very few metrics that they could think of to achieve this. At least go for value of EA being understood.
Table 2) EA Newbie Group -- yet to begin
Governance - want to achieve 4-managed
Business Leadership 2/3 Basic/Standardized
Important for starters. Setting sights low as a start point. Political issues seen as an impediment. Just about everyone comes out of IT. Where does IT sit in the organisation.
Engagement - level 4 desired.
Table 3)
Governance
Repository
Business Leadership
Didn't get to set levels. Engineering view on tolls and repository (Steve). Seen as a critical need to have that. CMDB view / change management driven by repository.
Business Leadership needs to tell a story of IT (for IT)?
Do you need to have everything in a common repository? Jim answered on the value of high-end repositories in terms of impact assessment.
We wandered off on to artifacts and tooling...
Table 4) EA Newbie table
Artifacts
Chose level 3.5
Toolkits 3.5
Engagement
mix of views split between very technical (tools and not much else) and people (we have to work with these people)
Table 5) EA Practitioners for up to 2 years
Governance 4 -- context driven.
Programme Management 4 (stretch), 3 (realistic)
Engagement 3/4/5
Architecture in of itself can be super-mature on its own. Without equilibrium across Governance etc., it's not going to happen.
Table 6)
Programme Management 4/5
Governance 4 -- requires leadership across campus + portfolio management
Toolkit -- if you get to 3, you mights as well go for 5. 3 -- define what the standard is and 5 would be actually using it.
Jim commented that they had had some success in doing this by passing off modeling and update to the LOB people.
Development of assessment of maturity in EA. JISC have one. Van Den Berg has one. COBIT 5 covers some of this. We should look at this as a group.
HE institutions may be somewhat distinct from businesses in that having a unified strategic governing body for everything is not achievable; these strategic drivers within HE may not be hugely visible or easily translated to action: "we want to be a leading research institution" given as an example - how do you translate these to implementations? Strategies such as "increase overseas provision" or "increase online teaching" are easier to get to grips with and align against, but can lead to multiple units acting towards these goals in non-unified ways.
A new book, "Bad Strategy, Good Strategy" by Rumelt, talks about these challenges and how aspirations are often mis-sold as strategy.
Federated Architecture
Overview
Content Tools