Chapter 52, Architecture Skills Framework of The Open Group Architecture Framework book (The Open Group, 2014), provides a set of role, skill and experience norms for staff undertaking architecture work.
TOGAF presents the following as job description for an enterprise architect:
“The architect has a responsibility for ensuring the completeness (fitness-for-purpose) of the architecture, in terms of adequately addressing all the pertinent concerns of its stakeholders; and the integrity of the architecture, in terms of connecting all the various views to each other, satisfactorily reconciling the conflicting concerns of different stakeholders, and showing the trade-offs made in so doing (as between security and performance, for example).
The choice of which particular architecture views to develop is one of the key decisions that the enterprise architect has to make. The choice has to be constrained by considerations of practicality, and by the principle of fitness-for-purpose (i.e., the architecture should be developed only to the point at which it is fit-for-purpose, and not reiterated ad infinitum as an academic exercise).” (The Open Group, 2014).
TOGAF considers Enterprise Architecture as a superset of Business, Data, Application and Technology Architecture. It states also that in cases where a team of architects is deemed necessary, a lead enterprise architect should be assigned to manage and lead the team members (The Open Group, 2014):
- The Enterprise Architect
- The Segment Architect
- The Solution Architect
I want to focus in this post on the Solution Architect: he/she “has the responsibility for architectural design and documentation at a system or subsystem level, such as management or security. A Solution Architect may shield the Enterprise/Segment Architect from the unnecessary details of the systems, products, and/or technologies. The focus of the Solution Architect is on system technology solutions; for example, a component of a solution such as enterprise data warehousing.” (The Open Group, 2014).
At my workplace, the Solution Architecture team, to which I belong; has the responsibility of ensuring that a project follows all aspects of the internal Technical Enterprise Process from initiation to closure while aligning the project deliverables with the company’s strategic goals and tactical objectives. In an attempt to be concise, the Solution Architect role is defined as Problem Solver. Identifying solutions by collaborating with the Information Technology and Business teams. Wanting to graph the scope of the Solution Architecture, the following diagram (Enterprise Systems Engineering, 2011) somehow represents my organization:

- EA: Enterprise Architect
- TA: Technical Architect; kind of representing the TOGAF Segment Architect role.
- SA: Solution Architect
The Gartner Enterprise Framework mentions another way of seeing Solution Architecture; it presents three viewpoints and a “meta viewpoint” (Bittler, 2016):
- Business Architecture Viewpoint
- Information Architecture Viewpoint
- Technology Architecture Viewpoint
- Solution Architecture “Meta Viewpoint”

Solution Architects are becoming vital in a world that is changing constantly, where technology is ubiquitous and the complexity of IT systems is increasing dramatically.
Mindi Clews from Equinox IT, published in the web an article “What makes a damn good solution architect?” in which a set of 8 different skills are numbered as following (Clews, 2015):
- Damn good solution architects are expert communicators
- Damn good solution architects have technical pedigree
- Damn good solution architects bring a breadth of experience
- Damn good solution architects zero in on risk
- Damn good solution architects helicopter and deep dive
- Damn good solution architects are pragmatic
- Damn good solution architects fight for the right solution
- Damn good solution architects are lifelong learners
A question came to my mind: Am I a damn good solution architect? If not what am I missing?
References
Bittler, R. S. (2016, January 31). The Gartner Enterprise Architecture Framework, Class Presentation.
Clews, M. (2015, June 6). What makes a damn good solution architect? Retrieved from Equinox IT: http://www.equinox.co.nz/blog/what-makes-a-damn-good-solution-architect
Enterprise Systems Engineering. (2011, September 19). Difference Between Architecture Roles. Retrieved from sysarchitect.com: http://sysarchitect.com/2011/09/19/differences-between-architecture-roles/#respond
McSweeney, A. (2014, June 9). Structured Approach to Solution Architecture. Retrieved from SlideShare: http://www.slideshare.net/alanmcsweeney/structured-approach-to-solution-architecture
The Open Group. (2014). TOGAF Version 9.1. Van Haren Publishing.
very nice post – used your diagram to clarify the roles and responsibilities of EA,SA and TA to our students.
LikeLike