The Role of the Software Architect

There are those who object most vehemently to the use of "architecture" and "architect" in the software domain (see, for example, the "Hiring the phantom Java architect" discussion on TheServerSide). We even get email to this effect from time to time. Not that we are responsible for this appellation, nor is its use unique to software. It is being used for systems, for products, businesses and even (now this one does raise my eyebrows) the Visa brand! But I do happen to think it is a useful term to leverage in our field. It focuses attention where it needs to be focused: system visualization in terms of bigger structures. You could say a house is but a pile of wood and bricks, nails and such, but it doesn't make sense to (only) see a house that way, if you want to build one. And it doesn't make sense to (only) see a software system as a bunch of bits, or even lines of code. We have to see the bigger structures. The rooms, the flow among them, the supporting walls, the sheltering roof. The components, the interactions, the mechanisms, the subsystems. If we envisage and model larger grained entities, we set ourselves up to be able to create larger grained entities.

For most systems it makes a whole lot of sense to start with architecture, and use that to inform our approach to building the system or set of systems. And recognizing that we are always aggressive in what we try to accomplish, hence always stretching beyond what we have done before, we will learn as we go, and we will have to revisit our architecture. My response to that is simply to remind everyone that the role of the architect is ongoing; it is not just an upfront activity that is then left to petrify, in every sense of the word.

Tec is in the Name (ArchiTECt)

During the Role of the Architect workshop at the end of March, one of the architects emphasized the TEC in the word architect. We enthusiastically agree with the emphasis! That is the necessary foundation, and the ongoing touchstone, for our success as architects in the computing/systems/solutions space. We have to be able to make technical decisions that are respected in the developer community. If we are too removed from our technical roots, we will have a hard time facilitating, guiding and making decisions that stand up under developer scrutiny. We need to build trust and goodwill, so that our stakeholders are willing to advance the goodness of the architecture rather than casting stones at it to see how much they can break.

If we are a product or application architect, this may mean we still write code. But let's face it, how many IF-THEN-ELSE statements does a person have to write in a lifetime? The architect does not have to write just any code to show that he or she is still getting exposure to the technology and staying current with the moving frontier of "hard problems" that must be solved to make this system fly. Either the architect has to have very good relationships with designer/developers who do work on this frontier—relationships that translate through active discussions and open sharing into real insight—or the architect has to work there herself. Ideally, the architect is seen as useful by developers, not just as a political shield, but as a technical problem solver.

The architect role is working well when developers call upon the architect to enter into problem solving with them, especially when the issue they are grappling with touches multiple pieces of the system, or, even if localized in it's impact, it is significant to the success of the system. But if the architect is developing code, who is keeping the architecture up-to-date? This takes bandwidth. Ideally, the architect is involved in addressing, at a conceptual level, the tough challenges that may mean the architecture needs to be revised and updated, and then the architect updates, or better explains and defends, the architecture.

And arch is in the name (ARCHitect)

So the architect has technical roots, and technical acuity so that she is able to quickly grasp technical issues and lead the collaboration that brings them to resolution. But the architect is also the person (or team) with the whole-system purview, hence the emphasis on ARCH in architect (in the section title). The architect deals with over-arching concerns. What are the really big things we have to get right, or we fail? What are the concerns that cut across the pieces of the system? If we want the system to have particular properties, we need to intentionally design the architectural elements and their collaborations to achieve these properties. If we do not, the properties are emergent so that system acceptance is a matter of some combination of luck, developer heroics, and user compromise.

Architecture Versus Design

For those who still wonder why we need the concept of architecture when we already have the concept of design: In the early to mid-90's we were drawn into the nascent architecture field because the design approaches of the day (SA/SD, Booch, OMT, Fusion, ..., leading up to UML and RUP), though promising, still left us holding the ball of complexity. To address complexity, and specifically the problems of tractability, manageability (in human terms), and large-scale (re-)use, we needed to work at a higher level of decomposition than classes, and a higher level of architectural element (components and mechanisms) design to achieve system properties in an intentional way.

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 ditched and rewritten, so this speaks to challenging pieces of the system. The challenges may arise from tendency to change frequently, high risk, stringent demands, etc.

For years we have been using the "big rocks*" metaphor (see slide 6 and 7). If we place several big rocks in a large jar, then add pebbles, and last add sand, we fit them all into our jar. And yes, we could even add water. The point is not that we can always ask the developer to do more! The point is that if we start with the same 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?

The architect of early generations of HP's Openview said "Architecture is the translation of business strategy into technical strategy." This definition focuses on the strategic nature of architecture. Architecture is about designing system capabilities that deliver the value propositions and reinforce the identity of the system (product, service, product-line, etc.) being architected. What is significant, in this view, is driven by what is strategic, and what is strategic determines how we will compete. What is the value we will deliver to our customers, our shareholders, our partners in the value network and our people? What capabilities will deliver this value? What services and properties must characterize these capabilities in order to deliver this differentiating value?

What is architecturally significant, then, is the decision of technically-experienced, strategically-minded architects of a given system (or set of systems, depending on the scope of the architecture). What is architecturally significant differs from system to system, depending on the kind of system and on the strategy; depending on what value this system will deliver and how it will support the differentiated identity of the business and its products or services. How we will differentiate dictates 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.

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.

Although these decisions about architectural significance and relative priorities are the responsibility of the architects, they, like the architecture design decisions, are not best made by the architects in isolation. They are best made by the architects in collaboration with the stakeholders they need to partner with for the system to succeed in delivering differentiating value. These stakeholders include customers and business leaders responsible for business longevity and competitiveness in capital markets, and they include those in the development community (project managers, developers, test/quality engineers, etc.).

ARCHitect, Again

The architect then, makes decisions that require system-wide scope of visibility and responsibility. And the architect also spans the chasm that has existed between "the business" and IT or R&D. Over-arching, bridging the divides, spanning the boundaries. No wonder it takes more than technical prowess, but strategy, leadership, and political skills too!

Sidenote on Building Architects

I came across this interesting post: Building Construction is like Software, by Matisse Enzer on April 3, 2006. Usually we see the analogy being used in the other direction. Interestingly, from time to time we have building architects inquire about our "architectural leadership and other skills" workshop!

References

This column draws on excerpts from Ruth Malan's (almost daily) architecture journal. It is echoed in the essay that launched Ruth's Trace in the Sand blog, and you are encouraged to enter into the discussion.