Jim Phelps, University of Wisconsin - Madison (chair)
Mojgan Amini, UCSD
Marina Arseniev, UC Irvine
Kasia Azzara, Columbia
Glenn Donaldson, Ohio State University
Dan Brint, SUNY
Chris Eagle, University of Michigan
Jim Green, Michigan State University
Karen Hanson, UW Madison
Christian Johansen, PSU
Leo Fernig, University of British Columbia
Scott Fullerton, University of Wisconsin – Madison
Mark Poepping, CMU
Rich Stevenson, University of Maryland University College
Emily Eisbruch, Internet2 (scribe)
-On behalf of this group, Rich put in a proposal for EDUCAUSE presentation.
-Would present the contents of the reference architecture
-Presenters would be Rich from UMUC, Scott Fullerton from Univ-Wisc and Mark McCahill from Duke
-Would be a campus perspective presentation
-Will learn in June whether the proposal has been accepted
-The idea is being floated for a F2F workshop for this group sometime in May
-Congratulations on the progress being made in this group, glad to see the work going forward
-There is a learning initiative under EDUCAUSE
-Jim will work on creating a bridge between the ITANA group and the EDUCAUSE group
-ECAR has replied with some minor changes to the ECAR paper regarding the SOA survey
-Leo will keep the group informed.
Starting EA Solution Path / Maturity Model Working Group
-Colleen Nagy, of Case Western, is leading this group
-Chris Eagle reported that This group has started meeting
-Had 10-11 people on the first call
-Group will most likely meet every 2 weeks
-Collen will draft a 1st draft of the charter
-Looking for references for an EA maturity model, even if those maturity models do not apply to HE
Jim suggested this maturity model example, which was primarily a brainstorm:https://wiki.doit.wisc.edu/confluence/display/ARCH/Practice+Maturity+Model
Rich suggested:
-Gartner maturity model
-Open Group Maturity Model (Rich has created their seminar)
-Chris Armstrong of Armstrong Process Group (has worked with PSU)
-John Polgreen (from a London-based firm "Architecting the Enterprise"). Rich can help make this connection
Jim also suggested to look at JISC maturity models
-possibly Paul Hobson could be of help
Leo suggested that the "Starting EA Solution" group and the "Learning Architecture" group may want to work together around maturity models and frameworks
-Jim has reached out to EDUCAUSE and told them we want to do both of these in 2013
-Waiting to hear back. Jim will keep the group posted.
-The planning subgroup is meeting on Feb 15.
-The reg for the F2F will be a separate registration from the EDUCAUSE Conference
Theme: "EA Helps Shine a Light on IT"
-response to EDUCAUSE thread about IT as black hole
-Joint Screen2Screen with the CIO constituent group (Jim has reached out to Theresa Rowe)
-timeframe: early March
-Hoping to present 3 case studies at the Screen2Screen
-Jim will present a case study from Univ. Wisc. (on Advising Architecture review board)
-Paul Hobson at UBC may discuss their usage of Troux (technical focus)
-Jim is open to suggestions on a possible 3rd case study for the Screen2Screen
Rich: UMUC is coming up on 3-year roadmap cycle
-Doing a capability roadmap
-Hope to reflect that into different technology projects
Example from the roadmap view:
-Office of Enrollment Management has a goal to stand up a one-touch service center for students to call into.
-That led to a strategic goal to have one view of customer data
-That led to IT program for more mature customer relationship management platform
-Led to IT spend and IT projects
Jim: this would make a good third case study for the Screen2Screen.
There was brainstorming & discussion (continued from the January 31 call) about this framework, presented by Jim:https://spaces.at.internet2.edu/download/attachments/30966076/Engagement+Value+Matrix.pdf
FRAMEWORK: Matrix to look at our projects and think about how we communicate with campus.
-The Y-Axis is "Business Value".
-Near zero is "hard to demonstrate business value" and at the top is "easy to demonstrate business value."
-The X-Axis is "Architectural Maturity".
-Near zero is "many architectural tradeoffs, hinders architecture maturity" and at the far end is "drive architecture maturity".
-Brainstorm about the "factors" that define both axis.
On the Jan 31 call the group discussed "Business Value."
Today the brainstorming is on "Architectural Maturity"
What should be the high level headers under "architecture maturity"?
How would we measure this?
James Phelps: They might be pseudo-TOGAFian: Organizational, Process,
Information, Technical
Leo Fernig (University of British Columbia): 1: IAM maturity (enabler for
everything) 2: SOA maturity
cjohansen (penn state): standardization, integration
Marina Arseniev (UC Irvine): Linked to Business Goals; Business people
heavily involved; Reusable; Repeatable EA
Rich Stevenson (UMUC): little to no duplication of function
Rich Stevenson (UMUC): or capability
Marina Arseniev (UC Irvine): Tied to SDLC practices
Jim Green - Michigan State: well matched to business goals
Marina Arseniev (UC Irvine): EA team is properly funded
Rich Stevenson (UMUC): few exceptions to target architecture
Glenn Donaldson (Ohio State): Data Center, Integration, Business Process
matruity, EA tied to PLC & SDLC & also Strategic plans/goals
Marina Arseniev (UC Irvine): EA Team members are also members of major
project teams or at least part of all strategic projects
Jim Green - Michigan State: synergy between governance, linkage with
business goals, technical architecture standards
James Phelps: Reusable, Leverage, Scale, Recombine
James Phelps: Process, Technology
James Phelps: Standardization
James Phelps: Engagement
poepping: where an architecture can affect the business approach
Marina Arseniev (UC Irvine): high business value might be the reduction of
workflow steps in a process, reduce time involved, and add maybe bring in
actionable real-time data instead of stale data?
James Phelps: X-Axis does it equal infrastructure requirements? Is it
the amount of the architecture you use in the solution.
Discussion:
-Jim: example is that Univ-Wisc is rolling out next generation of SOA infrastructure (new ESB, registry, etc.)
-that is an important step for the maturity of the architecture
-but applications go on top of that infrastructure
-such infrastructure is harder to explain than something more concrete to users
-need a good framework for communicating the value
-architecture can be about how to assemble components
-there are many abstractions
-good to be able to layer and do tiering; lower level constructs help you build higher level constructs
-good to layer components/solutions to leverage and reuse them where it's possible to extract value
Next ITANA Call: Thursday, Feb 28 at 2pm ET