Lessons Learned from Architecture Reviews
Last year I talked about lessons learned from architecture reviews at JAOO 2007 and Markus Voelter from Software Engineering radio interviewed me. You can listen to our conversation.
I've experienced both sides of reviewing. Early in my engineering career I presented the design of a universal linker to an external reviewer. I was scared to death that the reviewer would pick apart my design. I was relieved when my design was blessed, but annoyed when the reviewer doubted my ability to deliver on time. (I delivered, but in hindsight I could see why he and my management doubted me--as a new engineer I was working solo on a critical project...I just didn't know what I couldn't do).
These days, complex IT systems are rarely understood by a single engineer or architect. Teams come together to create complex software systems. Technical challenges can be enormous and the "tricky bits" involve the subtle interplay of business and technical design decisions. The focus is on achieving overall business objectives, not the optimal design of a single component. Yet poorly designed interfaces, sluggishly performing services, or crappily constructed components can cause enormous grief. Design still matters.
I've experienced both sides of reviewing. Early in my engineering career I presented the design of a universal linker to an external reviewer. I was scared to death that the reviewer would pick apart my design. I was relieved when my design was blessed, but annoyed when the reviewer doubted my ability to deliver on time. (I delivered, but in hindsight I could see why he and my management doubted me--as a new engineer I was working solo on a critical project...I just didn't know what I couldn't do).
These days, complex IT systems are rarely understood by a single engineer or architect. Teams come together to create complex software systems. Technical challenges can be enormous and the "tricky bits" involve the subtle interplay of business and technical design decisions. The focus is on achieving overall business objectives, not the optimal design of a single component. Yet poorly designed interfaces, sluggishly performing services, or crappily constructed components can cause enormous grief. Design still matters.
posted by Rebecca Wirfs-Brock at
10:18 AM
2 Comments:
I have experienced a propensity from inexperienced project managers to divide-and-conquer in a heavy-handed fashion. The result in one financial services project I worked on 5 years ago was an artificial separation of the architecture and the teams which precluded sensible domain-level modelling and design. Complexity and uncertainty scares people, particularly those looking for a decomposition 'handle' to exert clumsy top-down control. Unfortunately the project failed, but it suffered from multiple pathologies. System designers must stand firm in the face of real business pressures until such time as they are satisfied that a viable and sound solution architecture has been put in place. Diving straight into package and then class-level decompositions will at best introduce risk and at worst lead to system-level fialures.
"The focus is on achieving overall business objectives, not the optimal design of a single component. Yet poorly designed interfaces, sluggishly performing services, or crappily constructed components can cause enormous grief. Design still matters."
I just wanted to say what a great comment! Very true!
Post a Comment
Subscribe to Post Comments [Atom]
<< Home