- Whether to mention a pregnancy in a job interview
- A possible meeting protocol
- What are an end-user's responsibilities?
- Another take on opening PCs, or not
- Getting some process going
- Selling a more open environment to management
- Running an effective meeting
- Licensing rules for virtual machines
- The ROI of metrics
- Legal challenges to virtual machines
June 28, 2006 | Comments: (0)
Making architecture happen
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 inclined
Dear 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
Posted by Bob Lewis on June 28, 2006 05:21 AM
RATE THIS ARTICLE:
-
- COMMENTS
I'm not sure it's strictly necessary to rotate developers in and out of architecture responsibility to prevent the role from becoming an ivory tower. I've served as Lead Architect for a number of large IT organizations, and the thing that "kept it real" in those cases was the fact the Architect was in the escalation path to be called in the middle of the night when things went wrong. When it's clear that part of your job is responsibility to see that things really get implemented and really work once they're in, you don't get the "ivory tower" syndrome.
Posted by: John Stork at June 28, 2006 12:01 PMRegarding developer rotation into and out of responsibility, one of the problems I have seen with this is lack of consistency of view.
Many times the developer (who knows he/she is in a rotation) will lean towards their favorite technolgies/approaches without regards for the past and the future. Without this looking back and planning forward, you will get a very inconsistent architectural view and subsequently create a very unstable presence in the space you are seeking to impact.
Posted by: T Page at June 29, 2006 08:41 AM|
Three books. Three ways to change the world, your life, or at least Bob Lewis' bank account. Leading IT: The Toughest Job in the World distills the world of IT leadership into eight learnable skills and gives you concrete, practical techniques for each one of them. Bare Bones Project Management: What you can't not do makes project management manageable, even for first-time project managers with no formal training in the discipline. ManagementSpeak: What managers say/What they mean … well, it won't help your career, and won't make you a better manager. Mostly, it will make you chuckle, guffaw, and maybe even chortle. Make friends - it's the perfect gift for anyone who has ever suffered through one of those meetings. Order your copies today! |
TOP STORIES
Hyperconnected users growingSteve Jobs to keynote WWDC
CSC settles kickbacks case
MS previews SMB software
What does HP-EDS really mean?
Mac Office 2008 SP1 released
HP buys EDS for $13.9 billion
Corporate IT spending slows
MS targets smartphone market
Sun to clarify JavaFX plan
ADDITIONAL RESOURCES
- Virtualization: A Step by Step Approach to Success
- Dialing up Agility with Business Transformation
- 5 Things You Need to Know About Storage Virtualization
- Is your smaller organization ready for High Availability?
- Is system maintenance doing more harm than good?
- Virtual Test Lab Automation: Manage development infrastructure
