Archive for May, 2006

What distinguishes the Software Architect?

Allan Hoffman at is researching the software architect role for an upcoming article on, and he asked me to give input. Here is his leading question (in italics) and my response:

What are the key elements differentiating the role of a software architect from related roles (project manager, programmer, and so forth)?

The role of software architect particularly comes into play for reasonably complex projects. These require the co-ordination of a fair number of people as they create, improve and extend a collective work product. This is not just a matter of scheduling and workload balancing. Software construction is very far from route manufacturing assembly. Rather it is a process of invention and inventive evolution.

Software architecture has to provide a context for this innovation, creating boundaries within which programmers can work with a high degree of freedom, while nevertheless delivering a system with a coherent identity, with parts that collaborate to produce services with service levels that not simply emergent, but rather the result of a reasoned, goal-oriented process.

Software architects are the people with the skills and experience needed to design these architectural elements that become units of work, and units of innovation and experiment, containing the cost of change through the initial experimental stages, and throughout the evolution of the system.

Software architects need to have real system development experience. But they are not just technically great. They also need to have skills that are more like those of managers, because they need to lead various communities (including developers, but also managers, and others), persuading, consulting, mentoring, and so on.

Software development is innovative work; getting people to work towards something with a coherent identity and integrity is a matter of getting people to voluntarily contribute their imagination and best effort to working towards a common vision, within a common setting of goals, principles and overall system structure, and with a good idea of the commitments their piece of the system must contribute to the overall system purpose.

Setting system goals is strategic, motivating and aligning people to achieve them is leadership, helping people understand them and be successful is consulting, navigating all the relationships and networks of influence to get things done in organizational settings is organizational politics. The architect must have all these skills, or partner very, very well with someone who does!

Useful References:

