Monday, December 17, 2007
Enterprise Architecture and Paradigm Potpourri
Have you ever ran across folks when confronted with two distinct paradigms, attempt to combine them and glow that they are using a hybrid approach? Sometimes paradigm potpourri is a mental disorder...
In the same way enterprise architects attempt to govern software development by limiting the piling on of features on top of enterprise applications, we sometimes need to govern ourselves when it comes to paradigm adoption as we diminish the benefits of a pure approach. In software development, each additional feature will give one more options that may simplify certain aspects of the code, but because the different ways to do it grows with each feature, it is increasingly less likely that any new feature will make a significant difference. The same thing can be said about enterprise architecture.
When will we stand up and have enough courage to ask ourselves whether we should be pursuing SOA, BPM, ECM, CMMi, Six Sigma, IT outsourcing, Business Rules, ESB, etc strategies all at the same time? We are delusional to think that we are like the building trades where the focus is on enterprise architects creating building codes and handing out permits as part of governance. Of course, we never think about the fact that the building trade also has the notion of occupancy certificates which many of our systems fail miserably at.
If we are to take on so many initiatives at the same time, don't we need to stop for a moment and consider the learning curve of both producers and consumers of our grand strategies? Like a carpenter or plumber, the bigger your toolbox, the more you have to lug around...
| | View blog reactionsIn the same way enterprise architects attempt to govern software development by limiting the piling on of features on top of enterprise applications, we sometimes need to govern ourselves when it comes to paradigm adoption as we diminish the benefits of a pure approach. In software development, each additional feature will give one more options that may simplify certain aspects of the code, but because the different ways to do it grows with each feature, it is increasingly less likely that any new feature will make a significant difference. The same thing can be said about enterprise architecture.
When will we stand up and have enough courage to ask ourselves whether we should be pursuing SOA, BPM, ECM, CMMi, Six Sigma, IT outsourcing, Business Rules, ESB, etc strategies all at the same time? We are delusional to think that we are like the building trades where the focus is on enterprise architects creating building codes and handing out permits as part of governance. Of course, we never think about the fact that the building trade also has the notion of occupancy certificates which many of our systems fail miserably at.
If we are to take on so many initiatives at the same time, don't we need to stop for a moment and consider the learning curve of both producers and consumers of our grand strategies? Like a carpenter or plumber, the bigger your toolbox, the more you have to lug around...
