The Architecture of Architecture, Part IV

By Len Fehskens

(Back to article)

Last time, I suggested that the obvious analogy between IT architecture and real building architecture was potentially flawed, because of the dramatic differences in their medium of expression, and that another analogy (with music) might be more appropriate in some ways.


The real lesson, though, is that all such analogies have serious limitations. While these analogies are intuitively appealing, they ultimately fail as models when it comes to the most important property of a useful model: the ability to straightforwardly apply what one learns from the model to the thing being modeled. This is because these analogies imply too many irrelevant details that obscure the essentials, the things that really matter.


How can we get at those essentials? Ideally, how can we develop a model for architecture that not only applies to “our kind” of architecture, but might also be applied to civil architecture and music, because it captures and expresses those things common to all three disciplines, the things that enable those appealing analogies? By answering the question I originally posed,—what is it that we want “our kind” of architecture to do for us?—that led to the consideration of analogy as an approach.


This time, I’ll start by trying to answer that question, and then start wrestling with how we might get from there to a useful definition of IT architecture.


The conventional wisdom about IT architecture has historically included statements like:



These three observations seem to flow into one another. Because architectural decisions are more abstract, they apply more broadly, i.e., are more global, and thus affect many more things, increasing the consequences of changing them. But these observations, even if they’re correct (and I’ll argue later that they’re not), don’t really help us understand what the benefits of thinking architecturally might be. And if architecture is just a more abstract form of design, where does architecture end and design begin?


Why call it architecture rather than, for example:



These terms are frequently used, so we must ask, if they’re not architecture, then how does architecture differ from them? Not much help here either understanding what architecture is good for or how it differs from design.


Lately, other kinds of statements are increasingly heard:



The first of these recent characterizations is more about how one should represent an architecture, though it implies something important about what we hope to get out of architecture: reconciliation and integration of multiple stakeholder perspectives.


The second reflects the current obsession with being responsive to change. Adaptability is only one of many “-ities”, sometimes called pervasive attributes, system qualities or nonfunctional requirements. These are properties of a system as a whole, which cannot be readily isolated in a single component. While adaptability is certainly important in many situations, it is probably unduly restrictive to make it the primary focus of architecture.


The last, though, more directly addresses the question of the value of architecture, and it is inclusive of the other two perspectives on architecture. If this is what we expect of architecture, i.e., aligning technology with the needs of the business, what does architecture need to be to deliver on this promise?


Agile Programming


One answer, the premise of the agile programming movement, is that architecture, specifically when caricatured as “Big Design Up Front” (BDUF), can’t possibly deliver on this promise, and should just get out of the way. While there are a lot of very useful ideas in agile programming, there are too many of us whose first hand experience with architecture has shown that it works in real-world situations to “throw the baby out with the bath water”. Besides, if architecture is really distinct from design, it can’t be confused with “Big Design Up Front”.


One of the most valuable insights of the agile programming movement is that you can’t build a system that delivers business value if you can’t define what business value you need to deliver. Agile programming traces this problem to two sources: lack of understanding of what is needed, and the inherently dynamic “moving-target” nature of what is needed.



It seems to me this would make BDUF the victim rather than the culprit, the true culprit being “Big Requirements Gathering Up Front” (BRGUF). If design is done in response to a set of requirements, BDUF is simply not possible without BRGUF. But if requirements are stable, correct and complete, BDUF will work fine, and be compatible with incremental development and delivery.


It is because of this problem with requirements rather than design that one of the fundamental tenets of agile software development is incremental requirements gathering, with incremental design, implementation and testing following so that the business value of the requirements can be quickly confirmed.


But incremental requirements gathering and implementation with rapid feedback doesn’t by itself address the most important part of the requirements problem: whether each requirement is a legitimate member of the set of necessary and sufficient requirements that define the solution to the business need or, more generally, the solution to the “mission”. To adopt an old Nissan advertising slogan, we want requirements that address “Everything you need and nothing you don’t”.


Without some kind of framework for testing the mission relevance of a requirement, does it matter if you gather them incrementally or in aggregate? Rapidly and frequently confirming the value of the implementation of each additional requirement certainly helps; it ensures that the evolving solution coherently addresses some mission. But how do we ensure it is the right mission?


This is, I believe, the crux of the problem. The IT community has historically focused almost exclusively on creating systems and assumed that someone else can and will adequately define the mission. This is hardly surprising, given long accepted organizational principles like division of labor, separation of function and responsibility, and specialization of skills. But alignment of a mission (i.e., problem, need or opportunity) and its solution would seem to be greatly facilitated if the architectures of the mission and the solution were congruent, which in turn requires that a mission have an architecture, in the same sense that a solution has an architecture.


The Mission


At first, the idea of mission architecture may seem odd, but this too is hardly surprising, as the very language we use to define architecture is inherently solution-centric, specifically, system-centric. Recall the widely adopted definition of architecture from ISO/IEC WD1 42010, “Systems and software engineering -- Architectural description” (formerly IEEE standard 1471, “IEEE Recommended Practice for Architectural Description of Software Intensive Systems”):


“The fundamental organization of a system (is) embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.”


It can be argued that this definition, generously interpreted, can be applied to things other than “software-intensive systems” (e.g., a business mission). Indeed, the standard itself asserts that it is applicable to "systems that are man-made and may be configured with one or more of the following: hardware, software, data, humans, processes (e.g. processes for providing service to users), procedures (e.g. operator instructions), facilities, materials and naturally occurring entities (e.g. water, organisms, minerals).


This definition of architecture is rooted in ideas from software architecture, which gained currency during the heyday of structured programming and software engineering, in the late ‘60s and early ‘70s. It is inherently structurally focused, and is really indistinguishable from definitions of preliminary/abstract/logical/high-level/general design. As such, many practicing solution and enterprise architects find it wanting.


I think we can do better, and next time I will propose a generalization of this definition that is not only more broadly applicable, but also clearly differentiates architecture from design, and explore the implications of thinking of architecture this way.



Len Fehskens is The Open Group’s vice president and global professional lead for enterprise architecture. He has extensive experience in the IT industry, within both product engineering and professional services business units. Len most recently led the Worldwide Architecture Profession Office at Hewlett-Packard’s Services business unit, and has previously worked for Compaq, Digital Equipment Corporation (DEC), Prime Computer and Data General Corporation.