A sneak peek inside a hothouse sprint week extravaganza

Most public and private sector leaders are acutely aware that they are supposed to be living and breathing digital: working smarter, serving people better, collaborating more intuitively. So why do front line realities so often make achieving a state of digital nirvana feel like just that: an achievable dream? The world is much messier and more complex for most organisations than they dare to admit, even internally. Achieving meaningfully digital transformation, with my staff/ customers/ deadlines/ management structure/ budgets? It’s just not realistic.

That’s where the Innovation Practice at Sopra Steria steps in.

I count myself lucky to be one of our global network of DigiLab Managers. My job is not just to help our clients re-imagine the future; anyone can do that. It’s to define and take practical steps to realising that new reality in meaningful ways, through the innovative use of integrated digital technologies, no matter what obstacles seem to bar the path ahead.

This is not innovation for the sake of it. Instead, our obsession is with delivering deep business performance, employee and customer experience transformation that really does make that living and breathing digital difference. Innovation for the sake of transformation taking clients from the land of make-believe to the tried and tested, in the here and now.

The beautiful bit? The only essentials for this process are qualities that we all have to hand: the ability to ask awkward questions, self-scrutinise and allow ourselves to be inquisitive and hopeful, fearlessly asking “What If?”.

Welcome to five days of relentless focus, scrutiny and radical thinking

The practical approach we adopt to achieving all this takes the form of an Innovation Sprint: a Google-inspired methodology which lets us cover serious amounts of ground in a short space of time. The Sopra Steria version of this Sprint is typically conducted over 5 days at one of our network of DigiLabs. These modular and open creative spaces are designed for free thinking, with walls you can write on, furniture on wheels and a rich and shifting roll-call of experts coming together to share their challenges, insights and aspirations. We also try to have a resident artist at hand, because once you can visualise something, solving it becomes that bit easier.

The only rule we allow? That anything legal and ethical is fair game as an idea.

Taking a crowbar and opening the box on aspiration

Innovation Sprints are the best way I know to shake up complex challenges, rid ourselves of preconceptions and reform for success. I want to take you through the structure of one of the recent Sprints we conducted to give you a peak at how they work, using the example of a Central Government client we have been working with. Due to the sensitive nature of the topics we discussed, names and details obviously need to stay anonymous.

In this Sprint we used a bulging kitbag of tools to drive out insight, create deliberate tensions, prioritise actions and, as one contributor neatly put it, ‘push beyond the obvious’. That kitbag included Journey Maps, Personas, Value Maps, Business Model Canvases and non-stop sketching alongside taking stacks of photos and videos of our work to keep us on track and help us capture new thinking.

Before we started, we outlined a framework for the five days in the conjunction with two senior service delivery and digital transformation leads from the Central Government Department in question. This allowed us to distil three broad but well-defined focus areas around their most urgent crunch points and pains. The three we settled on were ‘Channel shifting services’, ‘Tackling digital exclusion’  and ‘Upskilling teams with digital knowhow and tools’.

Monday: Mapping the problem

We kicked off by defining the problems and their context. Using a ‘Lightning Talks’ approach, we let our specialists and stakeholders rapidly download their challenges, getting it all out in the open and calling out any unhelpful defaults or limited thinking. In this particular Sprint, we covered legacy IT issues, employee motivation, citizen needs and vulnerabilities and how to deliver the most compassionate service, alongside PR, brand and press challenges, strategic aims and aspirations and major roadblocks. That was just Day One! By getting the tangle of challenges out there, we were able to start really seeing the size and shape of the problem.

Tuesday, Wednesday and Thursday: Diving into the molten core

This is where things always get fluid, heated and transformation. We looked in turn at the  three core topics that we wanted to address, following a set calendar each day. We would ‘decode’ in the morning, looking at challenges in more detail again using ‘Lightning Talks’ from key stakeholders to orientate us. Our experts shared their pains in a frank and open way.  We then drilled each of our key topics, ideating and value mapping, identifying  opportunities to harness innovation and adopt a more user-centric approach to technology.

