Monday, February 05, 2007
Eliminating inefficiencies within the enterprise...
I had an interesting conversation with one of my mentors over the weekend regarding how enterprise architects are doing a poor job of eliminating efficiencies within their enterprise and why he believes that enterprise architects always fail at justifying their existence...
This conversation was timely as I am currently researching metrics for chapter I am writing for an upcoming book. My mentor stated that enterprise architects have tons of metrics that show activity but almost zero that shows efficiencies. Noodling his advice I started to realize that most folks in large enterprises don't really have a clue to areas of inefficiencies nor do we spend much time searching for it as this would require a dedicated effort which flies in the face of IT align with the business and the repeat after me cliche phrases that we have been indoctrinated to spew for eternity.
Business folks in many shops are frustrated. The missed opportunity costs are realized in failure to generate real return on IT projects and inefficiency is generally the application of, or the failure of application of, methods, procedures, practices and allocation of resource in an approach designed for success.
Have you ever heard of ERP4IT? How about ERP for people where we first figure out how to inject honest communication into the enterprise? Enterprise architects may have a better return on investment if they were to focus on people (fyi, this is the most expensive resource in the budget) and figure out ways to eliminate head nodding when managers ask about status.
The second thing I would champion is the elimination of governance in terms of financial controls or at least attempt to decouple it from how software is development. Another inefficiency is in treating requirements, design, development, testing as separate phases. In this approach, there is nothing to measure for efficiency and no known status. You only know where you are and when you are done.
Maybe inefficiency will be eliminated if we can teach business folks how to ask the right questions and not just questions. I wonder if this should be the topic of my next book? Maybe this is the job of folks that blog about business architecture to start the conversation...
| | View blog reactionsThis conversation was timely as I am currently researching metrics for chapter I am writing for an upcoming book. My mentor stated that enterprise architects have tons of metrics that show activity but almost zero that shows efficiencies. Noodling his advice I started to realize that most folks in large enterprises don't really have a clue to areas of inefficiencies nor do we spend much time searching for it as this would require a dedicated effort which flies in the face of IT align with the business and the repeat after me cliche phrases that we have been indoctrinated to spew for eternity.
Business folks in many shops are frustrated. The missed opportunity costs are realized in failure to generate real return on IT projects and inefficiency is generally the application of, or the failure of application of, methods, procedures, practices and allocation of resource in an approach designed for success.
Have you ever heard of ERP4IT? How about ERP for people where we first figure out how to inject honest communication into the enterprise? Enterprise architects may have a better return on investment if they were to focus on people (fyi, this is the most expensive resource in the budget) and figure out ways to eliminate head nodding when managers ask about status.
The second thing I would champion is the elimination of governance in terms of financial controls or at least attempt to decouple it from how software is development. Another inefficiency is in treating requirements, design, development, testing as separate phases. In this approach, there is nothing to measure for efficiency and no known status. You only know where you are and when you are done.
Maybe inefficiency will be eliminated if we can teach business folks how to ask the right questions and not just questions. I wonder if this should be the topic of my next book? Maybe this is the job of folks that blog about business architecture to start the conversation...
