My favorite posession in high school was my drafting board. Yep… I was geek, even then. I was going to be the next Frank Lloyd Wright (or at least, I wanted to die trying). I fell in love with Architecture in a high-school drafting class and was hooked. I had notebook after notebook filled with sketches of floor plans and perspective drawings. The year was 1979. Good times.
So when I was talking to a fellow architect recently about one of our team meetings, I realized that I had a good thing back then, something that I don’t have today in my current incarnation of ‘Architect.’ When I created a set of blueprints for a house, it was accurate. I was a careful person because I had to be.
You see, the goal of a blueprint is that I can give a package of drawings to a builder and literally walk away. The house that he or she builds should (if I did my job well) come out looking A LOT like the picture on the paper. Not identical, mind you. There will be minor gaps, and the builder may have to make a compromise or two, but for the most part, I should be able to walk through the finished house and find everything pretty much where I put it on paper.
If the builder had a question about the amount of carpet to order for a room, for instance, they could whip out a ruler and measure the size of the room on the blueprint. If the scale was 1/2″, and the room, on paper, measured out to 6 inches wide, the builder KNEW he could order 12 feet of carpet. (Of course, he would order 13 feet… just in case).
Point is that the diagram was so accurate that the builder would not have to ask me for anything that he could get by whipping out a ruler and measuring the drawing on the paper.
Why don’t we have this kind of accuracy in our architectural models?
Is that something we should strive for? This is not an MDA question. This is an accuracy question.
In your opinion, gentle reader, what level of accuracy should the architectural model go to?
PingBack from http://msdnrss.thecoderblogs.com/2007/08/16/put-a-ruler-to-the-blueprint-is-it-useful/
PingBack from http://msdnrss.thecoderblogs.com/2007/08/16/put-a-ruler-to-the-blueprint-is-it-useful/
PingBack from http://msdnrss.thecoderblogs.com/2007/08/16/put-a-ruler-to-the-blueprint-is-it-useful/
My intuitive answer is that it depends on the level of uncertainty and possibility of disruptions/surprises coming from the environment etc.
Even in the case of building a house I would say that there is a fair amount of uncertainty and surprises that you have to be prepared for.
The more uncertainty there is the less architectural detail can be motivated.
But there are cases when blueprints are absolutely accurate – and must be. I’m thinking of computer architecure (hardware, circuits, motherboards etc).
In the case of systems architecture however we, unfortunately?, have to be prepared for a _lot_ of uncertainty and surprises. Virtually any requirement could be misinterpreted, added, obsolete, etc.
In stead systems architecture have to rely more on principles, strategies, standards, best practices, communication, agility and more.
Only as accurate as the model needs to be in order to effectively communicate to the people reading the model. Any accuracy past the "effective communication tool" bar has diminishing returns. Of course, measuring that "effective communication" level will vary based on the person you are creating it for.
That would be my general answer. Another possibility might be:
As far as is needed to accurately ascertain or predict the amount and types of resources needed when reifying the model. Resources may include people, man hours, servers, bandwidth, etc.
Of course, edge conditions (such as systems with low tolerance for latency, or safety-critical systems) would probably be different.
Two great responses. Cool.
One of the things we do (in IT) is describe systems that are built by developers in India and China. A lot of our IT development happens in India and China!
Both of you seemed to assume that there is diminishing return that comes from describing details, but if I hand ‘plans’ to a builder and walk away, I know the house will look good, be solid, pass code, and give me a good reputation.
Right now, if I hand models to developers across the ocean, it is the same as ‘walking away’ because I’m 12 hours delayed (at best) in answering questions.
In corporations in America, this may not be typical, but it is fairly common. I’d guess that other countries (Europe, perhaps) may have some similar economics.
So, to Evan’s point, "as accurate as we need to be" has a different meaning when the need is great.
I also want a fairly standard amount of accuracy. A builder does not look at blueprints and ask "Did Joe do these? Because Joe doesn’t pay attention to structural members, so I have to add those in when looking at Joe’s plans. Bob, on the other hand…"
Maybe DSLs and Software Factories ARE the same thing as an accurate blueprint. Hmmmm…
Hi Nick,
My wife is a building architect and we had an interesting dialog a couple of months ago comparing Software Architecture to Building Architecture as a response to a blog entry comparing the two.
The conversation was captured in this blog from Robin Mestre found here http://blogs.msdn.com/robinm/archive/2007/03/26/if-building-architects-had-to-work-like-it-architects.aspx
The result, as you probably imagine, was that Software Architecture is VERY immature in comparison.
The reason I’m bringing this up, is that it’s hard for me to offer an answer to your question because the differences between the mature standards and techniques in the Building Industry are so far ahead of the standards and techniques in the Software Industry I’m not sure where to begin.
Anyway, I like the challenge you present. It’s time (or past time if you follow Pat Helland) to seriously look at how we in the Software Industry we can improve our maturity to reach the level of sophistication our brothers in the Building Industry have acheived.
@Nick,
The often used "builder" analogy also puts a bit of context on your question. We know that process is serial in nature (first blueprints, then construction). We know that the architect is typically the skilled (highly paid/highly trained) labor. We know that the construction work is performed by low skilled (low paid) labor. Both are specialized in skill. It also assumes that the knowledge of the future is somewhat certain (thus it is a predictive process). Building a bridge or a house is pretty predictive (although a 10 yr construction project probably exhibits some unpredictability).
If you change the above assumptions, an architectural model can be a completely different beast.
If you rip out the serial process phases (and mash them together), the blueprint becomes more of a "snapshot in time". This usually works well where there the team is not highly specialized. The skill level for each person is raised (and the team is flat instead of specialized). This approach works well where the future is uncertain (and likely to change). Thus the adaptive vs predictive approach. The model reflects the thing (think documentation) instead of the thing reflecting the model (think specification).
I was going to leave a comment, but Gabriel Morgan beat me to it. In defense of the software industry, building architects have a 5000+ year head start on us.
If we want to catch up, it would behoove us to try to learn from the successes and failures in other fields of endeavor instead of always assuming that the everything we need to know has happened in the last 30 years (and I’m being generous, I know a lot of developers and architects who think that any knowledge more than 2 or 3 years old is irrelevant to their work).
I wish we could model software architecture as discretely as building architecture, but as far as my years of experience have made clear, it is that we can’t.
There are distinct differences between building architecture and software architecture. And one of the problems we have created for ourselves over the years is that we have continually used the building architecture metaphor to help articulate and illustrate software architecture.
First, we still haven’t reached the point of having standardized discrete elements or if you prefer building blocks that are consistent in structure and function that we can employ. Compare this with the components used on a building. A two-by-four is a two-by-four and we continually use it in the framing of a house, no matter size or type.
Does this imply that we may never get there with software, no, but if history is a lesson, we still have a ways to go. We keep wishing that building software is about interchangeable widgets, but so far it isn’t, at least not yet.
Second, as stated in other responses the development of software is continually fraught with uncertainty and mirrors the definition of the uncertainty principle. In my view building software is more art than science.
The other challenge to this equation is having a concrete understanding and agreement as to what to build. This problem also affects the building of a house, just ask anyone who bought a semi or custom home and ask them if things worked out exactly as they planned.
Again with software architecture, understanding what you are trying to structure and build for business is dynamic in nature and what you laid out day one needs to continually adapt to changes based on business events, technology and or industry changes, new requirements, or competitive pressures.
In the building trades yes technology has caused changes in materials but not necessarily in the fundamentals of how you build a house. Again, we are still using two-by-fours. Whereas in software architecture the fundamentals, what is a widget and what is the right use and size of the widget, are still in motion.
While I agree that the maturity level is not yet present, I would hate for "its so hard" to prevent us from trying. The building architect uses several perspectives to present diagrams of different types, and so no single panacea diagram is required. We can use some standards IEE 7-Layers to differentiate Apps from Hardware from Networks, we can use Jackson Structured Diagrams to present coded segments and relationships between them. We have multiple opportunities to agree to diagramming standards, but that is only half (the easy half), the other advantage that Building Architects have is the general agreement about the semantic components of the drawings. What are meant by the things represented on the digrams, here IT differs widely from construction. And rarely do a writer and a reader mean the same thing in IT. While I agree with your plea…it is not a simple fix, and it will likely take us 10-15 years to get it right. But lets not let us from making a start, like you I would like to be able to pick up drawings and discern meaning from them that is well defined, easily understood, and consistently applied.
Cheers
Gary Scott
@Bob,
Ultimately, you are describing the effects that Moore’s law (and friends) has had on us as software professionals. If the construction industry changed at the pace that software changed, I think there would be mass confusion (or at least, lots of "legacy buildings".)
Combine that with the changing software needs of today’s business and you have a mess on your hands. In terms of business need, office facilities don’t change that much (especially when compared to software requirements). Sure they often have the need to scale capacity (sound familiar?), but fundamentally, they are stable in what they need. Heck, they will often meet the needs of the next business after the original is long gone.
I like the idea of having as accurate a blueprint as time can afford. Unfortunately the blueprint is often the lowest common demonator of the attitudes, experience, skill and knowledge of architects involved.
I once had an architect from a big French Telecommunications company ask me what UML was when I suggested we use it for documenting our work and thinking. As the conversation progressed and I suggested he should learn UML he gave a bit of a snort and nothing more came of it. Except, we then spent many minutes and hours getting ourselves on the same page every time we had to meet.
I’ve found blueprints work well when the team is committed to improving its common language, refining this as the project(s) progress(es) and dumping stuff that doesn’t work. So accuracy is good, but in my experience it’s only as good as the consensus. And most often, it’s an uphill battle. Like making my kids eat their greens.
@All
Great responses, all. Thanks to Gabriel to pointing out a blog that provides insight in the experience of a working architect. Makes a difference to get a real-world touchpoint.
The one thing that struck me from reading the blog entry that Gabriel provided was that the accuracy of the blueprint ENABLED the highly skilled architect to perform design functions, while the highly skilled builder could employ sub-contractors with specialized skills to construct specific parts of the house.
In other words, in a model where the drawings are very accurate, the differentiation of skills emerged as a major part of the ‘business culture.’ In our world of poor accuracy, we rely on generalists. Given that over 50% of our projects fail, perhaps we have something to learn.
To JohnCJ who points out that Architects have a 5000 year head start on us, I would say that the art of building a modern home is not 5000 years old, and that only in the industrial age did we start to see standard parts. And to Bob who points out that a 2×4 is still a 2×4, he should be aware that the modern 2×4 didn’t emerge until the turn of the 20th century.
No, Architecture does not have a 5,000 year head start on us. There are clearly cases of excellent design that have survived the ages, but the majority of the science and engineering that we rely upon today are fairly recent, as are the innovations that define our lives (like electricity and indoor plumbing). I’d say that the modern practice of architecture has about 300 years on us.
Now, add to the fact that the first 250 years of modern architecture took place before the Internet, in an environment where skills were learned once, in college, and then practiced for long periods of time. That is quite different from our age where we expect, of ourselves, the same level of professionalism as a building architect, and we have a possibility that is more aligned with Gary’s timeline of 10-15 years.
I’d like to see that level of maturity by the time I retire in another two decades. That way, by the time I am done with this industry, we will have progressed as far in 85 years and the building industry did in 300.
I believe it can be done. After all, we have examples to work from, and smart people to work with.
Accurate models, and standardized parts. That’s clearly the right way to go.
@Nick,
Just remember that some business can’t wait for a year and a half+ development project to complete. The all or nothing "builder" approach forces up-front stability in the project. It also radically alters the financial picture of the project (in terms of when the investment reaches payoff and investment ROI).
While the predictive approach may work well for a project like Sql Server, my experience tells me that it’s not one size fits all. My stakeholders (and their shareholders) would rather start recouping investment (and getting new business) with something that works in a month or two, even if it isn’t the polished/finished product. I personally haven’t seen any "big specification here, walk away, build in india" projects. Maybe they are more common in Very Large Enterprises (my current client only has a few hundred developers on staff and the offshore outsourcing isn’t the low skilled laborers described in this conversation). The real waste shows up when we try and force the predictive approach on an adaptive project. It’s important to see both and know the strenghts/weaknesses of each and apply intelligently to the given context (which ultimately shapes our definition of architectural model).
To be fair to us as software professionals, I think we would have to compare most development projects to something like building The Guggenheim (a project where everything’s completely custom). The difference between two random buildings is not nearly as significant as the difference between two random software projects.
And what about those guys doing renovations? What happens to a building project when the size of renovations is several times the original scope of the project? 😉
@Evan,
Standardized parts is the key to shortening the amount of time. This is the goal of SOA+BPM in my opinion: produce standardized parts that allow developers to quickly build the things that you need.
Have you noticed that most of the folks on this discussion have had very very little contact with building architects (except Gabriel… he’s married to an Architect ;-).
Yet we all live in buildings and work in buildings and shop in buildings. So many buildings… so few architects. Why is that?
Because the amount of time that an architect is needed is very comparatively small. What makes it go fast is the accuracy and regularity of the models and the ability to build most of the building from readily available parts.
By speeding up the process of design and delivery using standardized parts, and through the magic of computing that allows us to use arbitrarily large components, we have the capability of delivering working code fairly quickly… that’s the goal.
It’s fantasy, of course. Reality is that there will need to be people to stitch it together and the larger the reusable component, the less reusable it is. However, we CAN speed up the delivery by allowing the composition of systems from standardized parts.
That allows us to deliver a partial answer quickly and get feedback. The technology supports the notion of adaptive projects, perhaps even better than traditional "roll you own Guggenheim Museum" methods.
Note that there is no Functional Spec in building architecture. Diagrams define the critter. That speeds things up considerably. In a smaller shop without remote developers, the turnaround time would be speeded up remarkably.
Between these points, a highly accurate diagram taking advantage of reusable parts will produce partial systems in the scope of a single sprint, allowing business feedback.
I’m an agilist. I want to use the best tools possible. I don’t accept the notion that a tool cannot be used in an agile way until I try it.
Nice post. Nice series of posts in fact.
This one raises a few questions for me.
The first question is around accuracy. Reading through the comments I think a lot of people are confusing accuracy with detail. Any artifact should be produced to the highest degree of accuracy time and resources allow. The level of detail required of any artifact depends on its purpose and intended audience.
The second question regards design. This is a question of responsibility and accountability. Who is responsible for what aspect of the solution? Is the architect responsible for all aspects of the design or just the structural aspects of components and interfaces? Who is responsible for the design of implementation classes, the programmer? the team lead? the architect? The assignment of responsibility and accountability is critical to determing the type and level of detail of the information flows.
The third question is around communication. The temporal and geographic aspects of communication are critical to determining the type and detail of communication required to successfully transfer information. Where parties to the communication are separated both in distance and time more formal communication artifacts with greater levels of detail may well be required than the face-to-face conversations often found in agile environments.
At the end of the day it comes down to appropriateness. There is no one size fits all. Accuracy should always be as high as possible. The level of detail is that which is sufficient to communicate all that needs to be communicated at that point in time over that distance to those requiring the information. Simple to say. Hard to do.
@Ian,
Excellent observation. I agree with all of your assertions.
You pose questions, yet really I view them as criteria for deciding what level of accuracy and detail are appropriate for a particular project. That was your intent,correct?
As for responsibility in design: no one-size answer there either. It depends on project resources and time/distance/capability of the staff, just as you point out. It also depends on the scale of the project.
If I’m doing a large distributed system, I may describe a very high level ‘site plan’ with a great deal of detail about the infrastructure, and then allow individual components to be designed by other architects within the (many) coordinating teams.
Thank You for your excellent observations.
Nick,
Interesting – a couple of comments back you said "I’m an agilist". This, for me, is the root of why software architecture is different – why do we need to be agile?.
To give a building architect a similar experience to a software architect, you’d have to do this:
. repeal all building regulations
. repeal all zoning/siting regulations
. allow competitors to target the project’s requirements e.g. buy up the concrete works and change the blend so my design will no longer work
. make the project brief something like "build any structure anywhere using any construction method, so long as it increases my sales or lowers my costs"
In this environment, project failure rate would skyrocket, long planning cycles and solid blueprints would vanish, and building architects would be going to conferences to talk about how to be more agile!
On the other hand, if you gave a software architect a brief specifying the technology platform, the deployment mechanisms, the precise functionality required, and full access to a couple of thousand other systems that use various approaches to do exactly the same thing, I think you’d find your architect could hand you back a pretty solid blueprint in short order. This is in fact exactly what happens with things like avionics and critical embedded systems, most of which fall over about as often as the Great Pyramids.
I don’t want to trivialize what building architects do, but their environment is simpler, better understood (at the business level), and has vastly fewer degrees of freedom. Outside of a few specialized domains, the market for software has consistently chosen functionality over reliability and adaptability over predictability. Which is why we need to be agile, and the users are also kept on their toes dodging falling bricks.
@Jaime,
I guess I’m not sure of your point: should we be more agile because the market is immature, or should we try to make the market more mature so that we don’t need to be agile anymore? Or both?
For me: both. We need to be agile. However, rather than simply adapting to the nuttiness, we can also push back to create structures and mature frameworks so that we can quickly solve the needs without sacrificing quality.
I disagree that the market for software has consistently chosen functionality over reliability and adaptability over predictability. If that were the case, Unix would never have come on the scene in the server market. The "selling point" that drives Unix is not the software cost. It is the notion that it is more reliable or secure (and therefore more predictable).
The market has dynamics that certainly place a value on providing at least the ‘minimum’ functionality over a partial but reliable solution. On the other hand, if multiple products meet the minimum bar, then adding features will not trump reliability or predictability. Adding XML to SQL would have meant nothing if that tool didn’t provide reliable and predictable performance in managing data.
So let’s not kid ourselves. Agility is necessary now because our field is still young. We cannot engineer a quality solution in a reasonable period of time. But our current Agile methods are first and foremost a coping mechanism. We need to cope with our inability to quickly engineer a solution.
As soon as we can speed up engineering, then Agile developers will be the first people to use ‘quick engineering’ to replace ‘quick craftsmanship.’ Agilists are the advance guard of excellence in our field.
I intend to help speed up engineering by managing complexity and evangelizing the use of an appropriate level of accuracy and consistency in our work.
And when that happens, I’m sure the agilists will lead the way to mass adoption.
I have put some own thougts on this subjects on my own blog.
Love your analogy. I believe that how accurate the model needs to be depends upon the company implementing. Small companies have different calls to action and drivers than larger ones. Public companies have greater compliance concerns than private ones. Etc…
But, I will share an analogy that I use in my mind, and in my daily evangelising of the topic. That of Apollo 13.
Too young to watch the news live, I have to settle for the movie.
The amazing thing to me was that they could take their test bed, and (quickly) know exactly how much voltage each item used, and then tell the astronauts what they could turn on, and in what order, to have the minimum spaceship necessary to make it home.
There are a million reasons why it’s both unreasonable and impractical to deliver this level of accuracy when designing a SOA, but I see no reason why it can’t be the objective.
@David,
Your analogy sounds compelling, but I’m not sure I understand the point.
Are you asking that our level of meta-data about our systems be so good that we can emulate the system’s behavior and thereby create a virtual test environment?
Can you post a reply or blog something to go into more detail?
The kind of accuracy you describe in traditional architecture is about quantity. The costs of a building are largely determined by the physical dimensions. (The cost of the carpet depends on the floor area.) So the first person who looks at the blueprint is not the builder but the quantity surveyor. The blueprint has to be good enough to enable reasonably accurate cost estimation.
We don’t usually do that in IT. There is no How-Many/How-Much column in the Zachman framework. You can’t work out quantities from a UML diagram. In a pre-SOA world, we thought cost estimation was largely about counting the number of components to be constructed (simple, medium, complex) and putting them into a time/effort formula. But this approach to cost-estimation is increasingly irrelevant to SOA.
If you are only building a garden shed then you don’t need a professional architect or surveyor. If you are building a tower block then you certainly do. The people who are doing serious architecture in an SOA world are those operating at internet scale – for example designing Skype so that it doesn’t fall over on Patch Tuesday.
Hi Richard,
To validate what I heard, let me tell you what I thought you said.
You said:
a) Accuracy is useful primarily for measurement
b) We don’t measure.
You didn’t complete the thought. Is the implication that we don’t need accuracy, or that we should start measuring? Both conclusions can be easily drawn from those statements. Which did you intend?
I would also challenge the first point. It is true that building architecture produces accurate diagrams that allow good estimation, but they allow lots of things. Good estimation is just one. The biggest thing they allow is consistent structural integrity. In computing, I’d say that accuracy provides the opportunity to deliver high quality systems. Measurement is not the high-order bit.
You also said:
c) Only big projects need accuracy.
I agree that only large projects need accuracy, but I’d redefine the bar of ‘large’ to say "any project that delivers an enterprise service". No garden shed but no office tower either.
Hopefully, over time, we can deliver fewer enterprise services because (a) we’ve built most of the ones we need, and (b) we can purchase prebuilt enterprise services either as a provisioned service or as part of a package.
Right now, that is only a dream.
Firstly, let me affirm that I think measurement (in the broadest sense) is a good idea.
I am not sure I know what accuracy means except in terms of measurement. How can we reason about things like "structural integrity" and "quality" without some form of measurement? In engineering, we don’t generally expect perfect integrity or perfect quality (which is usually either physically impossible or economically non-viable); we look for arguments of the form "X produces greater integrity/quality than Y" – where X/Y is some choice of material or technique or pattern or whatever. So there are implicit metrics running through all branches of engineering. Software engineering just isn’t very good (and should be much better) at managing these metrics and making them explicit. As a result, we don’t always see software engineers delivering the maximum integrity and quality for the minimum cost and effort.
So when I’m talking about measurement, I’m certainly not only interested in cost estimation and other project management stuff. I think architects should be thinking about things like the amount of complexity, the degree of coupling, the scale of integration, and you certainly can’t read these quantities straight from a UML diagram.
Of course a building blueprint doesn’t tell you everything you need either. If you are designing an airport, the blueprint will show how much flooring you need, but will not show whether there is enough space for the passengers to queue for passport control. If you are designing a tower block, you have to have some way of working out how many lifts to put in. In software engineering this kind of stuff is dismissed as non-functional requirements.
All engineering involves estimation. "is this bridge going to fall down" is an estimate.
In a traditional waterfall development, many people thought it was a good idea to address the functional requirements first (logical design), and then tweak the design (physical design) until you satisfied the non-functional requirements as well. But when you are composing solutions from prebuilt enterprise services, this approach just doesn’t wash. Indeed, it may now be the other way around: if a service assembly fails some functional requirement, you may be able to plug/mash in some additional service to fill the gap; but if it fails the non-functional requirements you may have to throw the whole thing away and start again.
Finally, I don’t say only big projects need accuracy. If a government builds a tiny service to be used by the entire population, a small project might have a massive impact. A garden shed may not need a professional architect: that’s not because a garden shed doesn’t need accuracy, but because an amateur builder can work out the quantities accurately enough herself.
@Richard,
Thank you for the clarification. I can see that we agree on the need for measurement. We also agree that accuracy can be expressed in terms of measurement (hence my ‘whip out a ruler’ analogy). In my mind, accuracy is a quality that can be rephrased as "measurability."
On the other hand, the benefits of accuracy exceed the act of measurement. That is my point.
You are right that, from the UML diagram, you cannot measure simplicity, any more than from a blueprint, can you *measure* structural integrity. Structural engineers often have to submit additional documentation, along with the blueprints, in order for a city inspector to allow a house to be extended, for example.
My statement was that blueprints offered CONSISTENT structural integrity and other qualities. I can provide blueprints and actually, physically, walk away and a building will emerge that, if they stuck to the plans, looks and behaves *very* close to what I drew.
And if the plans are used in another location by a different builder, that attempt would produce another *very* similar building. Both would have similar levels of structural integrity.
It is also entirely possible that one of my two fictional houses would pass local building codes while the other would not. A house built for a snowy region may be entirely inappropriate for a region that gets hurricanes.
However, the ability of a building inspector to look at a blueprint and make governance decisions, and the ability of a builder to look at a blueprint and make staffing and purchase decisions, and the ability of a sub contractor to look at a blueprint and take specific measurement or clarify intent, all of these abilities comes from accuracy. Each may actually measure the drawing. However, the measuring serves different purposes.
And that is why accuracy is important: it allows independent decision making and creates a consistent expression from which many houses can be quickly and consistently built.
Wouldn’t you like to build software quickly, and consistently, with behavior that can be predicted from the specifications?