Draft Minutes, ITANA call of 18-July-2013

Attending
Jim Phelps, University of Wisconsin - Madison (chair)
Brenda Reeb, University of Rochester
Mojgan Amini, UCSD
Rich Stevenson, University of Maryland University College
Michael Janke, Minnesota State Colleges and Universities
Arin Komins, University of Chicago
Scott Fullerton, University of Wisconsin-Madison
Andrew Gianni , University of Buffalo
Joe Tarter, UW-Madison
Marina Arseniev, UC Irvine
Glenn Donaldson, The Ohio State University
Chris Eagle, U. Michigan

DISCUSSION

What is a Solution Architect?

Resources discussed on the call are linked from: https://spaces.at.internet2.edu/display/itana/Solution+Architects+and+EA+July+2013

There was recent conversation on the ITANA list about definitions of Solution Architect.
This arose from this question from Joe Tarter of University of Wisconsin, that JimP posted on the list:

The Application Development and Integration ( ADI ) group within UW-Madison's Division of Information Technology is researching a potential new role for a "Solutions Architect" and is seeking contacts or other informational resources from institutions with a similar functional role already in practice. More specifically, we'd like to collect information on exactly how the role is being used in practice, along with any lessons learned. And, of course, sharing of actual PDs would be a plus. At a very high level, the role concept would be rooted in R&D and the discovery of options/solutions based on immediate business problems. There would be a strong component of relationship management to garnering support for innovative solutions by leading or leveraging various methods - proof of concept/prototyping, cost/benefit analysis, business process improvement, alignment with campus/business unit strategy, etc. One could consider this foundational pre-project work generating interesting in and momentum around project solutions.

Comments about the Solutions Architect Role:

-Arin from U. Chicago commented that she fills the Solutions Architect role for U. Chicago, though that is not her current job title. She is now Sr. Project Manager. One way of viewing things is that the Solutions Architect has a 1-2 year vision, concerned with immediate tactical implementation. In contrast the Enterprise Architect has a 5-year vision.

-JoeT commented that this is an evolving space. There seems to be a bias toward technology architecture, at least in the private sector.

-JimH of Mercy Healthcare noted in an email on the list that Solution Architecture is in the Phase E (Operations and Solutions) section of TOGAF architectural framework.

-Andrew stated that at U. Buffalo there is an effort to formalize the architecture practice. They are drafting the architect roles. It's challenging to know what to call things so there is a common vocabulary for making improvements. Solutions Architecture needs to be involved at an early stage (Phase B or C) of the planning, probably earlier than Phase E.

-Rich: At UMBC, the Solutions Architect gets involved around Phase G of TOGAF. The idea is that TOGAF is primarily about Enterprise Architecture, (it's like the urban planning stage). Then for further refinement and solutions, the work gets turned over to the Solution Architect (like the house designer) to implement the solution. As part of Phase G (Implementation Governance), the Enterprise Architects check in on the Solution Architects to be sure specs and visions are being followed. Then some reconciliation may be needed, and that is Phase H - Architecture Change Management.

It was observed that there is some iteration and overlap in each phase.

-Arin: Involvement from the Solution Architect is valuable during discovery, during design, and during testing.

University Michigan has good resources showing this involvement. Shows roles and interaction between roles

JoeT: Two definitions for Solutions Architect:
1) Solutions Architect as someone who defines a solution based on some set of standards.
2) A Solutions Architect can also deal with R&D, thinking of possible solutions available for a need.

What about a platform-specific solution architect?
JimP: Risk of the situation where one platform is seen as the answer to every issue.
Arin: often there are not enough resources for a platform-specific Solutions Architect.

Andrew spoke about his draft document being used at U. Buffalo

UC Irvine: The larger projects, like PeopleSoft, get funded and proceed pretty well. Smaller projects often get done in stove-pipe fashion and there is the danger of breakage after one or two years, due to lack of planning. Does use of a Solutions Architect help reduce this problem of silo systems that are not robust?

A: Yes, the Architect can help address this. But don't want to be perceived as a bottleneck. Organization needs to accept that doing architecture right can take more time up front but can help avoid failure later.

-JimP: For rolling out ERP systems, there can be a fear of "scope creep" if architects get involved.

-Andrew: U. Buffalo has centralized IT within the past few years. This has greatly increased the diversity of the portfolio and the systems to support. Need to manage all the stove-pipes well!

At U. Wisconsin, there is an effort to streamline, and an " IT Decision Making process" is being developed to assess new initiatives.

Scott: Knowing where to do the hand-offs from an enterprise architect to a solution architect is a challenge. Where it's possible to be specific about a pattern, you may want to had the project off to Solution Architect. An area that a solutions architect has never heard of may be a job for an enterprise architect.

Rich: it's a struggle to know where EA stops. Don't want EA to be a rubber stamp that approves every project. Also don't want EA to be an impediment that slows every project down. At a certain point there were no Solution Architects on staff. Now that there are Solution Architects, it's a hard balance to strike between the different architect roles.

Staff constraints have become a challenge at many institutions.

ITANA at EDUCAUSE 2013

ITANA F2F at EDUCAUSE 2013
Tuesday, Oct. 15, 8AM to 4PM (Seminar 07F) http://www.educause.edu/annual-conference/2013/seminar-07f-itana-face2face-2013-ea-action-value-enterprise-architecture-separate-registration-and-fee

IT Architects Constituency Group at EDUCAUSE:
Thursday, Oct. 17, 1:30pm-2:20pm http://www.educause.edu/annual-conference/2013/it-architects-cg

ITANA (un)Conference 2013 at EDUCAUSE:
Thursday, October 17, 6:30pm – 8:30pm
A fun time working through a few topics in un-conference style. Pitch a topic, build a following, lead the discussion, all in a short amount of time.