It’s our responsibility as architects to make sure our work is implemented. We’ve been dealing a lot lately with questions about what makes a good architecture, what should be in an architecture, what’s the difference between a technical architecture and an information architecture, etc. But somewhere along the line we failed to emphasize perhaps one of the most important points in this business.
“It isn’t architecture until it’s built.” While that seems quite obvious when it’s stated, it’s the kind of observation that we almost need to have tattooed or at least put on our wall where we won’t forget it. It’s very easy to invest a
great deal of time in elegant designs and even plans. But until and unless the architecture gets implemented it isn’t anything at all; it’s just a picture. What does get implemented has an architecture. It may not be very good architecture. It may not lend itself to easy modification or upgrade or any of the many virtues that we desire in our “architected” solutions. But it is architecture.
So the implication for architects is that we need to dedicate whatever percent of our time is necessary to ensure that the work gets implemented. It’s really very binary. You belong to an architectural group. Maybe you are the only architect, or maybe there are five people in your group. In either case, if your work product results in a change to the information architecture the benefits can be substantial. Almost any architectural group could be justified by a 10 or 20% improvement. Frankly, in most shops a 50 to 90% improvement in many areas is possible. So on the one side, if a new architecture gets adopted at all it’s very likely to have a high payback. But the flip side is that a new architecture, no matter how elegant, is not worth anything if it’s not implemented and the company would be acting rationally if it terminated all the architects.
The implication is that as architects we need to determine the optimal blend between designing the “best architecture” and investing our time in the various messy and political activities that ensure that an architecture will get implemented. These range from working through governance procedures to making sure that management is clear about a vision to continually returning to the cost-benefit advantages, etc. The specifics are many, and varied. In many organizations you may be lucky enough that you may not have to invest a great deal of your time to get a new architecture and implement it. Perhaps you’re fortunate enough to have insightful leadership or a culture that is eager to embrace a new architecture. If that’s the case, you might get away with spending 10 or 20% of your time ensuring that your architecture is getting implemented and spend the vast majority on developing, designing and enhancing the architecture itself.
However, if you’re like many organizations, life for the architect will not be that easy. You might find it profitable to spend nearly half your time in activities that are meant to promote the adoption of the architecture. Certainly you should never pass up an opportunity to make a presentation or help goad a developer along. Indeed, the importance is so great that given an opportunity to present you would do well to invest disproportionately in the quality of the presentation, as a perfunctory presentation about the status or a particular technical standard is not likely to move developers or management to adopt it and you may need to return to the theme over and over again.
As someone once pointed out to me, in matters such as this the optimal amount of communication is to over communicate. The rule is when you’re absolutely certain that you’ve communicated an idea so many times, so thoroughly, and so exhaustively that it just is not possible that anyone could tolerate hearing it any more, that’s probably just about right. Experience says that when we think we’ve communicated something thoroughly and repeatedly three-fourths of the audience has still not internalized the message. People are busy and messages bounce off them and need to be repeated over and over and over. And you’ll find that each part of your audience will accept and internalize a message in a different way from a different presentation and at different rates. I’m continually amazed when I get some feedback with a particular stakeholder at some meeting. The coins finally drop and they become advocates for some position we’d taken. In some cases I’ve gone back and realized that we’ve presented it many times to that person and somehow finally one time it took. In other cases we realized that, in fact, we hadn’t presented already it to that individual. We thought we’d covered everyone but they weren’t in certain meetings or we repeat something so many times we think everybody must have heard it and, in fact, that’s not the case at all.
In closing, I’d like to recommend that every architect make a little plaque and put it near their desk that says: “It isn’t architecture until it’s built.” That might help you decide what you are going to do tomorrow morning when you come into work.
