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/
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 2x4 is still a 2x4, he should be aware that the modern 2x4 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.
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.