At the heart of this activity we created key citizen and employee personas using a mixture of data-driven analysis and educated insight. An exercise called “How might we…?” helped us to free-think around scenarios, with key stakeholders deciding what challenges they wanted to prioritise for exploration. We were then directed by these to map key user journeys for our selected personas, quickly identifying roadblocks, testing or own assumptions, refining parameters and sparking ideas for smarter service design.

On each day we created Day +1 breakaway groups that were able to remain focused on the ideas generated the day before, ensuring that every topic had a chance to rest and enjoy a renewed focus.

Friday: Solidifying and reshaping for the future

On our final day, we pulled it all together and started to make the ideas real. We invited key stakeholders back into the room and revealed the most powerful insights and synergies that we had unearthed. We also explored how we could use the latest digital thinking to start solving their most pressing challenges now and evolve the service to where it would need to be in 3-5 years’ time. Our expert consultants and leads in automation and AI had already started to design prototypes and we honestly validated their potential as a group. Some ideas flew, new ones were generated, some were revealed to be unworkable and some were banked, to be pursued at a later date. We then discussed as a team how to achieve the transformations needed at scale (the department is predicting a rapid 4-fold growth in service use) while delivering vital quick wins that would make a palpable difference, at speed. This would help us to secure the very senior buy in our clients needed for the deeper digital transformations required.  To wrap up, we explored how we could blueprint the tech needed, work together to build tight business cases, design more fully fledged prototypes, strike up new partnerships and financial models and do it all with incredible agility.

Some photos from the week

Fast forward into the new

My personal motto is: How difficult could that be? When you’re dealing with huge enterprises and Central Government departments devoted to looking after the needs of some of the most vulnerable and disenfranchised in our society, the answer is sometimes: Very! But in my experience, there is nothing like this Sprint process for helping organisations of all stripes and sizes to move beyond unhelpful default thinking and get contributions from the people who really know the challenges inside out. With this client, we were able to map their challenges and talk with real insight and empathy about solutions, in ways they had never experienced before. We were also able to think about how we could leverage Sopra Steria’s own knowledge and embedded relationships with other government departments to create valuable strategic synergies and economies of scale.

A Sprint is never just about brainstorming around past challenges. It’s about fast-forwarding into a better, more digital, seamless and achievable future, marrying micro-steps with macro-thinking to get there. It’s an incredibly satisfying experience for all involved and one that delivers deep strategic insight and advantage, at extreme speed. And which organisation doesn’t need that?

Let’s innovate! If you’d like to book your own hothouse sprint week extravaganza or just want to know more about the process, please get in touch

Containers: Power & Scale

by Richard Hands, Technical Architect

In my last blog post, we looked at the background of Containers. In this piece, we will explore what they can do and their power to deliver modern microservices.

What can they do?

Think of containers on a ship.  This is the most readily used visual analogy for containers. A large quantity of containers, all holding potentially different things, but all sitting nice and stable on a single infrastructure platform, gives a great mental picture to springboard from.

Containers are to Virtual Machines, what Virtual Machines were to straight physical hardware.  They are a new layer of abstraction, which allows us to get more ‘bang for our buck’.  In the beginning, we had dedicated hardware, which performed its job well, but in order to scale your solution you had to buy more hardware. This was difficult and expensive. Along came Virtual Machines, which allowed us to utilise much more commoditised hardware, and scale up within that, by adding more instances of a VM, but again, this still came with quite a cost.

To spin up a new VM, you have to ensure that you have enough remaining hardware on the VM servers. If you are using subscription or licensed operating systems, you have to consider that etc.  Now along comes containers. These containers literally contain only the pieces of code, and libraries necessary, to run their particular application. They rely on the underlying Infrastructure of the machine they are running on (be it physical or virtual).  We can typically run 10-20x more containers PER HOST than if we were to try putting the same application directly on the VM, and scale up by scaling the number of VM’s.

