Dear Bob ...Enough already! You've written a lot recently about good architecture and bad kludges. We all know that good architecture is important and that kludges are bad. That doesn't help very much without some practical advice for CIOs who want to encourage the former and discourage the latter.What, exactly, should we be doing about it?- Architecturally inclinedDear Canted ...The two best steps you can take Dear Bob …Enough already! You’ve written a lot recently about good architecture and bad kludges. We all know that good architecture is important and that kludges are bad. That doesn’t help very much without some practical advice for CIOs who want to encourage the former and discourage the latter.What, exactly, should we be doing about it? – Architecturally inclinedDear Canted …The two best steps you can take (that I can think of right now, at least) are to (1) establish a core set of architectural principles, building an architecture review process into your applications methodologies; and (2) build code reviews into your applications and SQA (software quality assurance) methodologies as well. Architectural principles are the core set of design standards that define good architecture in your company. The key to their success is to ground them in the realities of your situation. That means that “eliminate data redundancy except in the keys and backups” is a valid principle if you build everything, but meaningless if you buy when you can and build when you have to (another candidate architectural principle, by the way).That’s because, if you buy applications, of necessity you’ll have the same data living in multiple applications, so you’ll need a different principle to guide developers then: “Manage redundancy by establishing which data repository is the source of truth for each category of information, and using data synchronization techniques to coordinate the other repositories that contain the redundant versions of the same data.” Or something – whataver is most appropriate for your company.Application methodologies should include an “architecture impact statement” created by the software designers that feeds an architectural design review that precedes coding. They should also include a final architectural review built into the SQA process prior to roll-out. The notion of having code reviews isn’t new, and I trust requires no additional explanation.The tricky part in all this is making sure the discipline of managing architecture doesn’t turn into a bureaucratic tangle. It can easily happen. The best solution I know is to rotate developers into and out of this responsibility, rather than to create a permanent organization that can easily become an ivory tower.– Bob Technology Industry