A Need for Speed: Rapid Digitisation

With business environments rapidly changing, there is a need for companies to respond as quickly as possible to competition and new opportunities. This means that organisations have a “need for speed”: with the aim to get a digital service on to the market that can help build momentum and offer real value to stakeholders and the organisation in general.

Of course, producing this service at a fast pace should not be reckless and unorganised as this could be counter-productive in the long term. That’s why Arrk Group has created its own rapid digitisation service to help deploy the minimum viable product as quickly as possible – without sacrificing quality.

What is the concept behind rapid digitisation?

At the heart of the Rapid Digitisation Service is the idea that the service is structured but also flexible and built around the individual user. It brings a focus to a new digital initiative and aims to produce a working application within three months. The hope is that it will deliver business value where it is most needed while also offering high returns at a low cost.

How is it done?

Rapid Digitisation is centred on Agile architectural practices. Its incremental development lifecycles help deal with the pressures of delivering high value capabilities while maintaining both productivity and speed.

Can speed and stability truly be balanced?

Achieving and maintaining software development so that teams can deliver a standard of releases that stakeholders will truly value and that makes sense for the business, is one of the real challenges of rapid digitisation.

For this to be achieved it is necessary to take a different approach for each company. Processes, architecture, tool environments and team structures are designed to support efficient and sustainable feature development. The idea is that all aspects of the organisation – including management, stakeholders and development teams – should have a clear idea about the desired results so that there is no risk of over optimisation or any risk that they will stop working on achieving the desired outcome.

Train Blur 400

Typically in environments that are highly regulated – such as those related to financial services, healthcare, software development and avionics – it is highly possible that software developers may be interacting with quality assurance teams and other deployment areas that work under different tempos. As such, it is their responsibility to apply a host of different tactics to deal with the significant slowdown of delivery that follows periods of high velocity. This will often include applying practices associated with Agile architecture with those from other areas.

Agile architecture boasts a host of practices that help to enhance stability and speed, including:

  • Release planning: With release planning taking into account architectural considerations, the feature release process can be extended by adding information to the description document.
  • Prototyping: The idea here is to extend demo user practice with a focus on quality attributes. This includes focusing on security and performance.
  • Roadmap/Vision: Incorporating an analysis of external dependency this reduces the risk of being hit with unexpected external changes.
  • Test-driven development: Merging test-driven practices this looks at runtime qualities including scalability, security and performance. It includes continuous integration and test-driven development which is completely automated.
  • Technical debt monitoring: Merging quality attributes, including security, reliability and performance, with a tracking of technical debt. This goes beyond functional correctness and defects.

Problems that the rapid digitisation service can solve

Based on feedback from various organisations there are several factors which have got in the way of developing teams, preventing them from delivering software products rapidly in the past. These have generally stemmed from inconsistent or incorrect application of architecture or Agile practices.

Some of these include slow business decisions; problems that come from the challenges posed by dependency management; limitations to the measurement of technical debts; and a desire for factors that will limit stability-related work and requirement analysis.

So can rapid digitisation work for your organisation?

There is little doubt that agile architecture can help organisations establish stability with their systems. However, before investing in a rapid digitisation service it is important to think about the main causes of why there has been a failure to deliver at the pace expected; and how to manage the differences between stability and speed.

The first step is for organisations to make these issues visible to their developers, as well as management and stakeholders. Discuss the issues and see if there is anything that can be done “in-house” to deal with these situations. Then, when considering whether to combine architecture practices and Agile, organisations should consider a number of factors, such as: will our existing technical roadmap potentially address these long- and short-term issues? Also, is software being delivered at the necessary pace to customers; is the organisation aware of any problems that may crop up by not focusing on architectural processes when Agile is employed; and does the development team have the skills necessary to successfully implement this architecture and Agile? Also consider whether or not you have the visibility needed for the system: both in terms of project management and in delivering the quality that is expected.

By considering all of these factors, organisations can truly take into account the conflicting demands involved with rapidly developing software that is stable, reliable and flexible. If done correctly, the potential for any organisation with rapid digitisation is substantial as it helps get something real out of the door as quickly as possible, building momentum and providing real value to the organisation and stakeholders as quickly as possible.

Share this article








Submit
Originally Published:

Authors