Tuesday 3 February 2015

Don't get bogged down justifying someone else's history

So, we were being presented to last Fri on an enterprise's major new digital presentation system; wrapping up all the scary legacy middleware with a modern puff-jacket of APIs, dished up with piri-piri multiple access mobile platforms. Good stuff and they've got a good handle on what their doing - both were smart chaps and had a good sense of fun, essential when you're looking a huuuugggeee Visio models!

But, they kept stuttering on one thing, the past...

The system is clubbed together using line of business back-ends that are 20 years old, running on big iron as well as interim security layers due to the nature of their business.

They've weaved like a ninja and ducked like a badger to make a compelling story that avoided the constraints imposed upon them as well as possible; the sequel when released worldwide even purported to transition a further step and remove the hurdles of the legacy security layer.

Where they failed in getting it across was to get that explanation out of the way early and bank it; before showing off their good stuff - rather feeling embarrassed when they didn't need to.

What is legacy was seldom bad at the time; any architecture is only good (note never perfect), in your business, with your teams, technology stacks, corporate climate and strategy and that exact moment in time. Unless it blows up in your face don't go back there. Much like trying to understand why your first love gave you the heave-ho 15 years ago, it doesn't get you anywhere.

So, we're back to the story; the way we human sorts have been communicating over tens of thousands of years, prior to pen, paper and caves to write on, in a way that tales have stayed with us for millennia.

Unless you want to go Tolkien and spend 100 pages on the past; go brief and go clear; get your introduction out of the way and present that as-is and the constraints it imposes upon where you can go forwards.

Then hit the audience with your content safe in the knowledge they are reviewing and thinking about the good new stuff 

If you're story is big and long; then a conclusion of sorts may be needed; one way of doing that is an overlay, possibly with transition steps. We'd suggest you present that in a different way to your content - if your content was words and text, use pictures; or if you presented in pictures use words.

This is for three reasons; firstly it's less dull and looks less like you're padding out; secondly it allows you to cross-reference what and how you're saying things. Thirdly and a key point throughout presentations; people think and understand differently. While the majority of we architecting types love a good model, others (those with real jobs) might prefer a good set of bullets or a table to help things sink it - both concluding with another view you hit both audiences.

Keeping on with our movie/story idiom, think of it like Shrek; it appeals to kids and adults with those smutty jokes hidden where kids cannot reach - end results everyone laughing.

A key point to this is get excited about what you've done and thought through; it's a creative process and you spent ages on getting a result - now show it off properly!

So, in conclusion... For the geeks out there, think Episode IV back in the 70s, those scrolling Star Wars credits are your legacy, where you are and what is. Present or show that well, then weave your compelling yarns on how you've defeat the Empire and/or expose a real-time RESTful API over your mainframe.

Hell, if you're feeling brave why not present your next architecture as it is was a Star Wars movie; just without Binks.