Monday, January 03, 2011
Enterprise Architecture needs less maturity in order to be successful...
There are lots of definitions for enterprise architecture and over time, people attempt to further refine its mission by adding on additional overhead while avoiding pragmatic thinking...
The United States Government, Office of the CIO defines enterprise architecture as:
Should the success of enterprise architecture require lots of process weenies ensuring that everyone has their number two pencils sharpened and that all TPS cover sheets are completed? Wouldn't the sign of a more mature EA discipline have less process than more?
The army of expensive consultants who spend time creating pretty documentation in various forms in order to satisfy contract deliverable is also wasteful in that the documentation doesn't actually help improve anything. At best, you can record current state, but everyone knows that SNAFU rules.
So, if the goal of an enterprise is not to completely document every business process, every software system, and every database record that exists throughout the organization, but instead to find opportunities to use technology to add business value, then what have we been doing all these years?
If adding business value is not the ultimate goal of an enterprise architecture, then the energy put into creating that enterprise architecture has been badly misplaced.
Another travesty is when enterprise architecture borrows from the building trades. The notion of the city plan which governs what types of buildings will be permitted in a community is appropriate. However, your local town hall has realized that it is NOT in the business of drawing blueprints and this task is best left distributed. Imagine a city that included in its city plan a detailed blueprint for every building that would ever be built in the city. Such a plan would be extremely expensive to create, and, if it was ever completed, it would be inflexible and stifling.
My 2011 thinking says that in order for enterprise architecture to improve we need to stop the practice of defining and work tweaking and instead focus on values. The Agile Software Development community allows for people to practice Scrum, XP, Kanban or any other Agile method without concern. Regardless of the methodology chosen, they all encourage you to adopt an Agile mindset based on Agile values.
Now for a trick question, what are your organization's enterprise architecture values?
| | View blog reactionsThe United States Government, Office of the CIO defines enterprise architecture as:
- A strategic information asset base, which defines the business, the information necessary to operate the business, the technologies necessary to support the business operations, and the transitional processes necessary for implementing new technologies in response to the changing business needs.
- timeframes not counted in weeks or even months, but in years needed in order to perform a comprehensive analysis.
- The large number of highly placed internal staff that become absorbed by the process.
- The army of expensive consultants that are necessary in order to navigate through the complex methodologies.
Should the success of enterprise architecture require lots of process weenies ensuring that everyone has their number two pencils sharpened and that all TPS cover sheets are completed? Wouldn't the sign of a more mature EA discipline have less process than more?
The army of expensive consultants who spend time creating pretty documentation in various forms in order to satisfy contract deliverable is also wasteful in that the documentation doesn't actually help improve anything. At best, you can record current state, but everyone knows that SNAFU rules.
So, if the goal of an enterprise is not to completely document every business process, every software system, and every database record that exists throughout the organization, but instead to find opportunities to use technology to add business value, then what have we been doing all these years?
If adding business value is not the ultimate goal of an enterprise architecture, then the energy put into creating that enterprise architecture has been badly misplaced.
Another travesty is when enterprise architecture borrows from the building trades. The notion of the city plan which governs what types of buildings will be permitted in a community is appropriate. However, your local town hall has realized that it is NOT in the business of drawing blueprints and this task is best left distributed. Imagine a city that included in its city plan a detailed blueprint for every building that would ever be built in the city. Such a plan would be extremely expensive to create, and, if it was ever completed, it would be inflexible and stifling.
My 2011 thinking says that in order for enterprise architecture to improve we need to stop the practice of defining and work tweaking and instead focus on values. The Agile Software Development community allows for people to practice Scrum, XP, Kanban or any other Agile method without concern. Regardless of the methodology chosen, they all encourage you to adopt an Agile mindset based on Agile values.
Now for a trick question, what are your organization's enterprise architecture values?
