Neo: Who are you?
Architect: I am the Architect. I created the Matrix. I have been waiting for you. You have many questions and although the process has altered your consciousness you remain irrevocably human, ergo some of my answers you will understand and some of them you will not. Concordantly, while your first question maybe the most pertinent you may or may not realize it is also the most irrelevant.
Bumper stickers for architects:
What others say about architecting:
Webster’s Ninth Collegiate Dictionary: The art or practice of designing and building structures and especially habitable {workable} ones.
Brook’s Mythical Man-Month: [T]he complete and detailed specification of the user interface.
Mack Alford, Ascent Logic: Dual problem of translating user needs into system requirements and the specification of components, that when integrated, will satisfy those requirements.
James Rumbaugh, Object-Oriented Modeling and Design: The overall structure of a system, including its partitioning into subsystems and their allocation to tasks and processors.
We have all experienced the failure brought on by bad architecting, but we usually do not discover this until it is too late. And often, the fact that the underlying architecture of a product is the root cause of a project/product failure is never realized. A study conducted by the Standish Group of over 8,000 telecom projects revealed the following results:
Failure Statistics
31% of projects will be canceled before completion
53% of projects will cost 189% of their original estimates
9% of large company projects are done on time and on budget
Completed projects have only 42% of originally proposed features and functions
(*No flames please, I know there is a competing study by the Cutter consortium published in 2005 that disputes these dismal statistics.)
I am convinced that bad architectures were underlying many of these failures, cost overruns, etc.
In an ideal world, architecture definition is easy. As Charlton Heston said to Yul Brynner in The Ten Commandments (1956), “So shall it be written, so shall it be done." In other words, once I have created an architectural specification, I would like to think that implementors will build it as I have so specified. But in the real world we know that this never happens as competing agendas, egos, and strategies get in the way.
What is it exactly that architects do anyway? And what are some identifiable aspects of good architectures? I will answer these questions in a few lines, but first let's set the architectural context:
REQUIREMENTS are concerned with the determination of the information, processing, and the characteristics of that information and processing needed by the user(s) of the product
ARCHITECTURE is concerned with the selection of HW/SW architectural elements, their interactions, and the constraints on those elements and their interactions necessary to provide a framework in which to satisfy the requirements and serve as a basis for the design
DESIGN is concerned with the modularization and detailed interfaces of the HW/SW design elements, their algorithms, signals, and procedures, and the data types needed to support the architecture and to satisfy the requirements; and
IMPLEMENTATION is concerned with the representations of the algorithms, signals, and data types that satisfy the design, architecture, and requirements
So, we can define architecting formally as the process by which user requirements, having been translated into technical requirements, are embodied into a synergistic collection of physical and logical entities, and their interfaces that exhibit…
wholeness, reflecting the primacy of the architecture as a whole over its elements
hierarchy, reflecting not only the potential for successive decompositions, but also the role of a given architecture as a subsystem within a larger framework; and
relativity, reflecting the inadequacy of any single delineation of an architecture and the consequent necessity of resorting to classes of descriptions, any one of which can capture only certain aspects of the wholeness and hierarchy of the system.
Given all the above, we now answer the question, “What do architects do?”
Hint Number 1:
By inspection, find the roots of the following polynomial:
(Equation 1) X^4 - 9x^3 + 27x^2 - 31x + 12
Hint Number 2:
By inspection, find the roots of the following:
(x - 1)^2 (x - 3) (x - 4)
Hint Number 3:
Finding the roots of the previous equation was not easy until we eliminated the accidental complexity by factoring, thereby leaving only the essential complexity
X^4 - 9x^3 + 27x^2 - 31x + 12 = (x - 1)^2 (x - 3) (x - 4)
The answer, then, is that architects factor complexity.
And what is a “good” architecture? Good architectures have optimum essential complexity, minimum accidental complexity, and exhibit a conceptual integrity that is normally visible by inspection.
Conceptual integrity means that:
- The design reflects one set of ideas: a single philosophy
- Systems that have it are simple and straightforward
- Springs forth from a very small number of resonant minds
- Requires a chief architect to control the concepts
- Facilitates parallel architectural and implementation activities
- Nevertheless, vigilance by the architect is required once implementation has begun
Thanks for staying with me this far. Now for the big finish. Here are
Reilly's Architecting Truths:
- An architecture must possess conceptual integrity - appear to be the product of one mind and written by one hand.
- It must be implementable in a cost-effective manner. Distrust an architecture that has not been implemented. Distrust an architect that has not been an implementor. Be wary of an architecture that has not been used by people other than its architect and implementers.
- It is better for an architecture to be wrong than to be imprecise; the former can be fixed, the latter may never be spotted. Specifications should be written in the singular, not plural.
- Each interface function should be as general as possible while also consistent with efficient implementation. For example, it should be independent of representation media. E.g., it should provide general mechanisms from which alternative policies can be implemented.
- An interface should hide information - it must reveal the "what" a system does but never the "how" the system does it.
- Partitioning is done so that each interface is "skinny" - it requires minimum information to be exchanged across it.
- Essential complexity should be managed in those components that are of concern to the fewest people possible.
- A strong match between functional and physical structures should be present.
- Functional aggregation should result in a partitioning of elements that will have very low external complexity and very high internal complexity.
- Distributed systems should have slowly changing global activity and rapidly changing local activity.
- Performance of partitioned elements should be insensitive to unknown or uncontrollable external influences.
- Impacts of extreme pathological behavior of a partitioned element to another element should be minimal.
- Deviations in product cost, schedule, technology, customer needs, and/or performance should have minimal impact upon the design of the architecture. That is, the degree to which developers must modify applications or the architecture itself to meet unforseen external changes is a measure of hidden accidental complexity.
- The ratio of Upper Layer or Lower Layer primitives should be much less than unity. This is a strong indicator of minimized complexity across elements and a high degree of abstraction.
- The ability to debug new applications directly on a working system, without affecting customers using that system, is a strong measure of architectural goodness.
- Bad cooking can at least be thrown away, but bad architecture is much harder to dispose of. (Kevin Kahn, Intel Fellow)
If you call yourself an architect then I hope you agree with today’s post. If you do not, I would like to hear from you.
No comments:
Post a Comment