Is it Enterprise DevOps or DevOps in the enterprise?  I guess it all depends on where you sit.  DevOps has been a significant change to how many modern technology organizations approach systems development and support.  While many have found it to be a major productivity boost, it represents a threat in "BTTWWHADI" evangelists in some organizations.  Let's start with two definitions:

Where we come from...

If we look at some successful Enterprise technology areas, they have had long term success by sticking with what works.  Cleanly partitioned technical responsibilities (analysts, developers, DBAs, network admins, sysadmins, etc.), a waterfall approach to development, a "stay in your lane" accountability matrix (e.g., you write the app, I'll get it platformed), rack 'em and stack 'em approach to hardware, etc.

While no one can deny this type of discipline has served many well, Enterprise technology's current generation offers us a much more flexible approach.  Today, virtually all hardware is virtualized (on and off-premise), and cloud vendors offer things like platforms as a service, databases as a service, security as a service...etc.   These innovations have allowed my companies to completely re-think how they want to be spending their technology resource (budget, people, mindshare)….with the most enlightened organizations quickly concluding that they should spend their human capital in spaces where they can create competitive advantages while purchasing those parts of their technology ecosystem what more commoditized.

An example of this would be in a retail company to think more about creating business intelligence than setting up new hardware for a database server.   A database can be scaled in the cloud, leaving the retail enterprise more human capital to figure out how to drive revenue.  Those who are not embracing the change DevOps affords are most often using a BTTWWHADI argument.  

Not everyone is ready for a revolution...

So, if DevOps is such a revolution, why do you have so many corporations having such an issue trying to get DevOps strategies to work for them? The answer lies in culture. For DevOps to be effective, an organization needs to be willing to take out a blank sheet of paper and draw a picture of what could be if they tore down yesterday's constraints and looked toward today's innovations. They need to match that picture up against their current staff, recognize that many jobs (and many skills) need to be re-learned or acquired.  No longer is so much specialization required in many specific fixed assets (like data centers, computers, network devices, security devices, etc.) In a modern DevOps world, much of the infrastructure is virtualized (giving rise to infrastructure as code).

To some extent, this means that your infrastructure staff will start to look more and more like developers.  Instead of a team plugging in servers, routers, and load balancers into a network backbone, they will be using scripting to configure equivalent services on virtualized hardware. On the development and operational side, CI/CD pipelines and process automation drive out many manual processes involved in yesterday's software development lifecycle. For development, the beginnings of this revolution date back to test-driven development. Today's modern pipelines go from development through testing, integration, and deployment. While everything is automatable, many have stopping points in their pipeline where human interactions are required to review test results or require confirmation about final deployments to production.   Whether you are in infrastructure or development, BTTWWHADI just won't do and more.  To compete, everyone will need to skill up and focus on architecture, automation, XaaS, and scripting/coding to decrease time to market while improving quality and resilience.

So, what's the big deal…

DevOps can be a threat to those who aren't ready for it (the BTTWWHADI crowd).  If your job is configuring hardware or running manual software tests, you might see these functions being automated into 'coding' jobs.  This function change could pose a severe career problem for those team members who don't see this evolution coming and fail to get prepared through education and training.  Unprepared staff becomes resistive to change (understandably), yet, those who are prepared end up in a better position (read: more career security, mobility, and better paid) as automation experts are now far more sought after than traditional hardware configuration engineers (as a gross generalization).  Please do not misunderstand; traditional system engineers are still valuable members of most enterprise teams, but as DevOps and virtualization take hold, those jobs will change.  Get prepared, train your staff, and address the culture change head-on.

If you need help with your journey, contact FP Complete.  This is who we are and what we do.

Subscribe to our blog via email
Email subscriptions come from our Atom feed and are handled by Blogtrottr. You will only receive notifications of blog posts, and can unsubscribe any time.

Do you like this blog post and need help with Next Generation Software Engineering, Platform Engineering or Blockchain & Smart Contracts? Contact us.