Initiativesofagile

The key to doing DevOp well is to realize that this is going to make everyone change perspective.

With Agile emerging as a mainstream software project methodology and management philosophy, DevOps has also become the culture thing in many forward-thinking IT organizations, culture is the collective mindset, culture is the habit, culture is how people think and do things in the organization, so how does exactly DevOp influence IT organization’s execution and performance? DevOp Culture: Are you Ready?

DevOp is a mind shift not only in the way products are developed but also the way is supported; developers and operation staff should be in lockstep from the conceptualization phase, in this way specific needs required by the operation teams are integrated during the development of the solutions, automation, monitoring, performance, etc. Another key element that will influence how the product evolves is the feedback loop needed to continue to enhance the software.

DevOps, as a technical discipline allows IT to short-circuit a lot of the longer human-oriented processes and automate things; so instead of increasing the supply of humans on the supply side, which is never going to happen, DevOps allows IT to decrease the demand for the labor market, shifting it inward. Although overall DevOps is still in a growth phase to make corporate cultural differences, and there are unreasonable expectations in some organizations because there are major gaps in talent and knowledge. There are generally gaps in DevOps operations due to flaws in configuration management. DevOps is still being driven by the front office. The skills required for an automated and integrated service-centric team require collaboration and scripting (coding), configuration, application, and networking skillsets.

The key to doing it well is to realize that this is going to make everyone change perspective. Cloud-enabled it but the real change is that where IT (architecture, development, operations) used to think single-threaded, they now have to think multiple streams. So to lay DevOps issues solely on the applications is somewhat misleading. There are changes necessary throughout IT. Infrastructure, Network, Applications, Architecture, Sourcing, etc all will need some changes. The connection to business value is still an issue for all of IT to solve. For example, more often, infrastructure is well managed along a single dimension, cost reduction. And like any organization with cost as the primary driver, the focus is on avoiding change. The less change the more efficient you can become, but in order to run IT effectively, consolidation, integration, and optimization are all necessary steps in improving IT maturity.

There are also knowledge & skill gaps. For some entities, there is a lack of clarity among engineers who lack the aforementioned skills in agility that work to move the entity forward. DevOps requires use cases and architectural principles to support transformative technologies. When there is a knowledge gap then an enterprise is dragging the anchor effect impact. There are often information breaches when mistakes are made which leads to malaise and confusion within DevOps whereby QoS, SLA's and performance are impeded and a lot of finger-pointing. Hence, continue to tune the IT organization by questioning: What has your infrastructure changed to accommodate development? When they wanted a test instance did you fight it? How are you supporting their benchmarking? Do you help them assess the risk of a release? Do you review your capacity restraints with them? Have you asked them what functionality they plan over the next year? Have you looked at your SLAs and created a business justification.

Organizations create "DevOps frameworks" that are so complex to use; and the projects that use them lose productivity - instead of gaining productivity, and after trying it on several other projects, the organization abandons the framework. Very smart people create these frameworks - but the only people who can use the frameworks are their creators and no one else. And these frameworks are often completely undocumented, in the spirit of "test-driven development"

DevOps is occasionally used as an excuse for undisciplined behavior, so does AGILE. The logic steps need to be taken, especially for the large-scale DevOps project, so the project goal needs to be well defined, and responsibility shall be well assigned:
(1). Having DevOps consultants to oversee the transformation.
(2). Business analysts to translate corporate goals down to Development and Operations Teams.
(3). Integrated testing analytics, so testing takes place in real-world scenarios
(4). Change managers to work day-to-day with integrating the various global teams involved in all aspects of application development, deployment, and on-going operations
(5). HR to coordinate talent management with IT management and staff
(6) PMO to oversee and integrate all the moving parts, and to ensure timeline and quality.
(7) metrics to manage quality in the S.M.A.R.T way and the worst type of negligence is not measuring quality because the "process" doesn't like it.

The DevOp culture can’t be built overnight, like all kinds of Change Management effort, there are friction and low success rate. Still, it enforces Agile methodology and practices, it provides a significant opportunity to run IT in a more holistic and integrated way, hence to improve IT effectiveness and maturity.