2017-05-24 EAMM-edu WG Meeting Notes

Date

24 May 2017

Attendees

• King

Goals

• Discuss Levels and Attributes and finalize a starting framework.

Discussion items

• Reviewed document: https://docs.google.com/document/d/17rQOtcdY5gv2sdfp9tccxQZf1dWlX0zSD8wCFV-Mcvk/edit
  • Focused on combined document & attributes
  • The goal is to try and come to a consensus of the levels
  • JJ - his approach / lenses come from ITSM / ITL service characteristics
  • Piet - not sure about the levels (based on notes from first meeting). Were the levels supposed to reflect the organization or the practice of EA itself?
    • Louis - The most mature level is where the EA program is tightly integrated with the organization's processes.
    • Dan - depending on the organization the scope of the EA program will be different (for example, if EA is part of central IT vs if EA is outside of IT and has broader impact to the university)
    • Louis - Believes that the EA maturity should be related to the integration of EA to the integration as a whole vs just central IT
    • Jim - It might be better to separate the EA maturity level from the reach of EA practice.
    • JJ - the scope EA and its maturity should be separate from each other
    • Dan - the scope vs EA maturity levels should be orthogonal from each other.
    • Piet - agrees with Louis in that EA should have a broad range / scope across the larger organization (the whole university)
    • Louis - the goal of EA should be to have a large impact to the organization as a whole.
  • Levels
    • Louis - take on the exercise was more about the practice of EA and its reach vs JJ and Dan's approach were more about the practice level itself
    • Dan - we can think of the levels as a way to assess an institution's EA practice and how to evaluate how to move to the next level of EA maturity (guidance on the path)
    • JJ - some institutions may choose to only go to a certain level of maturity for some characteristics.
    • Louis - depending on the industry or organization (politic situation) some characteristics / things may never work for an organization
  • Characteristics
    • JJ - should we be using an existing model?
      • Louis - the existing models & language is not accessible to higher ed? The existing documentation is not always great. The value is in keeping things simpler for higher ed. Maybe a simple page that can easily outline the levels compared to 35+ pages that the other models use to describe.
      • Piet - at the end we should measure how accessible the model is to higher ed. What if we could keep up the basic maturity grid very simple. 
      • José - higher ed has special needs & considerations: research vs academia; centralized vs de-centralized IT
      • Louis - there should be a practice guide document that acts as a companion to the maturity levels. That document would answer the question: how did we get there?
      • Dan - sometimes we need to push back in the organization and show the trade-offs of moving to greater maturity levels. The model shouldn't be too opaque or hard to understand between the various levels.
      • Piet - the overview grid should show the big value proposition that EA provides. Somebody at the executive level should be able to consume the document and understand the value of the various stages of maturity.
    • Attributes
      • We're going based on the Piet's approaches since they are more general rather than being too fine grained
      • We need a straw man list so that we can have a starting point
      • JJ - we should also include / mention the deliveries as one of the attributes
      • Piet & Dan - it would be helpful to specify what tools & methods to use to work on deliverables

Action items

• Louis - will work on a draft document to gather a list of Attributes for the Maturity Level and Practice Guide.
• All - review the document that Louis creates and see if there are things that we see missing or want to suggest