Monday, December 05, 2005
Enterprise Architecture and Technology Consolidation
many industry analysts aren't assisting in providing valuable input into how it can be best accomplished. Guess I have to do the job they should be doing for others...
The word consolidation can be attached to data centers, applications, databases and even the amount of vendors and insulting firms an enterprise does business with and therefore should be viewed holistically. Reduction of sprawl in all forms helps reduce total cost of ownership but cannot occur in any realistic manner without embracing enterprise architecture.
Sure, we can open up a variety of industry magazines and read success stories on server consolidation but the answer to the real question is never provided. If you can cut down the amount of servers or other components of your infrastructure by half, how come the IT spend is still growing? I suspect that they were successful from a technical perspective but didn't do anything that would align the business demand for IT to the resources, capitalize on change or even adopt anything that would have made life easier for the folks who do application development. In fact, I suspect that the software developer's jobs have gotten more difficult (aka time consuming) interacting with a consolidated infrastructure.
Many, enterprise architecture practices actually don't spend much time understanding infrastructure even though in many shops it can be a majority of the IT budget. Maybe they are too busy believing the hype of savagely focusing on aligning with the business (not necessarily a bad thing) but ignoring the simple truth that someone in the organization must sooner or later understand technology.
Another phrase that is well worn in the halls of corporate America is Enterprise Architecture Governance. In all reality, many of its participants are spending time reviewing projects and programs and are spread too thin. Maybe they need to not focus on what is important but focus in on what is more important.
Since many EA practitioners haven't figured out what is more important within their own walls, I figured I would simply tell them to focus in on the following things:
The key thought to review is that in my humble opinion, it is not something that is done at a specific time in a project and then signoff is achieved. Rather, the notion of stewardship should occur throughout its lifecycle. The other aspect to review is that during a review cycle, the enterprise architecture team are not the only ones who should be critiquing. I recommend that reviewed projects will critique the project review process and provide feedback which allows for continual improvement.
Consolidation that is simply a technology excercise can be done without enterprise architecture but in order to increase business agility and reduce total cost of ownership, enterprises would be well-served by embracing enterprise architecture before embarking on consolidation projects.
Anyway, ran across the Enterprise Architecture Thought Leadership Council which strangely enough doesn't even have a single member of a Fortune enterprise and is 100% comprised of vendors. Will volunteer my services in hopes of bringing integrity to the discussion...
| | View blog reactionsThe word consolidation can be attached to data centers, applications, databases and even the amount of vendors and insulting firms an enterprise does business with and therefore should be viewed holistically. Reduction of sprawl in all forms helps reduce total cost of ownership but cannot occur in any realistic manner without embracing enterprise architecture.
Sure, we can open up a variety of industry magazines and read success stories on server consolidation but the answer to the real question is never provided. If you can cut down the amount of servers or other components of your infrastructure by half, how come the IT spend is still growing? I suspect that they were successful from a technical perspective but didn't do anything that would align the business demand for IT to the resources, capitalize on change or even adopt anything that would have made life easier for the folks who do application development. In fact, I suspect that the software developer's jobs have gotten more difficult (aka time consuming) interacting with a consolidated infrastructure.
Many, enterprise architecture practices actually don't spend much time understanding infrastructure even though in many shops it can be a majority of the IT budget. Maybe they are too busy believing the hype of savagely focusing on aligning with the business (not necessarily a bad thing) but ignoring the simple truth that someone in the organization must sooner or later understand technology.
Another phrase that is well worn in the halls of corporate America is Enterprise Architecture Governance. In all reality, many of its participants are spending time reviewing projects and programs and are spread too thin. Maybe they need to not focus on what is important but focus in on what is more important.
Since many EA practitioners haven't figured out what is more important within their own walls, I figured I would simply tell them to focus in on the following things:
- Applications / projects that are community (external) or enterprise-wide (non-departmental)
- Applications that are likely to expand beyond the initial departmental scope
- Applications that create and store user IDs and Passwords - Keeps one out of trouble with SoX
- Applications that utilize sensitive data - Keeps one out of trouble with GLBA, HIPAA, California 1386 and others
- Applications that emit smells - Future blog entry will explain this in detail
The key thought to review is that in my humble opinion, it is not something that is done at a specific time in a project and then signoff is achieved. Rather, the notion of stewardship should occur throughout its lifecycle. The other aspect to review is that during a review cycle, the enterprise architecture team are not the only ones who should be critiquing. I recommend that reviewed projects will critique the project review process and provide feedback which allows for continual improvement.
Consolidation that is simply a technology excercise can be done without enterprise architecture but in order to increase business agility and reduce total cost of ownership, enterprises would be well-served by embracing enterprise architecture before embarking on consolidation projects.
Anyway, ran across the Enterprise Architecture Thought Leadership Council which strangely enough doesn't even have a single member of a Fortune enterprise and is 100% comprised of vendors. Will volunteer my services in hopes of bringing integrity to the discussion...
