Out of sheer necessity, IT startups and small companies have simplified departmental structures, and their focus is narrowed to a few specific products/services. This is the ideal environment for agile IT methodologies and where the DevOps ‘movement’ was born.
The shift to DevOps is ‘in the making’ by Corporate IT for quite a while. This topic raises the discussion: ‘Can every company really act as a startup?’
Take the main IT teams (Development, Quality Assurance and Operations) for example. The idea behind DevOps will push for a different kind of resource arrangement:
Take the main IT teams (Development, Quality Assurance and Operations) for example. The idea behind DevOps will push for a different kind of resource arrangement:
Some arrangements like DEV does all OPs, may seem a little stretched. But have become possible on the last couple of years with the Cloud (PaaS and SaaS) dissemination. In fact most of the Operation Departments struggle to contain Shadow IT inside organizations.
At first glance Mixed and Multivalent scenarios seem similar. But the first scenario splits specialized resources between teams. The second promotes interdisciplinary knowledge for each resource (is this even viable?). In fact the new resource arrangement can lead to independent smaller teams that will tackle different projects, on opposition to specialized single purpose larger teams.
The last arrangement (at least of this bunch), is where a separate DevOps Team is assembled, (usually with the most capable resources), matches pilot projects or autonomous teams that are hard to scale.
However, all the scenarios have one often neglected consequence: the organization structure has to shift alongside with the resource arrangement. Siloed structures have to be broken and organizational change is mandatory. DevOps should be a top-down engagement beginning with structural changes, where the Ops team is no longer adverse to SW changes and participates actively on the solutions and the DEV team has concerns for non-functional requirements like performance and security on the early stages of development.
DevOps is about joining teams and removing barriers in order to improve collaboration and knowledge about different disciplines among each area.
This approach will improve the QUALITY and ROBUSTNESS of the products/services.
Have in mind that there is no Tool that can provide this.
Another ‘recent’ trend on the DevOps Landscape is SPEED: The need to rapidly produce software products. This is where new tools and agile methodologies come into place.
But, are the advertized tools a new thing? Application Lifecycle Management (ALM) is not new! And covers all SW engineering stages from requirements to release management (including continuous integration, test automation, automated deployment...)
Somehow ALM has been rebranded into DevOps. This is not a bad thing… Since organizations become more aware and willing to experiment new tools and practices.
Truth be told, ‘old’ ALM Suites are agnostic to team composition or expertise, this can promote team segregation (DEV|QA|OPs), and that is the sweet spot where DevOps can help to change in an integrated and agile fashion.
DevOps may be ALM revamped from a human collaboration point of view, but is here to stay!
At first glance Mixed and Multivalent scenarios seem similar. But the first scenario splits specialized resources between teams. The second promotes interdisciplinary knowledge for each resource (is this even viable?). In fact the new resource arrangement can lead to independent smaller teams that will tackle different projects, on opposition to specialized single purpose larger teams.
The last arrangement (at least of this bunch), is where a separate DevOps Team is assembled, (usually with the most capable resources), matches pilot projects or autonomous teams that are hard to scale.
However, all the scenarios have one often neglected consequence: the organization structure has to shift alongside with the resource arrangement. Siloed structures have to be broken and organizational change is mandatory. DevOps should be a top-down engagement beginning with structural changes, where the Ops team is no longer adverse to SW changes and participates actively on the solutions and the DEV team has concerns for non-functional requirements like performance and security on the early stages of development.
DevOps is about joining teams and removing barriers in order to improve collaboration and knowledge about different disciplines among each area.
This approach will improve the QUALITY and ROBUSTNESS of the products/services.
Have in mind that there is no Tool that can provide this.
Another ‘recent’ trend on the DevOps Landscape is SPEED: The need to rapidly produce software products. This is where new tools and agile methodologies come into place.
But, are the advertized tools a new thing? Application Lifecycle Management (ALM) is not new! And covers all SW engineering stages from requirements to release management (including continuous integration, test automation, automated deployment...)
Somehow ALM has been rebranded into DevOps. This is not a bad thing… Since organizations become more aware and willing to experiment new tools and practices.
Truth be told, ‘old’ ALM Suites are agnostic to team composition or expertise, this can promote team segregation (DEV|QA|OPs), and that is the sweet spot where DevOps can help to change in an integrated and agile fashion.
DevOps may be ALM revamped from a human collaboration point of view, but is here to stay!