Suppose you are in the IT department of a (very) large organization and have been developing systems for your organization for quite some years. Chances are that you will have a landscape of systems great and small that all serve a particular purpose, or that have served a particular purpose. Systems that were built in a variety of languages, such as Visual Basic, Cobol, C, PowerBuilder, Java, or packaged systems including SAP, Oracle, PeopleSoft or more modern variations such as salesforce.com.
Since each of your systems only covers part of your business processes it is likely that they are linked together in all kinds of ways. Either they re-use each others functionality via services, or worse they use each others data or databases. Or maybe they even just exchange files in XML, Excel, CSV. No matter the protocol, life will be harsh on you.
Release calendar
A few weeks ago I had a really interesting conversation with the release manager of such an organization. He was desperately trying to implement a release calendar with regular intervals. That is, he hoped to reach the situation that this organization had four releases per year of the whole landscape. Each release should implement the results from projects and from handling change requests to existing systems. A noble goal.
However, this noble goal did not seem very realistic. Most change requests on his list included changes to a number of systems. Sometimes up to eight different systems need to be changed to implement a single change request.
The big issue here is that these changes to different systems are aligned in chains. Even making the simplest change to a business process requires development, but much more, it requires testing. Lots and lots of it. First of all the changes to the individual systems need to be tested. Next the chain of changes needs to be tested in the integration test. Then if everything works out fine, the whole landscape needs to be placed into acceptance to perform an acceptance test.
Whiteboard
Standing in front of a whiteboard the release manager drew the different stages in his release calendar on a line representing the three month period he had in mind. “At the end we have the acceptance test,” he stated, and took four weeks from the end of his line. “Before that we run the integration test,” he continued, and took off another three weeks. “And of course the individual systems are also tested, that takes about two weeks after the developers finish writing the software.” And then he finalized his calendar with the statement that business and information analysis also require about two week. “So, there you have it,” he proudly pointed to the timeline.
I stared at the timeline for a while, a bit in doubt whether this was serious, or if he was pulling my leg. All in all, the release calendar in front of me on the whiteboard only has two weeks to do design and development. Extrapolated that adds up to around eight weeks of software development in a whole year. And this was not even real life, but the situation the release manager strived for to reach in a couple of years. Real life was worse.
We finally done it
And it will get even worse. Because with each change in any of the systems the landscape will get bumpier. Just to give an idea of the complexity, the about forty systems in the landscape are documented in over 9.000 documents, spreadsheets, models, PowerPoint presentations that are located in over 2.000 directories. And with each new bump in the road, testing will get more complicated. Resulting in longer time frames and thus resulting in an even shorter development period. My guess was that within three years from now development will have totally stopped, and the organizations will only do testing. How’s that for productivity.
This is what I call Death by Landscape.
A particularly nasty anti-pattern, this Death by Landscape. It’s consequences not only sink your ability to implement changes and new functionality, it will disallow you to support the new products your marketing department wants to introduce, and it stops you from implementing new legislation or regulations when required. In short: death by landscape directly impacts your business. We’ve finally done it.
Sander Hoogendoorn
Principal Technology Officer Capgemini
www.sanderhoogendoorn.com
www.smartusecase.com
