Script Kiddies and Reference Architectures: 11 Reasons to say No

This is Kevin. He’s a Script Kiddie.  We really need to talk about Kevin.

He’s a glass-half-full kinda guy!  He loves learning on the job, and he’s looking insanely happy because he’s been told he can build his first converged infrastructure by plagiarising someone else’s to-do list, also known as a Reference Architecture.

That’s right: as if his blindly plagiarising a simple best practice doesn’t cause enough damage, imagine him using a huge complex interwoven collection of them that stretches over one-hundred pages: that’s what a Reference Architecture is.

Chad Sakac has just posted an excellent blog on this topic, and it’s timely that I share eleven reasons why you should avoid the incorrect use of Reference Architectures, Dear Reader.

1. Best is a relative term.  Better than what?  If there are three ways to skin a cat, what is the best practice?  Well, if the guy that wrote it had a knife to skin that cat but you only have your teeth: what do you do now?  Before you buy a knife, check your name isn’t Reg Prescott.
2. Sharing is not caring.  Just because someone shares their practices with you (and I’m a fan of that, after all I did VIOPS), if you blindly copy what they did and it doesn’t work then do not expect them to help you.  You are on your own.  It’s all your risk.
3. Prepare to shave a yak.  When it doesn’t work (and believe me, it won’t) then will you know why?  Chances are this is your first time (otherwise why are you following a strangers to-do list?), and therefore you will get a sore head with all that scratching trying to figure out the answers.  I hope you can reach Google from the datacenter?
4. You will stray from the path.  You will have to customise the best practices in a reference architecture: but do you know what has to change due to different requirements?  And when you DO change something, what’s the impact of THAT change?  At this point you are on your own, your solution is not standard nor recognisable to the original reference.
5. Entropy is Flexibility’s evil twin.  The more you stray from the path the more you disintegrate the architecture and start to experience entropy: cause and effect start bouncing off each other like rabbits, breeding misconfigurations across your solution.  Think of “re-pristining” Windows OS: that’s Entropy in action on a small scale affecting one user.
6. The future is unpredictable.  Products change over time, so do people, so do solutions: everything changes: a reference architecture does not protect your from these changes.  Imagine you’ve got a converged infrastructure, that you’ve customised, and one of the elements has a new release: how do you do it?  Should you do it?  What happens if you do?  You. Are. On. Your. Own.
7. Come on in the water’s lovely.  Reference architectures are mostly marketing papers, giving you the illusion of a safety blanket so that you feel empowered to buy the latest widget.  That means you are at the cutting edge, installing version 1.0.  Is that blanket still keeping you warm?
8. Failure has many faces. Gone are the days when IT guys just had to keep the lights on.  Now they are being asked to do custom work at the speed of cloud providers.  Failure is now an East-West (solution lifecycle) as well as North-South (technology stack functions) problem.
9. Consumers have no tolerance for failure.  Clouds work indoors and outdoors today, and they are ready for your customers who have applications that need to work NOW while you’re creating a customer solution from someone else’s to-do list: if you fail (see point 8) then don’t expect them to wait six months for you to get it right.
10. A fool with a tool is still a fool.  Think you can short cut the process and fix the above with a tool?  I see that Cloupia have an automated way of implementing a reference architecture for FlexPod, and HP have a million different incompatible products that need services… Think that’s awesome?  It certainly is: I can’t think of a faster way to implement all nine failure scenarios above.  Now you have to maintain the reference architect AND the tool AND integrate it… headache inducing.
11. IT people are horrible tech writers.  There are very few people I know in the tech industry who love also to write documentation.  And if you hate a job you are usually bad at it.  Bad means missing stuff, having sloppy commands that don’t work, and not keeping the document up to date.

All those 11 reasons multiplied together with various helpings of impact and probability give you a big old lump of risk that might be too hard to swallow.

There are two ways to derisk these eleven reasons though, and both of these are about the appropriate use of Reference Architectures:

1. A reference architecture has a single use-case: for learning about technologies and solutions.
2. For real life, skip the reference architecture and go to a reputable, experienced, knowledgeable, customer-focused partner to get it right.

Reference Architectures when used properly are great learning tools.  Take the Cisco Validated Designs (CVD) as a great example.  When I was at Cisco you would find a brilliant Technical Marketing Engineer to author a new CVD to combine new and exciting products together for the first time.  EMC and VMware do similar great work to showcase their technologies.  Yes it is possible to use OTV and VPLEX for long distance vMotion, but would you build this for real just using the reference architecture?

If someone claims to be a knowledgeable expert but then refers to a reference architecture, they aren’t likely to be what they claim.  A reputable expert will have superceded a reference architecture long ago and have their own kitbag from which to help craft a solution.  Great channel partners of the major vendors stand out immediately, if you need help finding one let me know!

If you want to create something as powerful as converged infrastructure to be right first time, be fit for purpose to run mission critical workloads and run for a significant period of business: don’t use a reference architecture!