ctu

re
Arc
hit
e

http://www.bredemeyer.com
BREDEMEYER CONSULTING, Tel: (812) 335-1653

The Role of the 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.
These activities drive the competencies that the architect needs to be successful. We present a competency framework that helps architects assess
areas for their own personal development, and managers in identifying who is
a good fit for the architect role.
by Dana Bredemeyer and Ruth Malan
Bredemeyer Consulting
ruth_malan@bredemeyer.com
dana@bredemeyer.com

Architects

ng
cti
ite

For Enterprise Advantage

h
Arc

ARCHITECTURE RESOURCES

Introduction
We often find it useful to look at building architecture and see if lessons learned there apply in our domain.
Though there have been building architects for as long as we have built structures, the regulated profession
of building architecture is less than 150 years old. Ancient, traditional cultures and languages used the
same word for both builder and architect. Construction was an integrated craft. The master mason or carpenter knew how to design structures, estimate costs, assemble labor and materials, and manage the construction process from foundation to roof. With the industrial revolution came new materials, machines,
techniques, regulations, etc. And along with all this came a proliferation of highly specialized subcontractors, who handled each specialized problem. This redefined the role of the general contractor, whose labor
force built less and less of the building. The specialized details of construction became matters for experts
while the role of the architect became more clearly focused on providing overall conception of structures,
and managing the relationship between the client and the builder/contractor (Lewis, 1998).
It is really easy to see the parallels in software and enterprise architecture. It wasn't that long ago that
an individual or very small group might conceive of and develop an operating system or an entire application. Increasing product complexity, project size, distributed teams, high levels of integration within and
even between different product lines, and product lines sharing a common code base, have changed the
processes and roles associated with software development. In particular, over the past few years the role of
architect has been created in many organizations to ensure the overall integrity and critical characteristics
of systems and development processes.
Although the history of the enterprise and software architecture discipline is short in comparison with
its analogous counterpart in the building domain, we have been able to establish several success factors for
the role of the software architect. In this paper, we concentrate on the competencies the architect must have
to be successful in the role.

An Architects Domains of Competency

When we created an architecture workshop for Hewlett-Packard internal use six years ago, we studied
many architecture projects in HP and in the industry, as well as the literature on software architecture and
systems architecture (e.g., Rechtin, 1991), and even looked into some of the work on building architecture.
Since then, we have worked with many leading architects across a broad spectrum of industries, and held
technical exchanges with other industry leaders such as the architecture team at the SEI who have published a number of book related to software architecture.
Based on this understanding, and looking at the architect in the context of the architecting process, we
have identified several critical areas of activity, or domains of competency, that figure prominently in the
architect role. These are technology, business strategy, organizational politics, consulting and leadership.
Below, we take a look at the knowledge and experience, activities and personal characteristics it takes to be
successful in each of these aspects of the architect role.

Technology
As an architect, you need a thorough knowledge of your organizations product domain, relevant technologies and development processes. But even in the technical area, your key activities are different than those
of the developers. The problems are less well-defined, often with unclear or conflicting objectives, and you
play a significant role in clarifying what the objectives are. Your focus is more on the implications of organizational objectives on technical choices. You take an overall system view. You are building models of the
problem and solution space, exploring alternative approaches, preparing documents and explaining the
architecture to sponsors and stakeholders.
The personal characteristics really essential to success in this domain are a high tolerance for ambiguity and a lot of skill working consistently at an abstract level. We know of at least one case where an other-

2002 BREDEMEYER CONSULTING

WHITE PAPER 12/10/04

wise qualified junior architect did not get the senior architect position because of his need for clear and
unambiguous objectives.
What you KNOW
In-depth understanding of the
domain and pertinent technologies

What You DO

What You ARE

Modeling

Creative

Tradeoff analysis

Investigative

Understand what technical issues

are key to success

Prototype/experiment/simulate

Practical/pragmatic

Development methods and

modeling techniques

Prepare architectural documents

and presentations

Insightful

Technology trend analysis/roadmaps

Tolerant of ambiguity, willing to

backtrack, seek multiple solutions
Good at working at an abstract level

Take a system viewpoint

Table 1. Technology Competency Summary

Often this is the extent of how people see the architect role, and this, along with technical consulting, is
in fact the primary role of a junior architect. But as a senior architect you also need to be an effective strategist.
If the junior architect is primarily a technologist, the senior architect is primarily a strategist, contributing to the business strategy and having primary responsibility for defining the technical strategy.

Business Strategy
To succeed in this aspect of the architect role, you need a solid understanding of your organizations business strategy and the rationale behind it, as well as your company or divisions business practices, planning
cycles, and decision making processes. You have a good understanding of the business context of your
organization. You understand your competitors, their products, strategies and product generation processes. You are familiar with the key factors in the business environment that affect your organizations
success, and you are able to distill all these business factors into architectural requirements and architectural choices. But the overriding characteristic that fuels your success in this domain is that of an entrepreneurial visionary who can translate well between the business and technical domains.
What you KNOW
Your organizations business strategy and rationale
Your competition (products, strategies and processes)
Your companys business practices

