Behold the second piece of my garden, together with some part of the bridge. The pile of tiles is there to nag me so I'll leave Twitter and blogging alone and get to redo this piece of garden
Redo? Yes, redo. When looking for inspiration today, Henk van Zuilekom was kind enough to give me "one of those tasks":
@MartijnLinssen draw a parallel between re-doing legacy applications and re-doing a garden. where does it all go wrong?I wonder whether I inspired him as I posted the picture above a few days ago, but I do see some very useful parallels between redoing enterprise IT landscapes, and "just landscaping" your own garden
Coincidentally, tonight's tweets and blog posts from other have been pointing in the direction of open hunting season on IT architects, somehow - so maybe it's a good time to reintroduce common sense, which this post is all about
How do legacy applications get redone? There is one story to that, with a few chapters, none of which always get read. Usually, the bottom-up approach is wielded by IT:
- Look on all hard drives for applications
- Make a list of all applications on all hard drives
- Hand over list with applications to IT manager
Here's the software architect approach:
- Make a list of all application managers
- Interview them
- Hand over list with applications to project lead
The Architect approach is to ask the users, what they are using, and then cross-reference that with the backend. Still, the ultimate end-goal is the list of applications as mentioned above.
The result? A messy mismatch between that what's there, and that's what supposedly in use - and then what?
Redoing a garden is a whole different story. There, the owner points out what he wants to keep and what he doesn't, and how he would like it to be. The gardener comes in after of without the landscaping architect, plants and builds everything according to the rough sketch, money passes hands and the customer's satisfied
Wow. That's quick. In IT, we had only a list that didn't add up much. Where did it go wrong?
- Overseeing a garden, even a big one, is a lot easier than overseeing an enterprise IT landscape. The difference is that people are actually using IT tools that aren't in the overview. However, much like people are making apple juice and marmelade off of a garden, those should just be considered out of scope
- Ownership in a garden is much less complicated, and a lot better 'documented'. There never is a tree or plant unaccounted for: if there are, they're just considered weeds, and exterminated
- Functionality of plants and trees is either blatantly obvious, explained by the owner, or irrelevant. No need to seek high and low for hidden features, advantages, disadvantages or risks
- The so-called AS-IS never is very interesting in gardening, only the available space is. People have an idea about the TO-BE situation: they look ahead, not behind. Sure, a special plant or very old tree might survive, but there aren't any "action groups" advocating the survival of some ugly plants or trees unless - well, unless the garden gets to be a few dozen square miles, and public property...
Ah, now it starts to make sense, doesn't it? Current enterprises are just too big, and the supporting IT landscapes dito. The unknown that is considered weed in a simple garden, is a potential huge business risk: what if entire countries depend on the apple juice and marmelade our garden trees and plants supply?
The solution is simple, especially now: chop up the enterprise, redo that in stead of only the IT department
The enterprise has become too big too sustain, from a human point of view, and now also from an IT point of view