Orchestration for power

Containers help us solve the problems of today in far more bite-sized chunks than ever before.  They lend themselves perfectly to microservices.  Being able to write a microservice, and then build a container that holds just that microservice and its supporting architecture, be it spring boot, wildfly swarm, vertex, etc., gives us an immense amount of flexibility for development.  The problem comes when you want to orchestrate all of the microservices into a cohesive application, and add in scalability, service reliability, and all of the other pieces that a business requires to run successfully.  Trying to do all of this by hand would be an incomprehensible challenge.

There is a solution however, and it comes in the form of Kubernetes.

Kubernetes is an open-source platform designed to automate deploying, scaling, and operating application containers.” (http://kubernetes.io)

Kubernetes gives us a container run environment that allows us to declaratively, rather than imperatively define our run requirements for our application.  Again let’s look back to our older physical or VM models for the imperative definition:

“I need to run my application on that server.”

“I need a new server to run my application on, and it must have x memory and y disk”

This approach always requires justifications, and far more thought around HA considerations such as failover, as we are specifying what we want our application to run on.

Most modern applications, being stateless by design, and certainly containers, don’t generally require that level of detail of the hardware that they are running on. They simply don’t care as they’re designed to be small discrete components which work together with others.  The declarations look more like:

“I want 10 copies of this container running to ensure that I’ve got sufficient load coverage, and I don’t want more than 2 down at any one time.”

“I want 10 copies of this container running, but I want a capability to increase that if cpu or memory usage exceeds x% for y% time, and then return to 10 once load has fallen back below z

These declarations are far more about the level of application service that we want to provide, than about hardware, which in a modern commoditised market, is how things should be.

Kubernetes is the engine, which provides this facility but also so much more. For example with Kubernetes we can declare that we want x and y helper processes co-located with our application, so that we are building composition whilst preserving one application per container.

Auto scaling, load balancing, health checks, replication, storage systems, updates, all of these things can be managed for our container run environment by Kubernetes.  Overall, it is a product that requires far more in depth reading than I can provide in a simple blog post, so I shall let you go and read at http://kubernetes.io

Last thoughts

To conclude, it is evident that containers have already changed the shape of the IT world, and will continue to do so at an exponential pace.  With public, hybrid, and private cloud computing becoming ‘the norm’ for both organisations, and even governments, containers will be the shift which helps us break down the barriers from traditional application development into a true microservices world. Container run systems will help us to break down the old school walls of hardware requirements, thus freeing development to provide true business benefit.

Follow Richard Hands on Twitter to keep up to date with his latest thoughts.

Lean Tea – A new Agile Retrospective meeting format

Many of our readers and subscribers – especially those involved in Agile software development – will be familiar with Lean Coffee ™ meetings where participants get together, add potential agenda items to a Kanban board, and then discuss these items in turn, starting with the one with most votes. This is a great meeting format but if you have a ready-made batch of discussion points or important issues that need dealt with then why not cut to the chase? To that end I devised the ‘Lean Coffee with Cream’; but the introduction of cream – i.e. pre-prepared agenda items – breaks the trademarked Lean Coffee model, and I’m a typically British tea drinker, too, so I’ve decided to rename it the Lean Tea meeting.

From Lean workshops to Lean Tea meetings

I am currently serving as a Scrum Master for one of Sopra Steria’s Government sector clients; and my team and I strive for continous improvement. To that end we inspect and adapt our approach to software delivery, and we make good use of our fortnightly sprint retrospectives, mixing up the meeting format from time to time to keep things fresh, and following up on agreed actions. But a couple of months ago we decided to use the time set aside for our regular retrospective meetings and hold workshops on Lean Software Development instead.

In our first workshop we came together as a team to learn about The Toyota 3M model and the three enemies of Lean: Muda (waste), Muri (overburden) and Mura (unevenness). We then took some time in between workshops as individuals (prompted by email), to think about these three forms of waste (and the seven types of Muda in Lean Software Development) and how they apply to what we do. And in our next workshop we shared and discussed our examples of Muda, Muri and Mura, and I documented them all in our team’s online knowledge base.

There were some obvious quick wins which we dealt with – wastes that had not been mentioned in our regular retrospectives – but we were left with a long list of unprioritised wastes. So I turned to Lean Coffee Tea for our next retrospective, where instead of handing out post-it notes and pens to my teammates, I just handed out pens, because I had already added all our identified wastes to the meeting’s three-column Kanban board under “To Discuss”. We had our agenda. Now we just had to vote on those wastes that really mattered to us and were slowing us down.

Our first Lean Tea meeting was a great success: we identified and dealt with our two main wastes and our velocity has increased. I have since used the format again in a retrospective where I asked my team to vote on the five Scrum values they thought we were best at; then I reversed the voting order and we discussed those values with the fewest votes and how we could improve on them. The same could be done with the twelve agile principles or with outstanding action items (in priority order) from previous retrospectives.

So the next time you are looking for a new agile retrospective format why not try a Lean Tea? And consider having an actual cuppa while you’re doing it as tea is said to be good for the brain!

Ready Steady Cook

by Software Engineer Graduates, Alistair Steele and Gregg Wighton

Two from our February 2017 Graduates cohort discuss their recent Graduate Project using Chef Technology to solve the problem of setting up a machine (laptop) adhering to company standards. Their aim was to introduce a working example of DevOps and learn more about that sphere. This post talks about the problem they sought to address using Chef, what DevOps is and the experience they have gained from their Graduate Project.

The Problem

During a new starter’s induction day, a considerable amount of time and effort is spent on setting up a Development machine (laptop). Tasks involve downloading software and creating a folder structure which adheres to the guidelines set out by the company. This manual process is time consuming and tedious, plus it allows room for human error. The same issue occurs for a current employee who has to rebuild their machine. A third issue can be seen with employees who have forgotten the company guidelines.

Company time, in particular for new inductions, would be better spent in various other ways. Allowing the new employees to read company policy or familiarise themselves with the office building and appropriate contacts.

A key aspect of this project was to eliminate user interaction and cut down on the potential human error. To achieve this, three technologies were considered, Ansible, Puppet and Chef. We chose Chef as it is serverless, scalable and Windows compatible.

With the technology selected we looked at how best to use Chef and what it’s capabilities were. This required a lot of research – and trial and error. Understanding the problem enabled us to create three main goals: Silent Installs of required software, Folder Structure and Environment Variables, all of which were to be automated.

Our objective was for the user to simply download Chef Client, connect to the repository on InnerSource and then run a single command on the command line. The Automated process will then kick off and deliver the finished product. So what will it achieve?

  • Ensures standardisation throughout the company
  • Saves the company valuable time
  • Speeds up Induction process
  • Silent installs of software, folder structures and environment variables

Using DevOps to tackle the ‘Wall of Confusion’

In the traditional flow of software delivery, the interaction between development and support is often one of friction. Development teams are wired towards implementing change and the latest features. Support teams focus on stability of production environments through carefully constructed control measures. This divide in culture is now commonly referred to as the “wall of confusion”.

DevOps looks to break down this culture by improving the performance of the overall system, so that supporting the application is considered when it is designed. One method of doing this is to start treating your infrastructure as code so that it can be rebuilt and validated just like application code.

One area that would benefit from provisioning infrastructure would be the configuration of development environments. Setting these up can often be tedious as they rely on specific versions of software, installed in an exact order with particular environment variables and other project specific configurations – all of which can cause delays to working on a project and are prone to human error.

Automation, Automation, Automation

Chef is a powerful automation platform that uses custom Ruby DSL to provision infrastructure. A key feature of Chef is that it ensures Idempotency – only the changes that need to be applied are carried out, irrespective of the number of times it is ran. While it is intended to configure servers, the flexibility of the platform means that it can be used to set up local development environments.

Diagram described in the text belowOur diagram shows the architecture and workflow for the project. A developer writes Chef code on their workstation, then uploads their code to a Chef repository hosted on GitLab, and installers kept in an S3 bucket on AWS. This code can be pulled down to a developer’s machine to be configured and run in Chef Zero. This is a feature (usually used in testing code) where both a Chef Server and Chef Client are run at the same time. This approach ensures that development machines can be quickly and reliably configured for a project. This also introduces portability into development environments so that testing and support teams can recreate these environments should they need to.

Ready for the Cloud

Chef is tightly integrated with Amazon Web Services through AWS OpsWorks. This means that the Chef code used to automate physical servers or workstations can be used to configure AWS resources. This ability to standardize both physical and cloud environments means that it is possible to create a smooth workflow for both Development and Support teams.

Our Grad Project take-aways?

From experiencing work in a support team, we can see the benefits of embracing a DevOps culture and workflow. The ability to standardize environments means that Development teams are free to implement new technologies that can then be easily transferred and controlled by support teams. Having completed Phase I of ‘Ready Steady Cook’, we aim to embark on Phase II- developing an automated setup for a specific aspect in the support team.

We have both gained valuable experience in working through a project’s complete lifecycle, from inception to development to testing and production. Throughout the project we utilised Agile methodologies such as working towards fortnightly sprints and daily stand-up meetings. This project has also widened the scope of our graduate training in that we have gained certifications in Chef and are working towards certifications in other DevOps technologies.

Sopra Steria is currently recruiting for the Spring 2018 Consulting and Management Graduate Programme. If you, or someone you know, is interested in a career with us, take a look here.

Have you heard the latest buzz from our DigiLab Hackathon winners?

The innovative LiveHive project was crowned winner of the Sopra Steria UK “Hack the Thing” competition which took place last month.

Sopra Steria DigiLab hosts quarterly Hackathons with a specific challenge, the most recent named – Hack the Thing. Whilst the aim of the hack was sensor and IoT focused, the solution had to address a known sustainability issue. The LiveHive team chose to focus their efforts on monitoring and improving honey bee health, husbandry and supporting new beekeepers.

A Sustainable Solution 

Bees play an important role in sustainability within agriculture. Their pollinating services are worth around £600 million a year in the UK in boosting yields and the quality of seeds and fruits[1]. The UK had approximately 100,000 beekeepers in 1943 however this number had dropped to 44,000 by 2010[2]. Fortunately, in recent years there has been a resurgence of interest in beekeeping which has highlighted a need for a product that allows beekeepers to explore and extend their knowledge and capabilities through the use of modern, accessible technology.

LiveHive allows beekeepers to view important information about the state of their hives and receive alerts all on their smartphone or mobile device. The social and sharing side of the LiveHive is designed to engage and support new beekeepers and give them a platform for more meaningful help from their mentors. The product also allows data to be recorded and analysed aiding national/international research and furthering education on the subject.

The LiveHive Model

The LiveHive Solution integrates three services – hive monitoring, hive inspection and a beekeeping forum offering access to integrated data and enabling the exchange of data.

“As a novice beekeeper I’ve observed firsthand how complicated it is to look after a colony of bees. When asking my mentor questions I find myself having to reiterate the details of the particular hive and history of the colony being discussed. The mentoring would be much more effective and valuable if they had access to the background and context of the hives scenario.”

LiveHive integrates the following components:

  • Technology Sensors: to monitor conditions such as temperature and humidity in a bee hive, transmitting the data to Azure cloud for reporting.
  • Human Sensors: a Smartphone app that enables the beekeeper to record inspections and receive alerts.
  • Sharing Platform: to allow the novice beekeeper to share information with their mentors and connect to a forum where beekeepers exchange knowledge, ideas and experience. They can also share the specific colony history to help members to understand the context of any question.

How does it actually work?

A Raspberry Pi measures temperature, humidity and light levels in the hive transmits measurements to Microsoft Azure cloud through its IoT Hub.

Sustainable Innovation

On a larger scale, the data behind the hive sensor information and beekeepers inspection records creates a large, unique source of primary beekeeping data. This aids research and education into the effects of beekeeping practice on yields and bee health presenting opportunities to collaborate with research facilities and institutions.

The LiveHive roadmap plans to also put beekeepers in touch with the local community through the website allowing members of the public to report swarms, offer apiary sites and even find out who may be offering local honey!

What’s next? 

The team have already created a buzz with fellow bee projects and beekeepers within Sopra Steria by forming the Sopra Steria International Beekeepers Association which will be the beta test group for LiveHive. Further opportunities will also be explored with the service design principle being applied to other species which could aid in Government inspection. The team are also looking at methods to collaborate with Government directorates in Scotland.

It’s just the start for this lot of busy bees but a great example of some of the innovation created in Sopra Steria’s DigiLab!

[1] Mirror, 2016. Why are bee numbers dropping so dramatically in the UK?  

[2] Sustain, 2010. UK bee keeping in decline

Building an Agile Organisation: lessons learned from Lean Agile Scotland 2016

I was lucky enough to attend Lean Agile Scotland last month, a 3-day conference in Edinburgh crammed full of fantastic key notes, talks and workshops covering all things Agile: from Value Streams to Cynefin, from TDD and BDD to Neuro-diversity, and from meeting culture to dark collaboration – #LAScot16 had it all.

Trying to summarise in one blog post all the lessons and thinking I took away has been tough, so I’ve focused on some interesting ideas from the conference which can help organisations build/maintain their Agile culture:

The role of management in an Agile organisation

The subject of management was touched upon by several speakers during the 3 days, including Marc Burgauer’s Eupsychian  Manager talk and Julia Wester’s Let’s (Not) Get Rid of Managers talk.

Marc Burgauer introduced many of the conference attendees to the idea of Maslow’s Eupsycian Manager (pronounced “you-sigh-key-un”), human-oriented management generated by self-actualised people (Eupsychian is defined as having or moving towards a good mind/soul). Marc highlighted that in age where most organisations strive for conformity and “same-ness”, there is not one right way to manage everyone. Each employee needs to be managed specifically to their needs in the moment and in a way fitting of their current context – in Eupsychian Management, one size definitely does not fit all.

Eupsychian managers make it easy for their employees to say No to them – this allows your employees to make you aware of anything you may currently be blind to in your organisation and so learn valuable information.

Euphysian managers also ask their employees, “What can I do to help you do your job better?”. This question clearly sets out from the beginning how the relationship between manager and employee will function.

Mirroring many of the sentiments of Marc’s talk, Julia Wester thoughtfully discussed how as more teams move to an Agile way of working (self-organising, no hierarchy), the traditional role of managers must move too. We still need managers in Agile environments but Agile management should focus on ignoring hierarchy and having managers just be part of the team – being seen as “one of the team” encourages feedback from your team members.

In an Agile environment, we should value individuals and interactions over processes and tools, therefore managers should treat their team as people, not just resources. One example of an organisation moving away from seeing their people as just resources is Google – they have renamed their Human Resources department to People Ops. When you value your people, you foster cognitive safety and create relationships based on trust which allows you not to micromanage.

Julia finished her talk with this important quote from Peter F. Drucker:

“Management is about human beings. Its task is to make people capable of joint performance, to make their strengths effective and their weaknesses irrelevant.”

The importance of Communities of Practice in an Agile (any!) Organisation

At Emily Webber’s Communities of Practice, The Missing Piece of Your Agile Organisation talk, highlighting the importance & value of having communities of practice in your organisation, I found myself nodding along in agreement at everything she said. Fortunately, Sopra Steria already recognises the importance of Communities of Practice, demonstrated by our adoption of a Community model earlier this year with communities ranging from Agile to Architecture.

So what makes a good community? Having Membership and Influence, while providing a Fulfilment of Needs and Emotional Connection. And why are they essential? People need to feel supported in their roles. We learn better when we learn together. Collaboration creates collective intelligence which is greater than individual intelligence.

When thinking about how you can get the most from your Community of Practice, use it as an opportunity to get together and:

  • Give presentations to one another and/or invite external speakers in to present on new thinking/innovation in your area
  • Practice new skills in a safe environment
  • Visit other organisations, if possible, with similar challenges and share learning

Many more lessons can be learned from Lean Agile Scotland 2016 and if you would like to learn more then all talks from the 3 days will be made available online – follow @LeanAgileScotland on Twitter or check www.leanagile.scot for updates.

If you have any thoughts on these topics, please leave a reply blow or contact me by email.

Bob Dylan was right about Digital Transformation

Bob Dylan is recognised as one of most influential writers of the 20th century.  He is not though, seen as an inspiration for the digital age. Perhaps he should be? With his 1964 song, “It’s Alright, Ma (I’m Only Bleeding)”, he states that “He not busy being born is busy dying”. With this line he couldn’t have been more prescient.

Organisations need to continually “be busy being born” and innovate or face the alternative.

Think about it: what differentiates companies hobbling along the digital highway from the ones paving the way? The ability to embrace change, refuse status quo and turn the business into an ever evolving entity. 

Put another way, being digital is about reconciling the pace of adoption of new technologies with the pace of their commoditisation. The latter recently experienced a dramatic acceleration, while the former is often stuck in old-world mode.

 

Old world versus Digital world

Twenty years ago, adopting new software was a big deal. There were limited numbers of vendors in each market segment. Software customisation or process transformation was necessary to take advantage of technology. Integration was complex, ongoing maintenance and support often presented challenges. All of this resulted in expensive acquisition costs, from both a financial and an effort perspective. Long-term supplier contracts were the norm.

Once software was installed, and the vendor proven, it was a lot easier for an organisation to allow the vendor to expand its footprint through additional modules and products rather than go back to the market to look for alternative solutions.

From a vendor perspective, selling and delivering software was costly requiring a large sales team to reach customers and negotiate complex contracts. Vendor delivery teams would need to be highly skilled building bespoke integrations to satisfy the specific needs of customers.

New software integration was expensive, risky and therefore needed careful consideration. Adoption pace was slow as software was seen as complex far from being a commodity.

Today, the pace of commodization has increased by an order of magnitude, mainly due to Cloud technologies. Let’s have a look: what does innovation mean today in the enterprise world? Big data maybe, machine learning and AI, blockchain or IoT?. All these have already been turned into commodities. Fancy running some machine learning algorithms on your customers database? AWS has an API for that. Conducting a first run shouldn’t take more than a few hours of work. Same goes for most of big data technologies, IoT, blockchain and even virtual reality.

as-a-Service paradigm

The as-a-Service paradigm has drastically reduced costs, complexity and risks of adopting new software and technologies. The SaaS model for instance through turning CAPEX into OPEX, has abolished any notion of commitment.

Should your company use this marketing software over this one? Who cares? Use both, allow yourself to pay a bit more for one month or two, then keep the one that perfectly meets your needs. Going further, why even consider it at company level? One department may prefer one software because it measures what they want in the exact way they want, while another department may prefer another one. With almost no acquisition and no integration costs, why try to over rationalise at the expense of business value and user experience?
Standardisation is still to be considered on non-differentiating applications, but at a much less prominent position.

The Digital highway

All this said, most of old world companies are still considering innovation with the same eyes as before, missing business opportunities and losing ground to new entrants.

If conducting an IoT experiment means running an RFP, conduct a 6-month PoC and sign a multi-year contract, then you may be doing IoT, but you’re still hobbling on the digital highway.

Velocity is key to transforming your company into an ever evolving, fast learning, business.

“He not busy being born is busy dying

Thanks to Clara, Gavin, Jian and Robin for their kind guidance.

More on the subject:

What do you think? Leave a reply below or contact me by email.

Image courtesy of Getty Images