spaces.at.internet2.edu has been upgraded to Confluence 6.12.2. If you have any questions and/or concerns, please contact us at collaboration-support@internet2.edu


Page tree
Skip to end of metadata
Go to start of metadata

Resources for understanding the role of the Solution Architect

Solution Architect Position Description from UMUC

Enterprise Architect Description

Solutions Architect Description

Architect Roles Overlap (spreadsheet)

NextGen Michigan Program Enterprise Architecture Capability Project, Version 1.0 Architecture Design Process 

A Solutions Architect PD from a non-profit:
http://www.slideshare.net/Billy82/solutions-architect-job-descriptiondoc

TOGAF Phases Diagram

Conference Call 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. 

Roll-Up of email list discussion:

Andrew Gianni - University at Buffalo, State University of New York
Jim, these aren't quite ready for prime time and not ready for general distribution, but I've been working with our management team to define architect roles for our department for a while now. I think they're going to be approved in the next few weeks. I'm attaching our proposed Solutions Architect and Enterprise Architect roles and a spreadsheet that shows where there is overlap between those roles and Application architect duties carried out by some of our developers.Much of this is formalizing work that is already being done but hasn't been defined as part of our formal performance programs. We're also in the process of ramping up formal competency centers around specific technologies and platforms (PeopleSoft, Java, RIA/UX, etc.) and we're envisioning those being staffed by Solutions Architects. Up to this point, all of our best practices and architecture practices have been the responsibility of our central Software Engineering and Infrastructure (SEI) group, of which I'm part. The creation of the competency centers is part of an effort to allow SEI to focus on enterprise-level practices, hence the creation of the new EA role.

(see above resources for Andrew's content)
Bruce Savage, Boston Collage 
Here's a Solutions Architect PD from a non-profit.
http://www.slideshare.net/Billy82/solutions-architect-job-descriptiondoc

Rich Stevenson, University of Maryland University Colleges 
We are actively recruiting this role - here's the position description we have.  (see above)
John Gendron, Huron Consulting Group
When thinking about the solution architect position, it's helpful to figure out where the resource will fit into your overall architecture unit. Typically we refer to three areas of architecture: enterprise architecture, solution architecture and technical architecture. If all three areas aren't present, then the solution architect might take on responsibilities for one of the other two areas. The solution architect's responsibilities tend to sit in the middle of the other two areas,  so it's naturally for that role to absorb some of those other responsibilities.

Typically a solution architect is responsible for provide architecture guidance for a specific domain, usually functional in nature. You might have a solution architect who is responsible for the HR, Finance or Student Service domain. Occasionally you will see the domains defined by technology platform: Java, .Net, Batch, etc. The solution architect would have responsibilities for planning architecture roadmaps across the domain portfolio, providing guidance to projects during the concept and design phases of the project, and for performing reviews during the build and testing phases of a project. Architecture planning responsibilities would include technology research and prototyping duties that you mention below.

Another import aspect of the role is interfacing with the customer, being able to understand business architecture and to perform cost benefit analysis for conceptual architecture options. Estimation and high level planning are important elements to the role. These skills tend to be toughest to find considering that most solution architects are going to come from a technical architecture background.

When I worked as a solution architect, I was generally deployed to next generation type projects within a specific business portfolio. I spent most of my time working across two projects, where we were evolving reporting and business intelligence capabilities or migrating a solution to a more modern platform and architecture. Part of my role was to champion enterprise standards and best practices, while the other part was to engage in business architecture and application architecture design. I also was responsible for  helping to select a new enterprise integration platform and to help develop certain standards.

Here's and except from a position description:

Responsibilities:

* The Solution Architect is accountable for architecting and designing solutions that meet business requirements in support of a given portfolio
* The Solution Architect will be accountable for partnering with key project counterparts to create solutions that are aligned to architecture standards and principles, leverage common solutions, services, and processes, and meet the financial targets (cost and benefits)
* Within the solution development lifecycle, this role will be accountable for solution evaluation and selection, buy vs. build decisions, and project estimations which contribute to the business case, and high level design
* He/she will develop strategic plans and roadmaps that define and prioritize key programs and projects that will deliver value to the University
* The architect will support requirements gathering, and will translate functional requirements into architecture and technical requirements
* He/she will provide consulting during the detailed design, build, test and deploy phases, and reengage to perform benefits realization

Skills Required:

* Deep understanding of university priorities and functional areas
* Deep understanding of the processes and systems used by the university
* Deep understanding of development and project management processes and methodologies including common roles, responsibilities, and deliverables
* Ability to determine the architectural implications of business requirements 
* Understanding of the architecture concepts, processes, and best practices
* Understanding of how to leverage services, components, and architectural artifacts
* Strong application design capabilities
* Excellent communication and stakeholder management skills

James Hooper, Mercy Healthcare 
You might look at the TOGAF ADM to judge where the Solution Architect fits in.  Typically they come in after Phase E around the time the PM gets assigned to implement the iteration.   (see above for TOGAF phases).