Continuous innovation is only possible when supported by well-designed and flexible software. To innovate, businesses need to be able to experiment. Therefore, to achieve experiments fit for innovation, they need to be relatively easy to complete at a low cost. Systems should be initially designed so that experiments can be self-contained and completed with minimal impact on business as usual.
Businesses need to have software that allows for innovation to keep up with consumer demands and ensure they can compete in a demanding market. The following article highlights how a business can support creating well-designed and flexible software fit for innovation, split into product, process and implementation.
Creating a start-up mentality to utilise fast feedback loops
Lean start-up is a methodology for developing businesses and products that aims to shorten product development cycles. This business methodology emphasises customer feedback over intuition and flexibility over planning. In use, companies can recover from failures more often than during traditional ways of product development, reducing market risk and sidestepping the need for expensive product launches and financial shortcomings.
The Lean start-up mentality compliments the use of fast feedback loops. One of the most critical points to creating good software is communication, and feedback loops are used to get feedback about the software development process. Feedback isn't limited to positive points, but also the negative ones that don't align with the business need. Completing a feedback loop as fast as possible speeds up and improves the overall development process.
The most critical thing to creating good software is communication. Feedback loops are mechanisms that are used to validate product ideas and refine the software development process. The goal is to make positive and negative feedback immediately available to the teams. Doing this as fast as possible speeds up and improves the overall development.
Using Feature flags to allow for Innovation
Feature flags are a software development technique that turns functionality on and off during runtime without deploying new code. It allows for better control and more experimentation over the whole lifecycle.
The purpose behind this technique is to build conditional features into code to make logic available to certain groups of users at a time. If the flag is on, new code is executed – If the flag is off, the code can be skipped.
The benefits of feature flag use can be as follows.
Feature Flags allow development teams to test new features during production whilst mitigating the risk of a poor initial release, as the feature can be rolled back quickly if necessary. This process allows the functionality of new releases to be validated in the real world with accurate user testing while minimising the risk.
- Quicker release cycles
Teams can modify a system's behaviour without making disruptive code changes to live code, therefore, not impacting other teams. In addition, feature flags create a simplicity to deploy in the development process, saving time.
- Continuous deployment
Feature flags carry the ability to allow for quick learning. This will enable businesses to continuously deliver and deploy software to their users in a faster way. Organisations often use feature flags to perform gradual feature rollouts, fix bugs in the code without redeploying and experience a more streamlined development cycle.
- Feature Gating
Feature flags can be used to implement targeted rollouts of a feature specific to a subset of users. This feature can be great for A/B testing, but it can also be used to release features to only a subset of customers.
Experiments are needed to create innovative software. Taking feedback and data from the actual audience helps to understand priorities and needs. Using A/B testing, teams can generate this data. A/B testing can be implemented using feature flags, as mentioned above, as well as other ways such as using API gateways that conditionally route traffic to different deployments. By enabling a feature for half a segment of users and disabling the feature for the other half, the business can understand how the two perform against each other for a certain metric.
A/B tests can be implemented to specific segments of audiences, for example, users that live within a particular country or fit a specific user profile.
Infrastructure as code
"Infrastructure as code (IaC) is the managing and provisioning of infrastructure through code instead of through manual processes."
Managing IT infrastructure is a manual process. This includes high overhead costs and communication complexity, creating barriers to innovation without significant investment due to commitment, such as building and maintaining data centres. This also impacts scalability; with manual configuration needed, this creates problems during peak times.
How does infrastructure as code solve these issues, creating a space for innovation? Using cloud computing frees the business from having to build and maintain data centres (and the high costs associated). Before IaC, IT teams would have to manually change configurations to manage infrastructure. Whereas IaC allows your infrastructure‘s configuration to take the form of the code file. This creates benefits such as
- Lower costs
Benefits that can translate to being more flexible and adaptable to changes in consumer demands and changes in the marketplace.
Elastic scaling is the ability to adjust capacity to maintain steady, predictable performance at the lowest cost possible. As mentioned above, this is a manual process with on-premise infrastructure that involves commitment and significant time investments. With the cloud, you can automate this process to adjust capacity as you need it. For example, this would involve large peaks over holiday seasons such as Black Friday or Christmas for the E-commerce industry.
It allows businesses to automatically maintain performance as designed, creating availability during unpredictable times. In addition, there are cost efficiencies through only paying for the resources you need. As demand drops, so does the excess resource capacity to avoid overspending.
Visibility is an additional benefit, as a business is able to use the data to understand its performance needs. Helping to understand at what stage innovation is possible and give them the data to stand out in a crowded market space.
Modular architecture – localised experiments
Modular Architecture is a way to manage the complexity of a problem by breaking it down into smaller manageable modules. Modular Architecture is a style that helps view the system, not just in layers or services but goes one level below, as parts are split into smaller, physical modules. These modules are confined within the context they are provided.
This style is to create an environment ripe for testing and experiments. Teams can work within closed-off modules to ensure experiments are limited to one environment and don’t impact business as usual, or change code another team may need for their system.
Intelligence gathering baked into architecture and design.
Observability empowers developers to use a data-driven approach across the entire software lifecycle. This enables developers to plan, build and deploy software that underpins great user experiences.
What does this mean in practice, and how does it help innovation? Observability helps improve planning cycle times, decreases change failure rates and increases release frequency. For a business to be successful in innovation, and in performing well against competitors, being able to put releases in the hands of consumers first is a must.
With a data-driven approach, developers, and businesses are able to get past the what, to uncover why. Meaning they can focus on the higher-priority, business-impacting code to get to the solution faster.
Using data and tooling to observe the behaviour of a system, before, during and after development to learn about its patterns helps understand how it will behave in front of its user. This can then improve and impact the way the software behaves with the users. Take, for example, event-driven architecture is when a change in state triggers the creation of an event. These events are detected by one or more event consumers which react accordingly. For example, when an item is added to a customer's cart in an e-commerce platform, an event producer could trigger an event detailing that action. An event consumer, meanwhile, might subscribe to this producer and update the inventory to reflect the change in product availability.
Producers and consumers are managed independently of one another, meaning this decoupled nature enables the development to achieve resilience, scalability and maintenance benefits.
The ability to gather this intelligence from a series of quick experiments enables data-driven decision making, reducing inefficiencies and speculation, and as mentioned above being more efficient.
Making the most of techniques that exist to make software, easier to change, more evolvable and flexible means that changes through experimentation and data are easier to conduct successfully and more securely. Experimenting with software shouldn’t be impacting the business as usual, but should be supporting it. Understanding how your audience wants to behave with your software is a good step to continuous innovation for the right reason.