When you look at the origins of DevOps you can see why so many established enterprises struggle with the practice. Many of the DevOps agile and lean practices originate from ‘born on the internet’ companies. These companies have had the opportunity to create their systems and infrastructure to meet the demands of continuous integration and delivery, from inception.
But mature organizations with legacy IT find it much harder to remap their architecture, infrastructure, organizations and operations to get closer to a DevOps delivery model. This has left many large enterprises caught in what Forrester calls ‘water-SCRUM-fall’ methods that have limited agile or lean capabilities.
For traditional financial institutions (FIs) acquiring DevOps capabilities begins with assessing their current maturity and determining key blocking points for achieving DevOps goals, both short and long term. This enables firms to set a roadmap of achievable DevOps capability growth factors that also support a continuous adoption of DevOps practices.
Debt from an organization’s architecture footprint is typically underestimated or completely ignored. Poor prioritization of Enterprise Architecture (EA) activities and low EA maturity leave many IT departments with a mixture of patterns and frameworks that conflict or duplicate solutions delivering the same function.
Typically, the platforms and technologies running within legacy IT frameworks have not been selected with a DevOps delivery model in mind. Choosing a ‘load balancer’ for an organization automatically creates architectural debt from a delivery pattern perspective as modern scalability is expecting a lot of these functions to be integrated into the application delivery infrastructure itself. Making the choice to standardize on F5 load balancers, for example, will impact the planning and refactoring of the applications and code that depend on these functions to leverage the full capabilities of the F5 solution. It starts with these basic decisions on infrastructure and turns into how the architectural debt builds in organizations. DevOps adoption needs to push for a re-examination of some of these choices and standards to avoid being saddled with this debt from the start.
Many large enterprises also use multiple frameworks. Less than a third of firms with 5,000+ employees have a single standardized application framework. It is rare to walk into a large bank that is strictly a ‘Java shop’ or a ‘.Net shop’ for application development and delivery. If you add network frameworks from Cisco and virtualization frameworks from VMware, the competition for architectural dominance becomes even more challenging. In many cases multiple frameworks are also used within categories. This means that technologies and platforms are already trying to deliver on competing requirements from many masters.
In short, unless enterprises advance their EA practices and move towards a single framework model across many infrastructure categories they will find it hard to reduce architectural debt.
IT departments have evolved quickly over the past decade to embrace virtualization, containerization and integration with private/hybrid cloud patterns. However, fully-performing software-defined functions within these large environments still elude IT management frameworks. Delivering consistent platforms across development, test, QA and production has not been achievable on a consistent basis.
Where only ‘pockets’ of software-defined networking or software-defined storage are available, firms rely on other elements in the infrastructure and tools to manage these resources. In addition, enterprises find it challenging to document existing infrastructure and end up lagging behind the ‘as-built’ environment. This becomes an ongoing liability for software development teams trying to leverage infrastructure resources.
Modern software development in a DevOps model is no longer just a language to create code. The language now sits at the core of a series of repositories, management nodes, agents and reporting components that enable coders to develop, integrate, test and deliver on very short schedules. The more an organization can set its infrastructure implementations into software-defined templates that are consistent across environments, the smoother the transition of code between these stages.
Devices and tools can also disguise technical debt. Out of date drivers, firmware levels and tools in can lead to unexpected software delivery results that are difficult to trace, locate and solve. Such IT environments that are not maintained properly can disrupt the ‘continuous’ operations of DevOps.
DevOps practices can also significantly change the loading volumes on key infrastructure components. The frequency of DNS calls could increase sharply and any issues that are generating DNS errors could spike with the increased traffic and create extra latency for these requests. Similar issues can occur with changes in network volumetrics against TCP services, web services, firewalls, databases and LDAP (Lightweight Directory Access Protocol). Enterprises that lack monitoring tools and cannot view activity levels for individual components in the infrastructure will struggle to uncover and resolve these issues.
To recap quickly, organizations are aggregating technical debt from the following sources:
An analysis of these debt sources as part of the overall DevOps maturity assessment and the addition of tools and processes to help mitigate the impacts of these factors are an important milestone along the DevOps maturity roadmap.
Craig Borysowich is a Senior Consultant, based in Toronto. His current focus is developing and deploying modern infrastructures and technologies to enable quality application architectures. Craig has published multiple thought leadership articles in technical journals and is regularly invited to speak at industry conferences and symposiums. His particular expertise includes blockchain / cryptocurrency, IOT / IOE, big data / analytics, digital technologies, API, Agile / Lean, DevOps, cloud, IaaS, PaaS, SaaS, payment solutions and wearable technologies.
The content and opinions posted on this blog and any corresponding comments are the personal opinions of the original authors, not those of Capco.