A lire sur: http://www.infoworld.com/t/enterprise-architecture/your-it-architecture-code-195292?source=IFWNLE_nlt_advice_2012-06-13
While the choice of words may seem a minor detail, the distinction tells the larger story. For those involved in enterprise technical architecture, the punchline may not be pretty. In many ways, we share a lot more characteristics with the bureaucrats who regulate buildings than those who create them.
[ Find out the 10 business skills every IT pro must master and beware the 9 warning signs of bad IT architecture. | Get expert advice about planning and implementing your BYOD strategy with InfoWorld's 29-page "Mobile and BYOD Deep Dive" PDF special report. | For more of Bob Lewis' continuing IT management wisdom, check out his Advice Line newsletter. ]
Waterfall vs. agile
In IT, waterfall development is our closest correspondence to real architecture. A building starts with a sketch, then drills down into floor plans and so on based on how it will be used. From there, it's designed even more deeply, until we have a complete set of blueprints that show the electrical, plumbing, HVAC, and wiring plans in enough detail that builders know exactly what has to go where. Waterfall development is pretty much the same thing, applied to software. (Any real architects reading this: Yes, I'm oversimplifying.)
Waterfall is the right way to create buildings. I experienced a home remodeling effort that was handled more like an agile project -- I don't recommend it.
Real architects are responsible for detail. Most enterprise technical architects I know consider detail to be someone else's problem. In that, they're wrong, though this doesn't mean waterfall is the way to go or that enterprise technical architecture's boundary is application development.
What it means is that while enterprise technical architects have no involvement in systems designs, they have a great deal to say about the rules to be followed in designing them, whether they're designed through waterfall or agile methodologies. The analogy to building codes is, by now, hackneyed, but its validity is still frequently obscured by the inappropriate use of "architecture" to refer to what is really the work of government regulators.
Can you blame the enterprise technical architects? Given the current insistence that government regulation is a horror visited on business victims, it's no wonder that the practitioners of a nongovernmental regulatory craft prefer nearly any other characterization.
What building codes teach ITThe reality is that the tangible product of enterprise technical architecture is entirely parallel to that of government regulators -- specifically, to those involved in building codes.
June 13, 2012
Enterprise technical architecture is a lot more about regulation than you might like to think
Follow @ITCatalysts When it comes to developing sound enterprise technical architecture, we probably should have chosen a different word. What we mean by "architecture" has too little in common with what real architects -- the people who design buildings, that is -- do.While the choice of words may seem a minor detail, the distinction tells the larger story. For those involved in enterprise technical architecture, the punchline may not be pretty. In many ways, we share a lot more characteristics with the bureaucrats who regulate buildings than those who create them.
[ Find out the 10 business skills every IT pro must master and beware the 9 warning signs of bad IT architecture. | Get expert advice about planning and implementing your BYOD strategy with InfoWorld's 29-page "Mobile and BYOD Deep Dive" PDF special report. | For more of Bob Lewis' continuing IT management wisdom, check out his Advice Line newsletter. ]
Waterfall vs. agile
In IT, waterfall development is our closest correspondence to real architecture. A building starts with a sketch, then drills down into floor plans and so on based on how it will be used. From there, it's designed even more deeply, until we have a complete set of blueprints that show the electrical, plumbing, HVAC, and wiring plans in enough detail that builders know exactly what has to go where. Waterfall development is pretty much the same thing, applied to software. (Any real architects reading this: Yes, I'm oversimplifying.)
Waterfall is the right way to create buildings. I experienced a home remodeling effort that was handled more like an agile project -- I don't recommend it.
Real architects are responsible for detail. Most enterprise technical architects I know consider detail to be someone else's problem. In that, they're wrong, though this doesn't mean waterfall is the way to go or that enterprise technical architecture's boundary is application development.
What it means is that while enterprise technical architects have no involvement in systems designs, they have a great deal to say about the rules to be followed in designing them, whether they're designed through waterfall or agile methodologies. The analogy to building codes is, by now, hackneyed, but its validity is still frequently obscured by the inappropriate use of "architecture" to refer to what is really the work of government regulators.
Can you blame the enterprise technical architects? Given the current insistence that government regulation is a horror visited on business victims, it's no wonder that the practitioners of a nongovernmental regulatory craft prefer nearly any other characterization.
What building codes teach ITThe reality is that the tangible product of enterprise technical architecture is entirely parallel to that of government regulators -- specifically, to those involved in building codes.
12
Aucun commentaire:
Enregistrer un commentaire