What You DO

What You ARE

Influence business strategy

Visionary

Translate business strategy into

technical vision and strategy

Entrepreneurial

Understand customer and market

trends
Capture customer, organizational
and business requirements on the
architecture
Table 2. Strategy Competency Summary

2002 BREDEMEYER CONSULTING

WHITE PAPER 12/10/04

As a skilled technologist you create good architecture. As a skilled strategist, you create the right
architecture for your organization. The next three domains of competency are more about getting the architecture realized. The first is about gaining support for the architecture among the management community.
Rob Seliger, the principal architect for the Concert Architecture (Seliger, 1997) for medical information
systems said, the single thing architects most need to learn is how to sell, sell, sell.

Organizational Politics
Architectures almost always have many and diverse stakeholders, and are ultimately meant to be used by
many developers. Often they are used across divisions and by developers in other companies. To gain and
maintain the sponsorship of your management and the enthusiastic support of other key influencers, you
will need to do a good deal of influencing yourself.
You really need to understand both the business and personal objectives of key players, and get them
personally committed to the success of the architecture. This means listening, networking, articulating and
selling a vision, and doing all this continuously over the life of the project.
The people doing this well are extremely articulate and confident. They are resilient and driven, and
they are sensitive to where the real power is and how it flows. They look for and see the organization
behind the organization, and they use this insight to build and maintain support for their projects.

What you KNOW

What You DO

What You ARE

Who the key players are in the

organization

Communicate, communicate, communicate!

Able to see from and sell to multiple

viewpoints

What they want, both business and

personal

Listen, network, influence

Confident and articulate

Sell the vision, keep the vision alive

Ambitious and driven

Take and retake the pulse of all

critical influencers of the
architecture project

Patient and not

Resilient
Sensitive to where the power is and
how it flows in your organization

Table 3. Organizational Politics Competency Summary

This domain of competency generates the organizational support to get the architecture created. The
next one supports getting it deployed into use.

Consulting
The actual users of architecture are development teams creating products or components, and their goal is
not to make your architecture successful, but rather to satisfy their specific functionality, schedule and
quality requirements. While using the architecture may be the best overall approach for the organization,
this is often not apparent to product teams. Consequently, your task as an architect includes recognizing
first that developers are a primary customer, and that the architecture must provide value to them in generating good products. Second, you need to enable product teams to quickly understand and effectively use
the architecture. You are functioning here more as a mentor and teacher, preparing and making presentations, consulting to individuals and teams, and also mentoring junior architects.

2002 BREDEMEYER CONSULTING

WHITE PAPER 12/10/04

What really contributes to your success here is to be truly committed to others success and to have a
good understanding of change management and how groups adopt new processes.
What you KNOW

What You DO

What You ARE

Elicitation techniques

Build trusted advisor relationships

Committed to others success

Consulting frameworks

Understand what the developers

want and need from the architecture

Empathetic, approachable

Help developers see the value of

the architecture and understand
how to use it successfully

An effective change agent, process

savvy
A good mentor, teacher

Mentor junior architects

Table 4. Consulting Competency Summary

So now we have a good architecture. It is the right architecture for the organization. It has got sufficient organizational support to actually get created. And it has been effectively deployed to the developer
community. Its a wrap! Well, not quite!

Leadership
The domain of competency which organizes all the others and gives them dynamic force, is leadership. An
architecture team without leadership goes nowhere. It thrashes and diverges. Weve seen this too many
times. A leader is required to infuse the team with a common vision, and to motivate the core team and
associated teams to do their best work.
This requires dedication and passion, and a strong belief that you can lead the effort. You must see
yourself, and others must see you, as a credible leader.
What you KNOW
Yourself

What You DO

What You ARE

Set team context (vision)

You and others see you as a leader

Make decision (stick)

Charismatic and credible

Build teams

You believe it can and should be

done, and that you can lead the
effort

Motivate

You are committed, dedicated, passionate

You see the entire effort in a
broader business and personal
context
Table 5. Leadership Competency Summary

The diagram below shows that while technology and business strategy skills form a foundation for you
as an architect, the real challenges (and ones that are not always acknowledged) as those in organizational

2002 BREDEMEYER CONSULTING

WHITE PAPER 12/10/04

politics, consulting and leadership. Also, as you become more senior in this role, it is less about what you
know and more and more about who you are--your personal characteristics.
What you
KNOW

What you
DO

What you
ARE

Leadership
Consulting
Organizational
Politics
Business
Strategy
Technology

