Sunday, September 02, 2007
Enterprise Architecture and Why Do Things Fail...
Many enterprises resort to adopting the latest hyped industry strategy (aka CMMi, PMIBOK, TOGAF, etc) because they make many mistakes. Why is that? How is that they are so bad at our jobs that we fail so often? The funny thing is if they were more thoughtful, they can't in all honesty blame the methodology or the tools, but people do rise to the occasion...
So, lets enumerate why things fail:
Awhile back, James Tarbell commented on Why architects may be better than engineers but hasn't yet discussed why there is a knowledge crisis in IT. It's not just that people make mistakes, after all we are just silly little human creatures who periodically make mistakes. The enumeration of failure is trivially true and reflects a certain lack of depth of thought to assert all that is required to be truly competent. We are talking about systematic failure whose reach into every part of the enterprise is truly breathtaking and may have no parallel in any other profession.
Maybe we fail not because we need a new methodology but we fail because we are focused on methodologies and not competencies. A mistake within a major IT system means that code has to change.This is methodology-independent. Well-built code, regardless of methodology, should be equally easy/hard to change. I'm not aware of any methodology that requires perfection, that says don't test, that says spread duplicate code everywhere, or that says spend three years developing useless code. Developers may do this, but that's a lack of skill on their part. Focusing on the latest methodologies simply isn't required but focusing on making folks competent is.
Some of the latest trends within IT is the notion of power vendors and strategies around rationalization. Should we ever ask ourselves what does it mean to remove tools that benefit individual craftsman within our enterprise? What would happen if engineers were asked to build buildings like we're asked to write software? Limited budget, political restrictions on tools, short schedules, things that have not really been done before, and requirements changing on the fly. If you had to build a bridge in such an environment, it would fall...
| | View blog reactionsSo, lets enumerate why things fail:
- Incomplete knowledge:We often make decisions on subjects where we don't know all the relevant facts
- Poor communication:People don't always share all necessary knowledge with decision makers
- Changing conditions:A decision based upon today's information may turn out to be wrong tomorrow
- Pressure:People often make mistakes when they have to make decisions too quickly or when under stress
- Complexity:Systems can become so complicated that the developers cannot keep all the details straight. There are limits to the ability of people's minds to process information.
- Process Orientation: Enterprises have way too much focus on process which results in the savage creation of comprehensive documentation. No executive as the wisdom to understand that process is not a substitute for competence
Awhile back, James Tarbell commented on Why architects may be better than engineers but hasn't yet discussed why there is a knowledge crisis in IT. It's not just that people make mistakes, after all we are just silly little human creatures who periodically make mistakes. The enumeration of failure is trivially true and reflects a certain lack of depth of thought to assert all that is required to be truly competent. We are talking about systematic failure whose reach into every part of the enterprise is truly breathtaking and may have no parallel in any other profession.
Maybe we fail not because we need a new methodology but we fail because we are focused on methodologies and not competencies. A mistake within a major IT system means that code has to change.This is methodology-independent. Well-built code, regardless of methodology, should be equally easy/hard to change. I'm not aware of any methodology that requires perfection, that says don't test, that says spread duplicate code everywhere, or that says spend three years developing useless code. Developers may do this, but that's a lack of skill on their part. Focusing on the latest methodologies simply isn't required but focusing on making folks competent is.
Some of the latest trends within IT is the notion of power vendors and strategies around rationalization. Should we ever ask ourselves what does it mean to remove tools that benefit individual craftsman within our enterprise? What would happen if engineers were asked to build buildings like we're asked to write software? Limited budget, political restrictions on tools, short schedules, things that have not really been done before, and requirements changing on the fly. If you had to build a bridge in such an environment, it would fall...
