Digital Darwinism Doesn't Have A Start Date

Digital Darwinism, the evolution of online services, propositions and systems that will eventually change every industry, is a concept that has been gradually creeping up on most people.

It's the little changes we don't see happening every day that add up to a lot over a short period.

• When did you start relying on Uber (or some other more ethical ride hailing App) to get you home after a late night in the office? 
• When did you start using the term "to Google" rather than just "to search online?"
• When did you start discussing that new Netflix series, as opposed to the regularly scheduled broadcast TV show you used to watch?
• When did you start ordering your household goods on Amazon?
• When did you start playing YouTube videos, rather than play music from your CD collection?

In the end you realise that there's less and less likely that there was a specific date for when you actually started doing these things... it just sort of happened. Or if you are a young person, you don't actually recall a date when many of these things were not the norm.

Evolution isn't a thing that happens to other creatures and people, with digital technologies the best example is happening right now.

Writing about Smart Ticketing

In my recent LinkedIn article “The 6 things they should tellabout smart ticketing and don’t” I cover some essential information that I would have found useful before entering into the world of ITSO Smart ticketing.

In this article I mention how: the industry if full of acronyms, Smart ticketing doesn’t necessarily mean smart customers (straight away), the benefits of combining smart ticketing with a decent online proposition, how you shouldn't stop improving the holistic user experience, testing and smart ticketing technical architecture.

This post has turned out to be my most successful article so far, with a large number of views and a few comments too. It has clearly proved to be interesting and engaging. Which is exactly why I wrote it.

Failing to Architect with Agile is Architecting to Fail

Agile approaches to development and online product delivery are almost de-facto these days. Every private and public sector organisation wants to be transformed, nimble, lean and able to deploy digital services quicker and quicker to their ever-demanding customers. And it is not just in the IT coding department that there’s been a change in vocabulary. An agile approach can even be adopted by a company’s commercial team, marketing department and even some of their operational functions (plus don’t even get me started on how much senior managers, procurement and HR have to change too – but that’s something for another post).

But I’m going to stick my next out (once again) on a subject I’m passionate about… Technical Architecture and how it clashes with agile delivery.
Or more succinctly put: Agile Architecture Doesn’t Work

There, I’ve said it now and I’ve been wanting to say it for a while. It has been on my mind as I’ve heard the opposite mentioned in podcasts, or read about it in blogs and books.
I guess I was trying to get this off my chest when I wrote my recent blog post “Digital Transformations starts and ends with Digital Architecture”. As in my mind, the science (or is it art?) of crafting a robust yet flexible technical architecture that supports digital business aims is the one thing you can’t build as you go.

Creating the technical architecture for your new venture takes planning. You also really only need one Technical Architect, the person who owns the architecture and has the responsibility for its solution design and ensures re-use of common components. Not a bunch of developers who all want to create a part of the architecture they are responsible for.

It’s like wandering around on a gap year between school and university (or school and work, or university and work).  You may be able to make up your journey as you go, with just you or a travelling companion making the decisions… but the roads and the map are pretty much fixed.

So...  although some agile practitioners talk about how agile approaches can help architecture deliver quicker or better.  I firmly believe that it is architecture that facilitates faster and more robust agile delivery.