One of my friends and mentors, Bill Vass of Liquid Robotics, has consistently advised IT professionals to understand, respect and use the power of well formed IT architecture. Bill has often reminded me and others that architecture is design. If you have poor design, or if you have good design that is ignored, then the architecture is worthless or even counter productive. If you have good, actionable design that is focused on mission needs and used by enterprise decision-makers then IT is better able to deliver workable solutions. Bill also emphasizes that well done architecture begins with the end in mind.
That last point means, that before building your design you need to know what your mission requirements are. And you need a good relationship with your customers and how they serve the mission.
If there was ever any doubt of that, I’d like to point out a great example highlighted by Monty Python in a skit named… “Architect Sketch.” In it John Cleese plays an architect who seems to have created his design without an approved business architecture. The result is a design that does not meet the intended mission needs. (In the same sketch, Eric Idle, seems to have a design that reflects mission needs, but shows signs that it might not be executable).
The sketch is a great way to drive home many lessons in IT architecture, don’t you think? Here are a few that come to mind:
- IT customers should very clearly spell out the requirements that need solving (by the way, most are are not very good at this)
- IT architects must ensure they are designing to mission needs
- Sometimes poor technical designs are picked because they are the only thing that comes close to meeting the mission
- Sometimes designs are picked because of relationships
If you are a customer of IT is is your duty to describe requirements in clear, understandable ways so the IT architects have a chance of designing the right solution.
If you are an IT architect you have a duty to ensure you are designing things to meet mission needs. You don’t design something just because that is what you are good at (John Cleese’s character said “You see I mainly design slaughter houses.”). And if you design something that customers reject in design review, don’t do a Cleese on them. Although he does have a way with words when it comes to pushing back on user concerns:
“Well, of course, this is just the sort of blinkered philistine pig-ignorance I’ve come to expect from you non-creative garbage. You sit there on your loathsome spotty behinds squeezing blackheads, not caring a tinker’s cuss for the struggling artist. You excrement, you whining hypocritical toadies with your colour TV sets and your Tony Jacklin golf clubs and your bleeding masonic secret handshakes.”
(That kind of in-your-face interaction with customers is probably not conducive to a productive, healthy, long-term relationship with your customers).
Which raises another point this skit humorously highlights. In the end, the customer choose the poor technical design over the good one because it was closer to meeting the mission, and because the architect had a relationship with the customer, as evidenced by the well executed masonic secret handshake.
Lesson overall: Good enterprise IT is always about people and the mission. When enterprise IT is designed without a good understanding of the mission, disaster can result.