I don’t want to provide a theoretical example, what follows is an actual example from work I used to do some years ago as the architect for a major reengineering effort within IBM. We were implementing a popular packaged application, and as part of the recommended application management system, we needed to have at least three environments - Development, Test, and Production. This would be fine for a small company with minimal required changes to the package, but we were working a worldwide rollout over multiple years and multiple releases. Our infrastructure requirements were a bit more complex.
At any given time we we had at least three level of development going, due to our waterfall development approach. The packaged application required that all objects in production originate from the same system. In the above example this would be 2 releases ahead of what was running in production, unacceptable. Also, all changes had to be applied in the sequence they were created to ensure that you didn’t back level any code. This meant that a roll back of a function was actually not just a simple, apply the prior version, but a create a new version which reflected the release prior to the current change. Talk about complexity!
While you can understand from a packaged application perspective it makes sense to have a true system of record, this does not scale with complex deployment architectures. Nor does it scale when teams have to handle multiple releases at the same. This requires a modern source code management system.
The second challenge that the above deployment architecture caused was that for each release a set of presentations were made to reflect the connections between this application and other applications within the architecture. These deployment architectures were at best a picture of how all the applications, pre-reqs and co-reqs, databases, operating systems, etc. needed to be installed and configured to achieve the desired operational environment. To put it mildly they were wrong, at best. We would have to have multiple meetings, and test runs to wring out all the problems and ensure that we could perform our quarterly move to production weekends.
This does not scale in the world of Agile development, where teams are providing many, small, incremental updates to production monthly, weekly, daily and some times even hourly! What is needed is a governance and tooling environment which supports this level of change, without delivering unacceptable risk to the production environment. I’ll describe this in my next blog entry.