Tuesday, April 08, 2008
Enterprise Architecture and Fire Drills
There is an interesting behavior in large enterprises where the vast majority of enterprise architects cause numerous impacts to software development by their behavior...
A Fire Drill is a recurring scenario in many software development organizations. A project is initiated, but the staff delays design and development activities for several months while various technopolitical issues are resolved at a management level. Enterprise Architects then scramble to create Powerpoint while the problem at hand that actually caused the politics is in the rapid creation of working software.
At some level, enterprise architects create noise in order to avoid duplication of the portfolio. What ends up happening is that we let the components of our ecosystem that we like devolve by distracting others with politics such that they don't have time to do it right. It was once said by a wise developer Wait until management is desperate and they will accept anything you give them. When will we get smart enough to stop attempting to manage politics and start managing our portfolio?
Management prevents the development staff from making progress either by telling them to wait or by giving uncertain and conflicting directions. Perhaps most destructive are the externally generated changes in project direction that lead to rework and inhibit progress.
Because the entire project is pressed for time, compromises are willingly made in software quality and testing. In a perverse way, the emergency situation makes the job easier for some software developers as management will accept almost any software (or documentation) product with few questions if it is behind schedule. However, conscientious developers who deliver products before their deadlines are often compelled by management to rework their solutions.
Enterprise architects should be a condom of sorts to protect developers from the disease known as IT executive politics where they can focus on long term continual progress towards software delivery. Likewise, Enterprise Architects themselves also need to remind others that as much as 80% of all code in applications really isn't application-specific and therefore it is OK to proceed in that you won't really need to refactor as much as you think.
At some level, the mindset of rework comes because us enterprise architects haven't figured out how to get project managers to think in ways other than waterfall. Maybe it is because us enterprise architects haven't figured out how to sell Agile...
| | View blog reactionsA Fire Drill is a recurring scenario in many software development organizations. A project is initiated, but the staff delays design and development activities for several months while various technopolitical issues are resolved at a management level. Enterprise Architects then scramble to create Powerpoint while the problem at hand that actually caused the politics is in the rapid creation of working software.
At some level, enterprise architects create noise in order to avoid duplication of the portfolio. What ends up happening is that we let the components of our ecosystem that we like devolve by distracting others with politics such that they don't have time to do it right. It was once said by a wise developer Wait until management is desperate and they will accept anything you give them. When will we get smart enough to stop attempting to manage politics and start managing our portfolio?
Management prevents the development staff from making progress either by telling them to wait or by giving uncertain and conflicting directions. Perhaps most destructive are the externally generated changes in project direction that lead to rework and inhibit progress.
Because the entire project is pressed for time, compromises are willingly made in software quality and testing. In a perverse way, the emergency situation makes the job easier for some software developers as management will accept almost any software (or documentation) product with few questions if it is behind schedule. However, conscientious developers who deliver products before their deadlines are often compelled by management to rework their solutions.
Enterprise architects should be a condom of sorts to protect developers from the disease known as IT executive politics where they can focus on long term continual progress towards software delivery. Likewise, Enterprise Architects themselves also need to remind others that as much as 80% of all code in applications really isn't application-specific and therefore it is OK to proceed in that you won't really need to refactor as much as you think.
At some level, the mindset of rework comes because us enterprise architects haven't figured out how to get project managers to think in ways other than waterfall. Maybe it is because us enterprise architects haven't figured out how to sell Agile...