Added 7/24/06: Allan Hoffman’s article on the Software Architect Career is out and he has done a great job. You can see it at Career Spotlight: Software Architect (

Comments (1)

Architect: not just technically great

Complex software is a collective work product, so constructing software systems necessarily has a social dimension, complicated by the fact that the work is innovative and non-routine. And we can’t just dispense with teams: software teams are about two things: getting more expertise so we can build better products and applications, and getting more bandwidth. Yes, these are two things:

  • The first is about the complexity of today’s products requiring such depth of expertise in diverse areas that it becomes unlikely that just one person holds all that expertise. 

  • The second is about the number of person-hours required to construct the product or application. We can’t wait hundreds of years for software that takes hundreds of person-years to construct!

Architects who recognize that they are more effective when they enable their communities to be more effective, are well on the road to being great. It is not just about the architect making technically solid decisions. It is about enrolling others, and empowering them, to contribute their best. It is about inspiring and motivating, it is about generating goodwill, and it is about enabling co-ordination so that all the pieces will be the best they can be, and the system, composed of the pieces will be the best it can be. (And of course, by “best” I mean best fit to the need taking into account constraints and tradeoffs that have to be made.)

Yes, the great architect is technically great. If it were just about the people side, then we could have stopped at technical project managers and we would not have seen software architects emerge in all kinds of organizations and industries over the past decade or so. There is a strong technical dimension to the role. You can’t just slice-and-dice a system any old way and parcel the pieces out to teams and individuals to build and then recompose the pieces into systems that deliver the services with the intended characteristics or qualities! Even if you start with a common vision, but only have a rough cut at divvying up the system, then you either have endless unproductive bickering about what the pieces mean and who must do what, or you have people going off and making their best guesses at what they were meant to do and maybe, eventually, through immense hard work and mass self-sacrifice, get to something that works. But this path is littered with failures!

So, it takes experience and talent to create a great architecture—architecture that clearly identifies the structures and mechanisms that must be built to deliver the differentiating value propositions and foundational services of the system.  And it takes other skills to help the communities involved make their best contribution to the success of the system.

The architect who understands that he must get the great architecture that is in his head into the heads of the team, is the architect who begins to get the full scale of the challenge! And no matter how great we think the architecture in our heads is, it will be greater if we include others in the process of creating it. We will understand better what the architecture needs to be, to meet the needs of all who have a stake in it. This includes those who will create it, and those who have a perspective on the value this system could, and should, offer.


What is Software Architecture?

To set the context for subsequent posts, I thought we’d start with the topic of “what is software architecture?” Bass, Clements and Kazman’s definition of software architecture  (in essence, the high level structure of the system, described in terms of components and their externally visible properties and the relationships among them) has been very influential. While this definition has resonated with many people, the continuing discussion indicates some remaining uneasiness with definitions proposed so far.  We prefer to use the Bass et. al. definition and focus on the central concerns that software architecture addresses. (You might also like to take a look at Chapter 1: Software Architecture: central concerns and key decisions.) 

Complexity and Cost of Change

We need architecture to manage complexity and cost of change. Grady Booch puts it like this: “all architecture is design, but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.” Cost of change goes up as scope of impact increases, so this definition covers decisions relating to system decomposition as well as those addressing cross-cutting concerns. Cost of change is also high if a significant chunk of the system has to be revised or rewritten, so this speaks to challenging pieces of the system.

Big Rocks First

We use the “big rocks” metaphor (see slide 6 and 7): If we start with the big rocks, then add the pebbles, and last the sand, we fit them all into our jar. And yes, we could even add water. The point is not that we can always ask developers to do more! The point is that if we start with the sand, add the pebbles, and then try to add the big rocks, we cannot fit them all in the jar. To fit them all in, we must start with the big rocks. Architecture is about getting the big rocks in place first.

But what are the “big rocks”? The architectural elements—the components and their relationships, yes. And architectural mechanisms addressing cross-cutting concerns or systemic properties, yes. Big rocks bear a high cost of change, yes. Is there more?

Architecture Implements Strategy

The architect of early generations of HP OpenView said “Architecture is the translation of business strategy into technical strategy.” This definition focuses on the strategic nature of architecture. What is significant, in this view, is driven by what is strategic, and what is strategic determines how we will compete. How we will differentiate dictates the big things we must get right, what hard problems we will tackle, where we will innovate, and where we must be ahead of competition. And it allows us to accept good-enough along those dimensions where we are not trying to create competitive advantage. Of course, even “good enough” may be challenging, especially when taken in conjunction with where we aim to differentiate.

The business or product strategy needs to establish what differentiating value we will deliver to our customers, our shareholders, our partners in the value network and our people. The architect needs to assess what capabilities will deliver this value. Architecture is about designing system capabilities that deliver the value propositions and reinforce the identity of the system (application, product, product-line, etc.) in alignment with the business strategy.

Architecturally significant decisions are those that must be made by the person or team who has influence and perspective across the system in order to deliver on the strategic objectives of the system.

Architecture Balances Differentiation, Complexity and Cost

The architect needs to balance the need to differentiate, with the lifecycle cost of the features and quality attributes we pursue. What we need to do, just to be in the game, constrains what we can accomplish in order to distinguish our products or services and business. For example, in many systems some level of security, scalability, and disaster recovery are threshold attributes not our avenues for differentiation. So we must develop mechanisms (authentication, encryption and firewalls; load balancing; failover, etc.) to address these challenges. Just delivering the base level of features and qualities is challenging, given the threshold set by intense competition in most markets.

Others will have a say in what our opportunities are to differentiate (e.g., marketing). And others will have a say in identifying the challenges we face to build and field systems in our domain (e.g., development). The architect needs to play a role in balancing what we would like to do, with what we are able to do given our resources and capabilities.

Architecture Expands Our Capability

Moreover, the architecture needs to play a role in increasing what we are able to do, and increasing the value of what we attempt to do, by allowing focus. Focusing attention, enabling specialization and separation, understanding where outsourcing or licensing can be leveraged, reducing complexity and scope where it is not essential to our value proposition. Knowing what to focus on and knowing what we can ignore—both are key to success.

Architecturally Significant Decisions

So architecture helps us manage complexity and cost of change, and deliver differentiating value in alignment with our business and product strategy. Architecturally significant decisions are those that the architect (or architecture team) needs to make in order to address these concerns (strategy, complexity, and cost of change). They generally include the high-level decomposition of the system and address cross-cutting concerns. What we do is driven by our business strategy, how we do it is driven by cost of change.

Furthering the State of our Understanding

Whatever else you might add, I hope that in the commentary on this post, you will share as concretely as you are comfortable with given the public forum (and your level of identity disclosure),

  • what are the major concerns you address through architecture, and
  • what kinds of decisions are architecturally significant for your system?

To set context for your observations, it would be very helpful if you would provide some background, such as

  • what kind of system you are working on (embedded system, e-commerce system, whatever),
  • some indication of complexity (like size of the development team), and
  • what your role is.

Comments (7)


Although I write extensively about software architecture, enterprise architecture and the role of the architect, this is my first blog and I enter this world somewhat trepidaciously.

My vision is to use this forum to post essays and host discussions that further our thinking about architecture and the role of the architect.