The Myth
There’s a new product roll out, the solution has been designed, everyone has added their own unique and valuable points to the big picture, it looks perfect. Unlikely.
Why is it a Myth? Well What ever you design is perfect only at the moment it was designed, from that point onwards it falls quietly into obsoleteness. Once you’ve experienced this a few times you’ll understand that the value in any solution is more about the flexibility and being realistic, expect any solution you put in place to have a shelf life of 6 months.
You have to consider the possibility that once you’ve wasted 6 months building out the worlds most beautiful solution that it was 3 months late to market and therefore no longer attracted the audience you wanted it to. With that in mind it’s a good idea to work out what is vital to be done in the immediate future and to have a plan about where you want to go, after all if you don’t know where you are going you will never get there.
What can you do?
Unless you are designing the solution maybe not much, but most likely you are talking to the people that are doing it or you are fortunate enough to be at the helm of the design ship and you can enact the real change needed.
Once you understand that the solution is only really going to last a few months the rest of it is irrelevant. Make sure that what ever you are putting in place meets the requirements, but above all else when faced with a decision on a slightly more flexible approach or a less flexible one, go for the more flexible one. This won’t always be possible but you want to mitigate the foot shooting as much as possible, after all you will be the one that has to re-build the solution if it is not flexible.
Not too long ago I was in the un-fortunate position of watching a colleague implement a puppet server, luckily they had experience of doing this in the past and although it was something I was really quite keen to do I had to bow down and let them continue. I only had one concern and that was that we structure our node manifests in a way that supporting multiple environments would be easier in the long run.
My idea was to have the site.pp include any pp file under puppet/manifests/something/*.pp unfortunately this didn’t happen and we stuck to one nodes.pp which is easier to manage, however we do now have a node manifest which is some 2000 lines long. Needless to say 5 months on we now have to implement that structure and migrate the nodes from the central nodes.pp into more site specific ones. I’d go into more detail but quite frankly it’s not that interesting and a little off topic for right now. In short, More flexibility is good!
This works in other situations too, just as you won’t ever design the perfect solution you won’t ever get it right first time but above all else, don’t worry about it. Don’t get frustrated when you see a solution going pear shaped or someone is implementing something that is not perfect, as long as it does what it needs to do now. Ideally it will do what it needs to do now and have the flexibility to be extended in the future.
So back to the point, a little frustrated, but it didn’t really cause any harm, we avoided a conflict over the issue and they now have the task of implementing the environmental structure, it is a more iterative approach. In this case it was more than likely we would need the environmental support so we should have done it sooner.
So we should have done that and we didn’t, however we spent no time at all worrying about a lot of other things, How would we cope with multiple sites in multiple countries? How will we transfer terabytes of data out of a hosting provider? I still have no idea on these; Why? it’s not that important, we haven’t got that far yet. In the large scheme of things the first 6 months of the project was more about meeting very specific business goals and making sure had done enough due diligence, more importantly we needed to implement things that really mattered.
We needed the tools to allow us to do the funky multi site environment, we needed the understanding of the product. With any new service it’s easy to get caught in the bigger picture, and be thinking that you have to worry about the multi site environment now because it will cause big issues if you don’t. in some cases that’s true.
So next time you’re faced with that situation do this.
It’s more important that you understand the impact of inaction that doing the action, so what you backups are all manual, the important thing is you have backups, You can automate them later if necessary (although to be honest, that one should be high on the list!)
Summary
Work out what is important to be done now, work out what the impact of the inaction could be. Don’t worry about designing the perfect solution, it will be wrong.
soimasysadmin 