Architectural Rqeuirements and the Visual Architecting Process

Working with hundreds of talented architects across the spectrum of industries as we do, each one of our ideas naturally gets challenged some of the time. With respect to architectural requirements, the main challenge is of the form "our business analysts (already) do this, so why is it part of the architecting process?"

We also hear the conventional analogy between building architect and software architect being challenged on the grounds that software architects are not responsible for the quality of a system in the way that building architects are. A building architect will be viewed as a failure if the building he designs does not have aesthetic appeal, if it fails to provide a good fit to its intended purpose, or if it fails for structural reasons.

Can the software architect (or architecture team) be held accountable for the aesthetics, fit-to-purpose and structural soundness of a software system? The last is most clear. Surely, yes, ultimately the architect must be accountable for the system structure, even though others have a hand in creating the details of the structure. But what does "structural soundness" mean? Maybe we want it to mean "not brittle" where "brittle" means changes to the system are highly error-prone; or maybe we want it to mean "the structure is capable of accommodating load" where "load" may be transaction volumes within a certain range; or maybe we want it to mean it "will not yield to stress" where "stress" may be dramatic changes in scale; and so on. I'm sure you get the point--what we mean by structural soundness differs for each system. We have to live in a world of compromise. No system can have ultra-performance, ultra-quality, ultra-scalability, ultra-you-name-it, and be cheap! By compromise we do not mean settling for the mediocre, but rather picking where to excel. We have to define where we will differentiate our system, and where we will accept doing less well.

Now, are your business analysts going to make these tradeoffs? Are they thinking about this system, and its future variations? Are they thinking about what technology makes possible, and what it makes extremely difficult? If so, you can leave defining the system qualities to them. If not, leverage what they are doing, and make sure that you understand enough about your customers, as well as your business strategy and organization's core competencies, to be able to define and prioritize the system qualities that are important to the market segment(s) you are addressing, and to your business.

System Qualities capture the required properties of the system, such as performance, security, maintainability, etc.--in other words, how well some behavioral or structural aspect of the system should be accomplished.

What about fit-to-purpose? If the architecture makes it impossible, or even difficult, to deliver the desired functionality to the end-user, the architect has clearly failed. On the other hand, if the architecture makes it easier to deliver on commitments to the end-user, the architect has succeeded. So how can the architect best ensure her own success? Firstly, if she has a say in what those commitments are, and how they are staged, she can help ensure her own, and ultimately the whole development team's, success.

Secondly, her architectural endeavor has to be centered around creating a structure that will accommodate that functionality and yet achieve the qualities that will determine the adequate "structural soundness" of the system. Architecture has to make it possible to deliver, and facilitate delivering, the required functionality. To do that, the architect must work from the set of architecturally significant functional requirements for the system. If business analysts are defining the required system behavior, then definitely leverage their work! However, bear in mind that the architect must understand the customer needs sufficiently to make the myriad tradeoffs that will have to be made along the way, and to be able to project how those needs will change in the future. Also, if the scope of the architecture spans multiple systems, the architect needs to explicitly consider what is common across and what is unique to the systems. Further, business analysts are not typically going to make the call between what is and what is not architecturally significant.

Functional Requirements capture the intended behavior of the system—or what the system will do. This behavior may be expressed as services, tasks or functions the system is required to perform.

When it comes to the aesthetics of the system, we have to ask what that means in relation to software systems. If we simply mean the "look and feel" of the system (translating directly from aesthetics in the world of buildings), we would look to the user interface to determine aesthetics. But we do not generally see architects being involved in the details of user interface design, nor do we necessarily advocate this. Should we be so literal in our translation from building to software architecture though? Since buildings are physical structures, the user and customer can see (more of) the structure, and perceive consequences of structural choices like light and flow. We do not look at or move around inside software systems, so we cannot expect to perceive the structure in the same way.

Yet we do have a sense of elegant software structures; when we look at architectures, there are some that we marvel at. What makes us marvel has something to do with how well the the problem is addressed (in terms of both functionality and qualities), and something to do with recognizing the work of a master. Like art and building architecture, our sense of software architecture aesthetics is somewhat individual. Still, since architectures are proprietary, we generally don't get to see too many. Even as architecture consultants, we get to see fewer architectures in a lifetime than works of art in a day at a good art museum. Nonetheless, we should hold architects accountable for architectural qualities such as conceptual integrity and buildability. And, as the discipline of software architecture matures, we will surely develop a more refined sense of what it means to be "great" in software architecture terms.

Architecture Qualities relate to general goodness of the architecture (as opposed to its fit-to-purpose). These include conceptual integrity (the underlying theme or vision that unifies the design of the system, at all levels), correctness and completeness, and buildability.

All this goes to argue that, indeed, the architect needs to work from a set of architecturally significant functional requirements, non-functional requirements (system qualities and constraints) and architectural qualities. Others may do much of the work needed to generate these requirements, but ultimately the architect needs to be responsible for determining the architecturally significant set and held accountable for specifying an architecture which delivers on these requirements. Moreover, if no-one else is chartered with collecting requirements for the system(s) being architected, then the architect has to take on the responsibility of defining the requirements, at least as far as the architect needs to, in order to design the architecture.

We all know that it doesn't matter how quickly we go, if we don't know where we are going! You can't create a great architecture if you have only a sense, albeit grounded in solid experience, of what systems in your domain are expected to do. Your decisions will be arbitrary, and your system will reflect the lack of coherent, directed decision making.

Architecturally Significant Requirements are those that

capture essential functionality of the system
have broad coverage; exercise many architectural elements
challenge the architecture
highlight identified issues/risks
exemplify stringent demands on the architecture (e.g. performance requirements)
•are likely to change
involve communication and synchronization with external systems

References

Malan, R. A., and D. Bredemeyer, "Defining Non-Functional Requirements" (nonFunctReq.pdf, 39kb), August 2001.

Malan, R. A., and D. Bredemeyer, "Functional Requirements and Use Cases" (FunctReq.pdf, 39kb), June 1999.

Malan, Ruth, "Driven by Big, Hairy, Audacious Goals (BHAGs), Complexity is here to stay!," July 28, 2006.

Malan, Ruth, "Requirements and Innovation," July 28, 2006.