discipline banner.gif (11841 bytes)

More on the Architect Role and Skills

Architecture Teams

Books

Architect Consulting

Consulting Services overview

Architect Training

Software Architecture Class

- Orlando, FL, Dec 12-15, 2011

- Eindhoven, The Netherlands, November 15-18, 2011

Enterprise Architecture Workshop

Role of the Architect Workshop

Enterprise Architecture Seminar (1-day)

Architecture Overview Seminar

Architecture Requirements Workshop

 

component.gif (2086 bytes)

Component Design Class

Software Architecture and UML Class

Architecture Consulting

Consulting Services Overview

 

 

 

The Role of the Software Architect

A simplistic view of the role is that architects create architectures, and their responsibilities encompass all that is involved in doing so. This would include articulating the architectural vision, conceptualizing and experimenting with alternative architectural approaches, creating models and component and interface specification documents, and validating the architecture against requirements and assumptions.

However, any experienced architect knows that the role involves not just these technical activities, but others that are more political and strategic in nature on the one hand, and more like those of a consultant, on the other. A sound sense of business and technical strategy is required to envision the "right" architectural approach to the customer's problem set, given the business objectives of the architect's organization. Activities in this area include active listening to stakeholders values, concerns and goals, creating technology roadmaps and scanning for opportunities to differentiate, and making assertions about technology directions and determining their consequences for the technical strategy and hence architectural approach.

The architect (or team) needs to partner well with a variety of different stakeholder groups, including management at different levels, business analysts or marketing, and developers. The architect needs to balance participation (to gain insight, ensure excellence and get buy-in) with the need to create conceptual integrity and keep the architecture decision process from stalling. The more broadly scoped the architecture, the more likely it is that the architecture will be challenged on many fronts. The architect has to shed distaste for what may be considered "organizational politics," and actively work to sell the architecture to its various stakeholders, communicating extensively and working networks of influence to ensure the ongoing success of the architecture.

But "buy-in" to the architecture vision is not enough either. Anyone involved in implementing the architecture needs to understand it. Weighty architectural documents are notorious dust-gatherers. The early participation of key developers brings good ideas into the architecture process and also creates broader understanding and vested interest in its outcome. In addition, for bigger projects, it can be quite helpful to create and teach tutorials to help developers understand the architecture and the rationale for the decisions it represents. During the construction cycles, the architect needs to be available to actively consult on the application of the architecture, to explain the rationale behind architectural choices, and to make amendments to the architecture when justified. The architect also acts as mentor and coach, working with developers to address challenges that arise, especially when they have broad/systemic impact or are critical to the success of the system.

Lastly, the architect must lead—the architecture team, the developer community, and, in its technical direction, the organization.

Who is Right for the Architect Role?

Too frequently, "architect" is a promotion offered to top-notch developers in an effort to retain them. Unfortunately not all superb technologists have the broader talents and skills that make them good architects. Still, the title raises expectations in the "architect"—and the rest of the organization—that architectural responsibilities are associated with the titled position. This can generate a lot of conflict for a strongly technically-oriented person who is suddenly overwhelmed with organizational politics and communication demands.

The best architects, then, are good technologists and command respect in the technical community, but also are good strategists, organizational politicians (in the best sense of the word), consultants and leaders.

Why We Need Architects

Experience tells us that without having someone (or a team, for larger projects) responsible for the architecture, the architecture is no-one's priority, and it gives way to what is on the priority plate—features that need to be released soon!

More on the Architect Role

References

Barbacci, Mario, "Are Software Architects Like Building Architects?" SEI Interactivehttp://interactive.sei.cmu.edu/news@sei/columns/the_architect/1998/September/architect-sep98.pdf

Bredemeyer, Dana  and Ruth Malan, "What it Takes to be a Great Enterprise Architect," Enterprise Architecture Executive Report, Cutter Consortium, August 2004.  Cutter is running a promotion, and you can download this issue free at http://www.cutter.com/offers/greatarchitect.html. This report is useful for solution, platform and software architects as well as Enterprise Architects.

Bredemeyer, Dana. "James Madison and the Role of the Architect", http://www.bredemeyer.com/madison.htm, 1999.

Bredemeyer, Dana and Ruth Malan. "Role of the Software Architect", http://www.bredemeyer.com/role.pdf, 1999.

Ing, David, August 5, 2005 blog entry On Being a Software Architect.

Lewis, R., Architect? A Candid Guide to the Profession. MIT Press, 1998. (Note: This book is about the building architect profession.)

"Who?: The Architect", HP Software Architecture Web Site,
http://www.architecture.external.hp.com/Overview/arch_who_architect.htm.

Malan, R. and Bredemeyer, D. "Creating an Architectural Vision: Collecting Input", July 2000.

Malan, Ruth, just a few things software architects do (with Archman as guide), 2009.

Rechtin, E. Systems Architecting: Creating and Building Complex Systems. Prentice-Hall, 1991. (Note: Ch. 14 is quite relevant to software architects.)

Worldwide Institute of Software Architects (WWISA) http://www.wwisa.org/wwisamain/index.htm

Restrictions on Use: All material that is copyrighted Bredemeyer Consulting and published on this page and other pages of our site, may be downloaded and printed for personal use. If you wish to quote or paraphrase fragments of our work in another publication or web site, please properly acknowledge us as the source, with appropriate reference to the article or web page used. If you wish to republish any of our work, in any medium, you must get written permission from the lead author (in this case, Ruth Malan). Also, any commercial use must be authorized in writing by Bredemeyer Consulting.  

Copyright © 1999, 2000, 2001, 2006 by Bredemeyer Consulting
URL: http://www.bredemeyer.com
Author: Ruth Malan and Dana Bredemeyer
Page Created: 1999
Last Modified: June 19, 2006