May 21st, 2008Pondering large scale application consolidation
Historically many bespoke application are developed on the same servers the prodcution application runs on. Often this server was built by the developers with little regards for consistancy. After all developers develop applications for a living, not build server infrastructure.
Developing an application on the production server can lead to many problems, particularly if that server build is not quite right or the developer is a little wet behind the ears and does not considure scaling issues and hard coded resource refernces. Then of course it is always possible to cripple the production server by testing rogue application code at the whim a developer. I could witter on for ages about this, bit i want to get on towards what needs to be done to consolidate these applications to central managed infrastructure. Putting to one side the issues of supporting the, often extremely large, consolidation platform, many problems need to be over come to ensure the successful migration / consolidation of bespoke applications in the enterprise.
<UPDATE>
It is worth pointing out that these applications should be consolidated to a well defined, well managed platform, where each appliaction exists in a logical container where ALL interfaces and features are defined and controlled by the infrastructure. Hopeful reducing or even eliminating many of the future gotchas
It should also be noted the technology is only a small part of the battle. Accurate recording of succesfull migration, ownership, and reporting of KPIs also need to be considered. i am not talking a few spreadsheets, it needs to be a fully operation CMDB. spreadsheets are not searchable on MASS, so without a proper CMDB you still only have a huge quantity of unstructure data which is be out of data before you can use it
</UPDATE>
So this is my list of check points and Gotchas
