It is generally accepted that folks in the domestic IT community are pretty accomplished. Today’s digital-centric business operations depend on them; and at the same time, they produce at-large systems stability ratings on the order of 93%, or more, day after day.
However, regardless of the aforementioned cultural and statistical values to date, there are various flies in the ointment when it comes to newly-emergent software methodologies; how best to apply them; and particularly, in the case of DevOps as an evolving technical culture. To reiterate, as currently understood the DevOps methodology is driven by direct, enterprise-wide, collaboration between operations, development, and quality assurance.
When considering any legacy organization chart, however, these departmental participants behave discretely, and typically respond as parts of an iterative framework, creating linear solutions. In simple terms, this means that operations keep the lights on; development creates new systems and utilities that enhance, and/or support, operations; and quality assurance validates both of these administrative and technical efforts.
However, DevOps calls for daily interoperation between these technological stakeholders, while at the same time organizationally blending their responsibilities enterprise-wide. These impacts, if handled badly, can create various internal conflicts that lead to lost business efficiency, and worse the limitation of, or even critically damaging, bottom-line revenues.
These impacts are why DevOps consulting is necessary to the “new world” of development; and on the other hand, why the potential of allowing legacy enterprise technologists to “go it alone”, when considering the implementation of a DevOps culture, is a really bad business idea. As a series of scenarios here are some areas of concern.
Legacy is as legacy does:
As previously suggested; legacy organizations typically call for vertical integration within a presumably consolidated operating framework. Consequently, the more mature a company is, the harder a “captive” DevOps representative will have to work, in order to break down, and/or replace, deeply averse implementation cultures and operating tenets.
Further, regardless of an internal representative’s quality, a “captive” employee will still be prone to the same intellectual biases, and potential misunderstandings, like any other technical participant who is embedded within an enterprise culture. This can lead to festering personal problems that can quickly clutter or misdirect important work at hand.
At the end of the day, then, if a proposed DevOps methodology is not designed, taught, trained, and implemented as a “fresh-eyed”, and highly-cohesive effort, the risk of achieving an enterprise’s goals will be high, and the potential of wasted money will be even higher.
This is why DevOps consulting services exist, and why DevOps teams exist to help enterprises go to the next level; efficiently, and with a minimum of cost to the enterprise.
Risk is just that; do it right the first time:
As the old business saying goes; “there’s never enough money to do it right the first time, but there’s always enough money to do it over.” As a practical matter then, any suggestion of allowing an IT employee to lead a DevOps implementation round is on the order of putting $100,000 on black, while being entirely committed to a misbelief that the roulette wheel always tends to favor the bettor.
DevOps consultants do their work every day, and as a general rule, these professionals produce outstanding results globally. This assertion is a statistical fact since the recent 2016 State of DevOps report, produced by Puppet and Dora illustrates that cost-saving in IT re-works alone have been reduced by a global average of 45% over the last two years, while at the same time the metric has translated to the development of new systems development.
So, in a world where time is literally money, the goal is to do it right the first time; by letting the professionals do the teaching and mentoring, while the enterprise reaps the advantage.
The DevOps methodology represents new ways to create, retrofit, and up-scale enterprise software systems. This developmental approach is driven by human collaboration, innovation, and experience; supported by cadres of professional DevOps consultants.
While the enterprise itself is an engine of commerce, and its ops, development, and QA departments are the guardians of that engine, in some cases the smartest thing to do is avoid any necessary risk, particularly when it involves a complete alteration of its core operational culture.