Mature organizations struggle with DevOps, but there are plenty of ways to beat ‘technology debt’ and related challenges.
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.
ARCHITECTURAL DEBT FROM INFORMATION TECHNOLOGY
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.
TECHNICAL DEBT IN INFRASTRUCTURE
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.
SUMMARY OF ARCHITECTURAL AND INFRASTRUCTURE TECHNICAL DEBT SOURCES
To recap quickly, organizations are aggregating technical debt from the following sources:
Low enterprise architecture maturity or priority for adoption of standardized patterns
Too many horizontal or vertical architecture/technology frameworks in the infrastructure that are competing for resources and support
Poor or outdated documentation for operating environments
Lack of monitoring and insight into infrastructure components involved in the end-to-end delivery of solutions
Low traction of ‘software-defined infrastructure’ capabilities that enforce standards across environments
Varying levels of infrastructure maturity and adoption/integration with private and hybrid cloud services with scalable support of virtualization and containerization technologies
Out-of-sync patching, firmware updates and driver levels across platforms and tools
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.
REFERENCES:
http://sdtimes.com/analyst-watch-water-scrum-fall-is-the-reality-of-agile/
https://www.forrester.com/report/WaterScrumFall+Is+The+Reality+Of+Agile+For+Most+Organizations+Today/-/E-RES60109
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.
ARCHITECTURAL DEBT FROM INFORMATION TECHNOLOGY
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.
TECHNICAL DEBT IN INFRASTRUCTURE
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.
SUMMARY OF ARCHITECTURAL AND INFRASTRUCTURE TECHNICAL DEBT SOURCES
To recap quickly, organizations are aggregating technical debt from the following sources:
Low enterprise architecture maturity or priority for adoption of standardized patterns
Too many horizontal or vertical architecture/technology frameworks in the infrastructure that are competing for resources and support
Poor or outdated documentation for operating environments
Lack of monitoring and insight into infrastructure components involved in the end-to-end delivery of solutions
Low traction of ‘software-defined infrastructure’ capabilities that enforce standards across environments
Varying levels of infrastructure maturity and adoption/integration with private and hybrid cloud services with scalable support of virtualization and containerization technologies
Out-of-sync patching, firmware updates and driver levels across platforms and tools
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.
REFERENCES:
http://sdtimes.com/analyst-watch-water-scrum-fall-is-the-reality-of-agile/
https://www.forrester.com/report/WaterScrumFall+Is+The+Reality+Of+Agile+For+Most+Organizations+Today/-/E-RES60109