Requirements
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
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.