Conference Call Minutes, 2007-06-01

DRAFT Minutes, ITANA Conference Call
June 1, 2007
**Attending**Jim Phelps, University of Wisconsin-Madison (chair)
Gary Chapman, New YorkUniversity

Chris Phillips, Universityof Maryland, Baltimore

Ron Thielen, UniversityofChicago

Keith Hazelton, University of Wisconsin-Madison

Tom Barton, UniversityofChicago

Dave Packham., UniversityofUtah

Jon Giltner, UniversityofColorado

Hébert Díaz-Flores, University of California-Berkeley

Steve Mullins, UniversityofAlaska

Renee Martin, North Carolina A&T

Paul Hill, MIT

Ann West, Educause/Internet2

Renee Frost, Internet2

Steve Olshansky, Internet2

Dean Woodbeck, Internet2 (scribe) 
**Agenda**

1. Face 2 Face report out
2. Next Steps (in no particular order)
   1. EDUCAUSE presentation on Enterprise Architecture (why and how)
   2. Architecture Maturity/Implementation Model and Survey of Institutions  (what are the facets to measure?)
   3. Peer list for Peer Reviews of architectural practices
   4. Guidebook for growing EA (maturity)
   5. Shared Use Case / Requirements Documents (Outsourcing email as an example)
   6. Data Management - metadata, best-practices
   7. Common Integration patterns for common applications
   8. Taxonomy of Pain - what are the pain points (related enterprise architecture) and what are the solutions
   9. SOA - Best of breed SOA tools, SOA Governance
      1. Drill down
   10. Role of vendors (like Burton, Gartner, IBM et al) - When do you engage them, What are they good at
3. Sub-teams

Items on the shelf:

1. Mellon ESB Assessment - goal? is there date on this? Mark get Chas on the call
2. EDUCAUSE Full-day seminar on Identity Management at EDUCAUSE 2007 (Request for case studies with different vendor solutions)

(99) Next steps, next call  
**Action Items** 
[AI]

will post thoughts on what EA encompasses on the wiki. 
[AI]

will send a question to the email list, asking if anyone has received an SOA survey. He will also post a sampling of questions from this survey to the wiki. 
[AI]

Review "EA Facets" on the wiki. 
 [AI]

will summarize the UniversityofChicago's EA organizational model and add to the list on the wiki. 
[AI]

will add "data management" to the agenda for the next call. 
**Face2Face Recap** 
Jim Phelps reported 23 people attended the ITANA Face2Face in New York City. Information from the meeting is posted at various places on the wiki. Common themes include refining the role of enterprise architecture (EA) - how and where in campus processes enterprise architects engage in issues surrounding governance and project development. Along those lines, [AI}

will post thoughts on the wiki concerning what exactly EA encompasses. 
**Next Steps for ITANA"** 
The Face2Face provided a substantial amount of information relating to the next steps for ITANA. Jim has started threads on the wiki as a way to generate and prioritize ideas. Look for a list of ideas under the Future Activities link on the wiki home page.  
One discussion point at the Face2Face was the creation of a peer directory, sorting institutions by various characteristics of their use of EA. The list on the wiki could be used as the start of a survey concerning the different campus models for EA. A series of questions could tease out the EA model(s) used at an institution. This could lead to a way for an individual or institution to find organizations that use similar structures, providing a place to seek help and information. 
On the wiki, this area is listed as a "study of EA models, organizational models, maturity models and effectiveness." 
The various organizational models discussed at the Face2Face included:  * Informal/ad hoc architecture - no formal architecture group.  Individuals acting as ad hoc architects in their areas

• Isolated architecture - a "more formal" architecture group but that group is buried in one department
• Federated architecture - architecture deputies around campus working together to form a "enterprise architecture"
• Head architect with domain architects - like federated but with a central lead architect orchestrating the federation
• Central architecture - a core group of architects that review all projects in the enterprise 
  Tom Barton mentioned that none of these models fit Chicago. [AI] Tom will post a definition that fits the model at the UniversityofChicago. 
  Another list of traits would also provide information about the role of EA at institutions. These traits include: * Do you build or buy software?
• Do you outsource activities?
• Are you active in lots of open source projects?
• Do you have a Project Management Office?
• Do you have Portfolio Management Process? 
  A discussion pointed out that there are at least two types of portfolio management processes. One, "service portfolios," refers to the management of services provided to campus units. The second is "project portfolio management," referring to how resources are used for active projects and the development of project priorities. 
  A third way to look at portfolio management is to think of a "capabilities portfolio," where you determine the capabilities you are trying to deliver, which then defines which services you will consider. 
  The discussion turned to how institutions define the role of EA. There was general agreement that EA must include much more than technology - that involvement in business processes and the alignment of IT within the institution is at least as important as the technology. One of the keys for EA success is becoming involved early in the process as new projects are developed. There will necessarily be a set of technology issues related to a project, as well as a set of policy and procedure issues. A successful roll-out requires addressing both sets of issues. 
  There was also a discussion about the role of EA as it relates to service oriented architecture (SOA). One of the issues is figuring out how enterprise architects are involved in SOA. Again, the involvement is as much about policy and governance as technology and software. EA involvement early on in the SOA process - starting with policy and governance - is key to success.  
  Policy and funding models at some campuses seem to work at odds with strategic success. The reward structure values success on a project-by-project basis, as opposed to looking at a range of projects at a strategic level. For example, a development team is rewarded to bringing in a project on time and under budget, rather than on how well a project integrates with the existing campus infrastructure.  
  One of the roles of EA should be advocating for an environment in which projects are expected to take advantage of central campus services, such as authentication and data transfer. In a system that uses activity-based budgeting, however, accounting for costs of central services can actually make a project look more expensive.  
  One future activity for ITANA may be to develop best-practice procedures for accounting for the benefit of enterprise-wide activities (such as providing email, licensing and identity management). 
  These considerations are now on the wiki, under a new category called "the taxonomy of pain - what are the pain points and how do we fix them?" The bullets of pain include: * Budget processes that focus on overall cost, not just localized cost (with activity based cost an example of the latter)
• Developer incentives that reward engaging architecture vs. low-cost / on-time
• Project management mindset is tied to a broken budget model
• What is EA's role in governance?
• What carrots can help overcome destructive budget behavior?  
  The "Future Activities" list on the wiki (derived from the Face2Face) also includes:
• Developing an architectural maturity model and architectural implementation model through a survey of institutions.
• Determining the role build vs. buy plays in how architecture is done at an institution
• Determining the level or open source participation at an institution.
• Using these bullets as the basis for a peer directory 
  Other future activity possibilities include:
• Presentation at the October EDUCAUSE meeting about the role and value of architecture
• Developing information concerning the role of vendors and good/bad experiences with vendors. This could be started as a thread on the wiki
• Collaboration on the integration of applications. Sharing information between institutions concerning the issues/solutions for installation of common applications.
• Data management, on the level of metadata and its relationship to SOA.
• Determining common integration points with a variety of applications and external service providers. This issue arose during a discussion of outsourcing email.

• Developing common requirements for service providers.
• Compiling information/best practices for SOA - SOA tools, SOA governance, version management, data management. 
  ** Next Call ** June 15 at 2 pm EDT