Conclusion
As we have seen, the architect role is very challenging. A lot of what this role is about is not technical, so
if this is what you enjoy doinggreat! If not, you may not want the role of senior architect.
Before choosing the role, you should also be aware that there are other risks that you should consider.
You will have more responsibility without corresponding authority and control, you will encounter a lot of
resistance and disappointmentswe have seen many an architecture project canceled along the way. And
from every angle you will encounter others that believe they have a better idea.
However, if the challenges inherent in architecting are the kind that appeal to you, then the role has
great rewards. These include a focus on interesting and complex problems, the opportunity to advance very
high in the organization with a continued focus on technical rather than personnel and fiscal issues, and the
opportunity to make an enormous difference to the company.
Success in the architect role depends on skills and characteristics not typically emphasized in university curricula or the on-the-job training. To help you delve further into the various facets of the software
architecture discipline, we host the Resources for Software Architects web site (http://www.bredmeyer.com). The site collects together a variety of resources for software architects. We also encourage you
to participate in the Action Guides for the Software Architect Workshop at the OOPSLA 2000 conference
(see http://www.bredemeyer.com/RoleWorkshop.htm) that we are facilitating with Bill Branson of FrankRussell Company. You may also be interested in our Role of the Architect workshop (http://www.bredemeyer.com/role_of_architect_workshop_overview.htm).

2002 BREDEMEYER CONSULTING

WHITE PAPER 12/10/04

References
Bredemeyer, Dana, James Madison and the Role of the Architect" available on http://www.bredemeyer.com/
papers.htm, June 1999.
Lewis, R., Architect? A Candid Guide to the Profession. MIT Press, 1998. (Note: This book is about the building architect profession.)
Rechtin, E. Systems Architecting: Creating and Building Complex Systems. Prentice-Hall, 1991.
Seliger, R. An Approach to Architecting Enterprise Solutions. HP Journal, Feb 1997

Visual Architecting Process Training for Architects

Software Architecture Workshop. This class focuses on the Visual Architecting Process (VAP). It is

organized around the process. As the workshop progresses, small teams of participants take their project
from vision to architecture. This format, punctuating lectures with exercises that build on one another,
gives participants the opportunity to learn and practice techniques used in each of the process steps.
Open Enrollment Class: Indianapolis, IN on April 5-8, 2005
See http://www.bredemeyer.com/architecture_workshop_overview.htm
Enterprise Architecture Workshop. This class focuses on the Visual Architecting Process for the Enter-

prise (VAP-Enterprise). Following a couple of context-setting modules, the core sections of the course are
organized around the process. It follows a workshop format, with lecture modules followed by team exercises to practice techniques and solidify concepts and models. The Visual Architecting Process for the
Enterprise starts with Business Strategy, identifies and refines the Business Capabilities Architecture, and
uses this to drive the Information (data), Application Solution, and Technology (Infrastructure) Architectures at the enterprise level of scope.
Open Enrollment Class: Palo Alto, CA on March 21-24, 2005.
See http://www.bredemeyer.com/Enterprise Architecture/Enterprise_Architecture_Workshop.htm
Software Architecture Overview Seminar: This course goes over the basics (what, why, how, who,

when, and where) and is a good introduction for managers and developers, business analysts and others
who need to partner with architects in making architecture successful. This class will build insight into the
importance of architecture, as well as the role of architects and others in making architecture successful.
See http://www.bredemeyer.com/Workshops/Descriptions/architectureConceptsWorkshop.htm

Other Training for Architects

Role of the Architect Workshop. Excellent class for architectsaccording to those who have taken it,

that is. This class helps you identify what skills you need to strengthen, and starts you along the road to
building them, while providing options for what to do next to further develop needed skills.
Open Enrollment Class: Indianapolis, IN on May 3-5, 2005
See http://www.bredemeyer.com/role_of_architect_workshop_overview.htm
For more information on our training classes, please see http://www.bredemeyer.com/training.htm.

2002 BREDEMEYER CONSULTING

WHITE PAPER 12/10/04

Resources for Architects

The Resources for Software Architects web site (http://www.bredemeyer.com) organizes a variety of resources that will help you in your
role as an architect or architecture project manager. A number of
Bredemeyer Consultings Action Guides and Architecting Process
Action Guides are on the papers and Downloads page (http://
www.bredemeyer.com/papers.htm). You will also find books and
papers listed under How: The Architecting Process in our Bibliography, and on the Architecture Books List (http://www.bredemeyer.com/Books/recommendedBooks.htm). You may also be
interested in our Software Architecture Workshop, as well as our
Architecture Vision Workshop. For more information, please see http:/
/www.bredemeyer.com/training.htm.

About Bredemeyer Consulting

Bredemeyer Consulting provides a range of consulting and training
services focused on Enterprise, System and Software Architecture.
We provide training and mentoring for architects, and typically work
with architecture teams, helping to accelerate their creation or migration of an architecture. We also work with strategic management, providing consulting focused on developing architectural strategy and
organizational competency in architecture.

BREDEMEYER CONSULTING
Bloomington, IN 47401
Tel: 1-812-335-1653
http://www.bredemeyer.com

2002 BREDEMEYER CONSULTING

WHITE PAPER 12/10/04