The Role of the Software Architect

Architects work at different levels of scope, or focus of decision responsibility. As with the management hierarchy, generally the broader the scope, the more senior the architect, for the responsibility and impact is strategic and demands greater acuity in the areas of strategy, leadership and organizational effectiveness. This is illustrated in the chart on the right, which derives from a visual created by the Embedded Systems Institute in The Netherlands. (The content of this figure is obviously not new news, but I like the ESI representation.)

Titles vary by organization, but to create a frame of reference for this discussion, let's just work with the following: A technical lead may lead a small team developing a service or system component. A software architect is generally responsible for the architecture of a product or application, or the software in an embedded product. In embedded systems, a system architect is responsible for the overall system, including software and hardware components. A product line or product family architect is responsible for the architecture decisions that need to be made across the scope of the product family, in order to meet strategic product family goals (reuse, consistency and brand identity, integration, etc.). A solution architect is responsible for the architecture of solutions that comprise various applications, products or systems.

The critical insight here, is that there is a significant shift from tech lead to architect, and again from architect to product line/family architect and again to solution/portfolio architect, and chief architect and enterprise architect. As this field matures, we have to become more self-conscious about the fact that we have quite distinct pools of competencies that we need to develop, and that from these pools, we need to draw the talent that seeds the next higher layer (in terms of breadth of scope and strategic contribution). It is useful to be explicit about nurturing the architect tree.

It takes investment and attention to develop the talent from which to draw the next level architects. And some of this investment must be made ahead of the need, or you find yourself looking to other architect trees to harvest already grown architects for your higher level positions. Of course, there is value to reaping some architects from another company's architect tree too, to allow growth and to bring in new experience for perpetual "in-breeding" weakens the crop. But too much reliance on such a strategy lays the organization vulnerable in many ways, for deep domain and company/product knowledge is important, and architect talent is in scarce supply.

Succession planning has become popularized for senior positions and we have to apply this to our technical specialist and architect trees, not just the management tree. And we have to recognize that succession planning can't jump suddenly into focus one level down from the top. We need to create pools of talent from which the next level of scope and impact can draw, as well as accelerated development tracks to nurture and speed the most promising talent so that our innovation leadership pipe is always ready to meet our growing need.

Career Planning and Personal Readiness

This is important for the individual to bear in mind too: when I'm a service/subsystem/component owner or tech lead, I need to have my ultimate path somewhat in mind. Do I want to be a technical specialist? an architect? or a manager? Do I want to be a first level architect? Or do I want to set my sights on the top tier where my scope of influence is broad, my strategic impact is enormous, and my remuneration is in line with taking on this level of risk, responsibility and degree of impact? For if I am a component owner and I have aspirations of becoming a first level architect (as my ultimate goal, or as a step on path to broader impact), then I need to start exhibiting the propensities that will make me a good architect. If I am an architect, and I have my sights set on becoming the product family architect, I need to develop in myself what it will take to succeed in that role.

I say this, because what I often face is "that may be all very well for -finger points at architect x- but it is not relevant to me." It is relevant in these ways: it sets the terms of engagement between you and architect x (so you can lead by following well), it sets your expectations about what it means to be in the role of architect x (so you can decide whether you want those responsibilities that come at a cost of losing some responsibilities and focus you have now and probably like), and it helps you see what you need to develop in yourself, so that you can be seen as a suitable candidate for that role and be prepared to excel in it. In other words, if you aren't ready for the role, your manager will probably look to another architect tree to fill their opening—you have to demonstrate the propensity and readiness in advance. Yes, you will grow in the role. But you have to show you have what it takes to make a go of it from the start.

You need to realize this for yourself, so you carve out some bandwidth for preparing for and demonstrating propensity for the next level of scope. If you show no interest in product strategy, no insight into and taste for dealing with issues around visual modeling or creating alignment among people with diverse perspectives, and so on, you paint yourself as a poor candidate for a role that will make those demands.

References

This column draws on excerpts from Ruth Malan's (almost daily) architecture journal.