The key challenge for any digital company looking to scale up is how to raise revenue without increasing core costs. The easy solution is to increase team productivity. However, doing so without risking burnout, system instability, or significant amounts of technical debt isn’t easy. This is where DevOps approaches to work come into play. The crown jewel is a common self-service approach to contemporary operations. According to the National Institute of Standards and Technology (NIST), on-demand self-service has long been regarded as an important feature of cloud computing. However, it is one of the most difficult cloud-based capabilities to deploy.
The ecosystem of DevOps tools is enormous. The ‘periodic table of DevOps’ from Digital.ai (previously XebiaLabs) has over 120 products divided into 14 categories. Expecting each team to tackle such complexity on their own creates redundancy and waste. The problem becomes much bigger when you consider the rising amount of cloud provider services (175+ for AWS and 600+ for Azure). Curation is required, which entails selecting a collection of tools and making them available to delivery teams as self-service platforms. This does not imply that a central team purchases a “Enterprise DevOps Platform” and then requires and enforces its use. From the standpoint of the delivery team, this strategy has several advantages. Each time they need to integrate a key service or feature, they don’t have to recreate the wheel. They don’t even have to send a request to a different team. Instead, people should just take what they require, when they require it, and pay for it as they require it. Even more, essential organizational concerns like security, governance, and compliance are all ‘built-in’ to the platform. Is this to say that a DevOps team doesn’t require operations engineers? Probably not. DevOps is not a team structure model, but rather a mindset. It doesn’t always mean that development and operations people are on the same team.
In any tech scale-up, the ability to accelerate software development while maintaining system stability and resilience is critical. To do so, developers must consider operability, and operations engineers must make fast innovation possible. They may work together in a multidisciplinary team. They don’t have to, though. Platform-based services can be provided by a distinct operations team using an overall Platform as a Service structure. Consider the Site Reliability Engineering concept developed by Google. Application SREs are in charge of managing the application, whereas Platform SREs are in charge of developing the common tools. They collaborate with the application delivery (product) teams in distinct teams.
A platform-based strategy brings a selected set of common toolchains into one place. This minimizes the margin for mistake and improves the consistency of operability and security across the organization. Platforms make it easier to develop new features or apps and to manage them in the long run. It’s simpler to reach the optimal team size of seven plus or minus two when shared self-service functions are provided individually. This improves team cohesion, whether team members are working on product delivery or the operations platform.
Self-service operations eliminate the need for delivery teams to raise tickets or wait for client requirements. Eliminating dependencies is essential to modern working methods, since it allows for greater autonomy, faster development, and less waste. Product delivery teams have direct access to enabling services like security and compliance, as well as test automation and continuous delivery. A specialized platform team manages all of these fundamental services, which are supplied as code. This method of handling them provides more uniformity, cost control, and governance.
This provides a means for scale-ups to improve product operability, resilience, and security while improving development velocity. It will also decrease the danger of incurring additional technological debt. At the organizational level, overall standards are managed and optimized. As a result, delivery teams can concentrate on providing genuine customer value that encourages loyalty and differentiates them from the competition. They can adapt and iterate products with confidence, knowing that the infrastructure is in good hands. Reference architectures can be included in self-service platforms to help with best practices. It is possible to improve the self-service model even further when it is paired with an InnerSource approach. In a nutshell, this strategy allows platform services to develop over time in response to the demands of delivery teams. The platform team creates the self-service platform and then makes the source code available through a code repository (repo). They are in charge of the repo’s overall upkeep from here, although anybody can contribute.
As a result, if a delivery team needs to expand anything produced by a platform team, they may do it themselves. The needed modification is coded, then submitted to the platform team as a pull request, much as in an open source project. The modification can be integrated into the main codebase after it has been evaluated and accepted. This is, in many respects, the gold standard for DevOps. Colleagues in development and operations work together in a synergistic and collaborative manner. Everyone is aiming for the same thing: providing value-driven consumer experiences through dependable digital goods that match current demands. The final result is dynamic, fast, and secure innovation, giving your company a competitive advantage.
