Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: VS Code drops support for Python 3.7, Windows drops VBScript, and Europe plans the fastest ARM supercomputer. (more…)
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Can the Linux desktop installed base ever break the mythical 10% barrier? Google has been refactoring ChromeOS, and GNOME is working on new window manager ideas. (more…)
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Working from home is here to stay, and Agile is still a failure. (more…)
As we close out 2022, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2022.
Welcome to The Long View—where we peruse the news and strip it to the essentials. Let’s work out what really matters.
This week, something a bit different: I’m devoting my entire column to Agile and Scrum. They’re increasingly getting a bad reputation, being associated with the worst aspects of toxic workplace culture: Sexism, racism, burnout, micromanagement. (more…)
When organizations begin using DevOps for application development, many only reference DevOps as part of their infrastructure and select a subset of DevOps before understanding the cultural and process changes needed for success. Instead, organizations must first determine which ‘Ops’ approach best promotes a DevOps mindset and integrate their workflows into their culture. In doing so, these organizations will better align their development and operations teams on common goals and protocols.
There are many variations and subgenres of DevOps. However, it’s important organizations understand the ‘Ops’ choices available and choose the one that’s right for them.
General DevOps and its subgenres can be split into two groups. The first and “purest” are the principles that these terms focus on unifying two or more industries with operations.
The second type is those that focus on an implementation type.
DevOps: Improving Technical Processes and Culture
DevOps is the overarching umbrella term for operations that combine Agile development concepts with IT operations and fast-tracks the development and deployment of applications in cloud environments. While there are different subgenres of DevOps, each subgenre is a different application of DevOps methodology, all geared toward making development more agile, stable and efficient. Because DevOps shortens the development life cycle by a significant margin, this streamlined approach to application development is quite popular.
DevSecOps: Adding Security Checks
DevSecOps bakes additional security measures into the workflow. Where DevOps typically has security checks at the end of a cycle, IT pros that leverage DevSecOps integrate security early and often in their DevOps journeys. With DevSecOps, collaboration between developers, security specialists and ops is crucial to maintaining agility and delivery speed, but the extra layers of security can slow processes down. DevSecOps leverages fast testing and robust pipelines to favor better code integrity. This method can be beneficial if an organization needs to elevate security during development.
NoOps: Reducing In-House Teams for Operations
NoOps is the lofty vision that DevOps is so automated it doesn’t require in-house expertise, meaning no manual intervention is required in processes. NoOps differs from DevOps because there is less focus on Agile and process management. This process assumes that developers do not need to know how to use the automated tools and uses continuous integration techniques to allow developers to focus only on application development.
Though NoOps speeds up the deployment processes, if used by itself, NoOps lacks open communication and team management. Successful implementation of NoOps is only achievable if an organization does not have lofty technical goals or if its development team is small but strong and able to handle development and operations.
GitOps: Using Git to Automate
GitOps has been gaining traction in the development industry over the past two years because of its use of Git to automate continuous delivery pipelines. GitOps is a robust and manageable form of operations because it uses Git as the single source of truth for operations. In addition, due to developers’ familiarity with Git and pull requests, there is no complicated tool to learn, and changes to existing workflows are often unnecessary.
The GitOps method can also boast that it is backed by some of the market’s most innovative cloud services, thus automating the process of building an update, testing for errors, reviewing code and pushing the update to production. Because Git is the only source of truth with GitOps, it is vital to effectively fortify the Git repository to avoid needless commits or pull requests.
CloudOps: Implementing Cloud-Native Features
CloudOps attempts to take more advantage of cloud-native features offered by modern service providers. Since CloudOps focuses on distributed development and deployment, there is no single point of failure, making the whole cloud environment more reliable. In addition, certain parts of the workflow in this type of operation can go stateless, making it cost-efficient as organizations only pay for the resources they actually use. Though CloudOps can be time and cost-efficient, organizations must get the configuration right for the approach to be beneficial, which could mean added complications to configuring CI/CD pipelines.
CIOps: Requiring CI Operators for Configuration
Continuous integration Ops (CIOps) is the latest iteration of DevOps, requiring CI operators to configure the infrastructure needed to support new code before deployment. The manual inputs necessary to ensure CI jobs’ correct configuration and deployment location bring advantages and disadvantages. Control over infrastructure allows two deployments to have different infrastructure configurations. The major disadvantages are the required manual intervention leaves room for error and the need to link an organization’s CI tool to its API can pose security risks.
CIOps is better-suited for smaller development environments where automation is an inconvenience. While CIOps gives developers flexibility in configuring cloud infrastructures, the approach takes time and effort to run smoothly.
ITOps: Automating IT Management Pipelines
IT is loosely defined as the management of end user or employee systems. They are the systems that are required to run a core business. The fundamental difference is that there is little to no development. If your business doesn’t require a software engineering team and can function solely on prebuilt applications, then ITOps is for you.
ITOps is in charge of delivering and maintaining services, applications and the underlying technologies necessary to run a business, covering jobs like system administrator and network administrator. ITOps focuses on updating laptops and office networks in addition to highly-tested commercial software and solutions for constructing the infrastructure, making updating infrastructure components more complicated. When using ITOps, an organization’s CIO will focus on managing the system via automation.
Choosing the Best Op for an Organization
Choosing between the variations of DevOps is a matter of finding an approach that works best for the kind of apps the organization is developing and the cloud infrastructure they use. Though all of the above Ops strategies are based on unique ideas, they tend to focus on the technical side. Contrarily, DevOps stands out for its ability to comprehensively improve workflows and streamline technical processes while fostering a culture of innovation and collaboration in an organization.
Once again, we are seeing an uptick in the use of the term NoOps. I always felt that NoOps was a misleading and, in fact, empty phrase. I don’t care what magic you think you have; you are never going to eliminate the need to operate your software, applications and infrastructure.
I first heard the term NoOps early in the maturation curve of DevOps. Back then, the idea seemed to be that Dev was going to absorb Ops. Between that and the cloud, there really wasn’t a role for traditional Ops to deploy. Managing apps would be easy with the cloud and automation. At least, that was the pie-in-the-sky thinking—but I never bought that.
There were other terms that popped up, like NewOps and AIOps, though that became something else entirely. But really, I think the rise of the systems reliability engineer (SRE) role put the NoOps movement in its grave (where it probably belonged). SRE became the shiny new identity of the Ops crowd and SRE continues to be one of the most popular topics here on devopsy.kinsta.cloud.
This latest incarnation of NoOps seems to be a little different. From what I have seen, it is not really NoOps; instead, it is more of a “not your Ops to worry about” movement. It is shifting who is responsible for Ops from the company developing and using the apps to a service provider (or SaaS provider) who is responsible for Ops. It is more a “MyOps” not “YourOps” movement, but there is still most certainly an Ops there.
In my neighborhood growing up, we used to have a saying, “I don’t care what you call me, just don’t call me late for dinner.” Originally, to me, NoOps was very much like that. We changed the name of something, but it didn’t go away or fundamentally change the thing itself.
Now, we still have Ops, it is just a question of who is doing it. That is not NoOps to me. It is “somebody is doing MyOps for me.”
We saw a similar pattern in security. The idea of outsourcing security was never called “NoSec,” because the idea of no security is, frankly, downright scary. Instead, it just meant relying on a cloud vendor or an MSSP to handle your security for you; it was outsourcing your security. An important lesson learned from that was that you can outsource your security ops, but you can’t escape your security responsibility. That is to say, when your customers’ information is breached, saying “We had someone doing this for us!” did not absolve you of responsibility.
The same thing holds true for this new “OutsourceOps.” The outsourcer may do a better job than you at Ops. They may give you SLAs and SLOs that give you reasonable expectations of performance and remedies if those SLAs and SLOs are not met. But it is still your company’s name and reputation on the line.
So is what we seeing as NoOps really NoOps? No, it is Outsourced Ops. But as we said in the old neighborhood, I don’t care what you call it, just don’t call it late for dinner.
The number of tools engineers use to provision software architecture in the cloud is starting to get a little out of hand. There are many competing ways to do one thing. Most often, people simply adopt a new tool to solve a DevOps problem in the moment, not always considering the longevity of the solution or how other departments are handling it. This could result in fragmentation and technical debt, making it difficult to find consistency and increase speed simultaneously across all company divisions.
I recently interviewed Jeff Kukowski, CEO, CloudBolt Software, to explore why these issues persist and how executives should approach cloud management within their organizations. According to Kukowski, many flavors of Ops now permeate large companies. Different approaches often exist per department or interdepartmental, with teams using various software stacks.
According to Kukowski, a new frame of mind will be necessary to remain agile in the new cloud order and to address this state. Doing so will require organizations to erode false dichotomies around ownership and IT governance.
At this point, most large suites of digital services have adopted a complex hybrid and multi-cloud modality. And many teams have embraced their own unique form of DevOps to get a handle on the management difficulties of delivering software and maintaining reliability for microservices architectures. Different groups pulling in various directions create an ongoing battle of EverythingOps, explained Kukowski.
You can think of it as separate Ops approaches emerging around different business functions. For example, FinOps is emerging to control spending, ITOps is about delivering services, DevOps is improving release fluidity and DevSecOps aims to bring security to the forefront of the release process. Lastly, BizDevOps is about increasing observability for business outcomes.
At a high level, CIOs have committed to digital transformation to move quicker. Yet the problem now is “battles between different Ops can easily lead to broken IT governance,” said Kukowski. This tension introduces several false dichotomies, he explained. In addition to slowing agility, a lack of DevOps unity eschews reusability, contributing to waste and increased IT expenses, said Kukowski.
There is a belief in IT that true innovation will come if you only give engineers the keys to use anything they want. While that may be true, without better leadership with regard to the basics in this new cloud order, some things can get out of control very quickly, Kukowski warned. Instead, he argued that built-in guardrails for provisioning tools are necessary. “We have too many tools—we need better frameworks to tie this together.”
Not only would increased cloud governance help tie together disparate tooling decisions, but Kukowski argued it also can reduce the cognitive load necessary to onboard each tool. “Shifting left will increase speed—it won’t slow people down,” he said. Contrary to popular belief, he said that shifting guardrails left can have the effect of increasing speed, which may greatly outweigh the negatives of shackling developers to a single approach.
CloudBolt predicted siloed management will shift to organizational governance around tools in the coming year. But it’s not only the tooling decisions that require forethought, “it’s the leadership and cultural approach,” said Kukowski. A common area where greater leadership is required is in tagging workloads for applications, he said. “It’s not being done well anywhere.”
Or, consider containerization. Containers have become fundamental to most modern cloud technology stacks, yet, the cognitive load required to deploy, configure and run a contain remains quite high, explained Kukowski. Do you allow every developer to custom-code each container, or do you enable a self-service repeatable provisioning process? If standard code is not being reused, you’re not getting speed or governance, he explained. Furthermore, with green IT initiatives becoming a priority, companies should be looking at ways to reuse processes and reduce waste where they can.
For a cloud-native company, the emphasis is constantly on speed and growth. And engineers are absolutely driving this focus and the resulting innovation. Yet, this innovation can’t come at the expense of bringing all departments onto the same level of innovation. “Innovative stuff in the cloud can’t be separated from governance, ESG and security,” said Kukowski.
A big hurdle of tomorrow’s cloud management will be identifying and uniting these islands of automation, these pockets of tools and preferences that differ between departments. It will also require a different frame of mind across divisions. “There’s a difference between solving the problem for the task and solving the problem for reuse and speed,” explained Kukowski. Delivering on reuse and speed will require less bespoke DevOps automation and better foundations for solving future problems, he said.
“Shift left, automate and reuse—people shouldn’t have to touch it. That’s the thinking that needs to be applied to this new cloud order,” said Kukowski.
NoOps is coming, in some form or another. Whether you have homegrown DevOps or outsourced DevOps, it’s time to realize that a simpler way is coming: NoOps automation. We spoke with a group of IT pros to get their perspective and insights, including James Rutt, CIO, The Dana Foundation; Rahul Subramaniam, CEO, DevFactory; and Mark Hahn, director of DevOps and cloud strategies, Ciber Global.
Forrester Research defines NoOps as the goal of completely automating the deployment, monitoring and management of applications and the infrastructure on which they run.
The next generation of PaaS platforms is evolving to meet this goal. If development teams prefer not to deal with operations or lack the necessary skill sets, they can opt into platforms that provide standardized best-in-class operations with minimal hassle. This also accelerates the evolution of their infrastructure to emerging technologies such as Kubernetes and containers. Not only that, but it can be accomplished at a fraction of the cost. However, the NoOps concept is not without its own bit of controversy.
Mark Hahn: “The differences [between DevOps and NoOps] have a lot to do with shifting left more on all of the processes. With DevOps, teams have to rely on various operations and infrastructure support services. With NoOps, the goal is to make those teams fully self-sufficient.”
Automation is the key to this self-sufficiency. Continuous integration and deployment automation can be created and configured by the DevOps team or provided by the platform (NoOps). In either case, the end goal is to empower the team such that they can focus more on the business problem at hand than deployment.
In a DevOps model, a few developers on the team typically manage the continuous integration pipelines and their associated deployments. This includes the creation of the application stack and subsequent updates, as well as observability and scalability mechanisms. The widespread availability of infrastructure-as-code and associated APIs has made this possible.
NoOps platforms provide these capabilities without much additional work by developers, thus enabling application teams to accelerate their delivery velocity. This does come at the cost of some flexibility. Teams with special requirements, such as GPU-centric environments or extremely high-scale use cases, may opt to build their own infrastructure to meet their individual needs.
Most teams don’t need the additional complexity, though, and are better served to avoid it. Applications with a user base in the low thousands will likely not need much beyond the standard configuration provided with frameworks such as Spring Boot or .Net Core. You start with just the infrastructure you need, avoid solving problems you don’t have and leverage only select offerings from cloud providers.
Rahul Subramaniam: “We have far too many choices; making the right choices is extraordinarily hard. When you build a Spring Boot application, the number of deployment choices you make is ten times what it was even five years ago.”
“I’ve seen teams that put together really large CI/CD pipelines that run thousands of builds a day. The problem is, it works for 50% of the teams really well, and the other half are struggling. For developers building Java-based systems, it works great, but those that are doing Android development, it doesn’t support mobile applications well,” added Hahn.
The NoOps approach has a key dimension that extends beyond automation. The infrastructure landscape is continually evolving, and developers are faced with a growing array of choices as they deploy and manage applications. How can teams know which are the right tools to pick? There are too many out there to be an expert on all of them.
Consider the area of observability, where choices range from open-source solutions such as Prometheus and Grafana to commercial offerings such as Dynatrace and DataDog. Is the extra value added by the commercial offerings worth it? Is it a requirement for your application?
It can be difficult to say, upfront. Oftentimes, the best way to learn how to operate your service is to operate your service. Starting with an opinionated, bundled solution gets you started quickly and puts you in a position where you can learn those lessons. With NoOps, the infrastructure arrives ready-to-go, right out of the box. You can focus on your core business function and not worry about the deployment mechanism. This shrinks the surface area where errors may occur, and improves the efficiency of development teams. From a management perspective, the reduced cost is also quite appealing.
Mark Hahn offered a different perspective on this topic. He noted that if there is one opinionated CI/CD framework, it may suit some teams well but not the others. Teams that develop various components may have different requirements; thus, they may need the option to build their own pipelines. This is a consideration to keep in mind as organizations seek to adopt the NoOps philosophy.
James Rutt: “There is a broad assumption that DevOps is mature, whereas in most shops, they feel mature in some areas of the value stream but not necessarily in the synchronization of all the tools. Now, we are talking about another quantum leap into NoOps. Do you think we are jumping ahead too quickly?”
DevOps and NoOps represent a spectrum, rather than a conflict where one wins over the other. Many applications don’t need a highly engineered infrastructure, as opposed to companies like Amazon and Netflix who require it. Thus, don’t over-architect solutions until the time where you need to. Grow into DevOps when it becomes a business priority for you. For Amazon, it is a business priority to manage that infrastructure. For you, it may not be.
Subramaniam made the point that teams should actually begin with the NoOps approach as the default. Look for NoOps solutions out there to quickly get started, and at some point, you may need to manage that infrastructure yourself as your business grows or requires it.
Another consideration is that not all organizations are at the point where developers can make choices independently. You always want the business and technology groups to be in alignment. This is where more traditional processes fall into place. Further, DevOps teams typically place numerous checks and balances in their systems. For example, custom pipelines enable reconciliations and cross-checks to make sure the data being operated on is correct and accurate.
For developers running on Google’s cloud, App Engine “lets app developers build scalable web and mobile back ends in any programming language on a fully managed serverless platform.” Teams running on AWS can use Engine Yard Kontainers from DevGraph to “deploy apps in one click directly from your Git repo.” There is also AWS Elastic Beanstalk, which bills itself as “an easy-to-use service for deploying and scaling web applications and services” on one of their supported technology stacks.
Regardless of DevOps versus NoOps, our interviewees agreed that development teams need to be empowered. Gone are the days where you can afford to spend time on undifferentiated activities or wait on dependent service teams. Focus on the business value from day one, make it observable and use the platform that best enables you to accomplish that goal.
It feels like DevOps principles are permeating every discipline, creating new buzzwords by the minute. DevSecOps. DatabaseOps. SalesOps. FinOps. MarketingOps. This “JargonOps” is clearly encouraged by marketing campaigns (and bloggers, wink, wink). Yet, the phrases do depict a real trend: all industries are getting an efficiency overhaul in the wake of increased automation.
As I’ve covered before, low-code and no-code tools lower the barrier to entry to application development, enabling field experts to construct workflows as they see fit. For tech-savvy non-engineers, this could be a huge boon to transform copy-and-paste stopgaps into efficient workflow automations.
I recently chatted with self-proclaimed “productivity geek” Sean Chou, CEO of Catalytic, to get his take on where this new era of automation is heading. From healthcare to logistics, advertising to supply chain management, every industry is likely to get an efficiency boost — and a lot of this digitization will be constructed using codeless environments.
But first, how did we get here?
“The story of B2B software is largely about automation,” said Chou. If we consider classic examples of corporate applications, we see one common thread — B2B software has always sought to automate traditional office work.
And so, it came to pass that computing and software devoured all these office tasks, from accounting to time-tracking, communications and many other areas. Though computer-based office work delivered huge efficiency boosts, these interfaces often introduced new hurdles; bad UI design, difficult navigation and a hundred open tabs, just to name a few.
From there, robotic process automation (RPA) aimed to operationalize a growing number of tedious digital workflows across Excel spreadsheets, web apps and desktop apps. In Chou’s words, “RPA took the concepts of test automation software, and then pointed it toward production systems.”
Though RPA’s process of recording screen interactions gathered much interest and attention (and funding), screen scraping is ultimately too fragile to be effective. It adds technical debt over legacy systems. It can be expensive to implement. Lastly, it’s not processes-centric and doesn’t implement reusable software-defined APIs.
At that point, though, “Pandora’s box was open,” Chou said. Folks started to consider other ways to optimize, and reimagine how end users could automate workflows and stitch together interactions between disparate apps.
Out of the ashes of RPA rose a new paradigm — low-code and no-code.
With developer resources stretched thin and limited engineering talent available, it can be challenging to loop expert programmers into codifying traditionally non-IT processes.
There’s not often enough developers to help with SalesOps, FinOps or any other Ops areas, explained Chou. “The only thing that can change the narrative is no-code technology that is effective.”
Similar to how higher-level programming languages made low-level programming more accessible, Chou sees low-code and no-code unlocking accessibility for automation design by orders of magnitude.
So, what are some examples of no-code use cases for automating operations? Chou outlined four specific categories that he believes will see much more citizen developer attention and action in the years to come:
Customer Ops: “It’s really important to run customer operations as efficiently as possible,” Chou said. Especially in B2B interactions, people need to adopt various systems dictated by the customer. This can result in many ad-hoc implementations that beg for efficiency improvements.
Financial Ops: Imagine the number of Excel spreadsheets that make up an account’s financial foundation. Consider the tedium of inputting data, generating reports or migrating calculations into other tools. There’s a ton to automate here. Providing no-code platforms to financial minds could have a “really transforming effect,” said Chou.
People Ops: “The number of mini apps being developed for HR use cases is astounding,” Chou said. Think of all the digital tools HR must use: vacation requests, employee performance reviews, personnel databases – the list goes on. There’s a significant opportunity to clean up legacy applications within many HR departments to build a more coherent platform.
SupplyChain Ops: Procurement and supply chain operations is another area where no-code could have an impact. Streamlining inter-company communications or engaging with potential customers are areas worthy of automation.
Across all these verticals, Chou notices three common patterns emerging.
First, groups are using no-code to create standard operating procedures (SOP). SOPs could be used for onboarding or offboarding customers or ensuring compliance with a set of policies.
Another everyday use is data pipelining — pulling information from many resources for analysis. A common use case is processing financial or customer data to generate a particular output. This is an area where embedded machine learning models could enrich the data.
Lastly, a third common use case is creating workflow-powered surveys. These online forms could be used to measure employee engagement or to collect customer input. No-code workflows enable not only the collection of that data, but could allow for additional actions to be taken upon input.
Of course, giving non-developers the keys to the castle could have some downsides. Let’s face it — computer science is, well, a science. There’s a reason engineers are taught strict practices around version control, data governance and peer reviews. All of which must still be upheld when establishing a citizen development culture — especially at scale.
When it comes to low-code and no-code, “governance is a huge thing,” said Chou. “Any company coming at this with no governance in mind can’t work beyond small teams.” Move beyond 10 or so citizen developers, and you’ll really need to establish some sort of shared framework or center of excellence.
Making citizen development work in a large company requires IT visibility, data governance and a review process for new workflows, said Chou. IT will likely also want to verify that a new workflow doesn’t make permanent state changes. Otherwise, static apps that don’t touch core systems or affect persistent data stores are probably fine. “Having built-in governance is really key to making this successful,” Chou said.
No-code is giving more people the ability to produce unique workflows to increase their efficiency and do more with less. But with this movement comes worry. “With every technology leap, there’s always a wave of people concerned,” said Chou. Many naysayers are worried that automation will leave people out of work – “They’re coming for our office jobs!”
Instead, Chou recommended we curb our expectations. Citizen developers are not going to build sophisticated iPhone apps any time soon. “If you think no-code is a panacea for all software, you’re coming at it all wrong,” he said. Instead, what they can actually can accomplish is far more practical.
In reality, things are not as dire as some may make it seem. The new age of automation will likely open room for more jobs than it diminishes. “The net is always a plus,” said Chou.
Within an organization, an operations model must be fit-for-purpose and be able to adapt as business needs change. At the same time, changing technology necessitates an advancement in how an organization operates. Small and medium-sized enterprises are faced with the difficult choice of how much to invest in operations and which approach to choose. In light of the numerous possibilities, companies need to identify the right upgrades for their needs. For instance, should a company now using a traditional operations model invest significantly to reach DevOps? Or would AIOps better fit customers’ needs? Is NoOps an option?
There is no “correct” answer. Each option comes with pros and cons and important budget considerations. That is why every business needs to evaluate the appropriate system for its products and its customers with three concepts in mind: cost, goals and experimentation.
Traditional IT operations (ITOps) is the process of designing, developing, deploying and maintaining the infrastructure and software components of a specific product or application. It also ensures the customer experience is delivered through traditional means of support such as tickets and escalated paths for resolutions.
DevOps is a process for accelerating the delivery of features to the application or product infrastructure in a consistent model with less human intervention, while also providing a better quality product through automation in the software development life cycle.
An AIOps process introduces data science into the operating model by learning the behavior of the systems, scaling according to the needs of a platform (both infrastructure and customer usage of the platform). It expands the horizon of DevOps through the introduction of machine learning, focusing on data generated from the hardware and software systems, and allows organizations to grow organically based on demand.
NoOps, although the name suggests otherwise, is an advanced approach to managing IT operations through the mindset that everything is derived as development. This model is best applied with startups and companies with high technological maturity.
Typically, these companies have advanced skill levels to deliver the best experience by adapting to the new industry trends of both software and hardware maintenance practices. NoOps is at the opposite end of the spectrum from traditional operations, and it’s largely a theoretical concept at this point.
NoOps is a fully automated, cloud-based approach that eliminates the operations team, aside from an integrated team focused on life cycle. The self-managed system requires resiliency and a high level of maturity with fail points that have already been addressed. NoOps, or high maturity structures, will also provide quick learning on drawbacks, customer and product needs. However, moving toward a self-maintained system requires upkeep for advances and innovation.
The first factor to consider in evaluating an operational approach is cost. Each level of IT maturation is gradual, incremental and expensive. Costs vary depending on the size of the company and the type and number of products. A small company that seeks to move from a level 2 to 4 maturity would need to make a significant financial investment.
Some questions to consider when looking at operations model upgrades include:
Next, it’s important to consider overarching goals and brand identity. The appropriate level of maturity might depend on the company’s value proposition. If, in the company’s vision, technology is at the heart of its journey, the company needs to invest, at a minimum, in a DevOps operating model to have the competitive edge to grow the business and meet its needs. If the company’s vision is to retain existing business and gain customers through continued investment in innovation based on the trend analysis of their core business, then AIOps will have the best ROI. If the company’s vision, culture and mission are intertwined with technology, adapting to NoOps is the right move.
Still, it’s important not to overreach with an operations model that might not fit the customer. To make a sound decision for the organization, it is important to understand the model, the product, customer base and when to halt an operational model and invest in a new one. The leadership team needs to ask how adaptable its end users are before implementing changes. Take, for instance, the poor consumer response to replacing live customer service representatives with automated features. Some end users were not prepared to adapt to the massive change in the platform or service offerings this move entailed.
Product-driven businesses often don’t see investing in new operations models as worthwhile. This mindset can result in continual churn that creates a backlog and increased operating costs for maintaining systems and services. Another important consideration in deciding which operating model meets the company’s needs comes through experimentation. That is because finding the right operating model for an enterprise can’t be done with a cookie-cutter approach. The point is to maintain the existing quality and productivity while investing in outcomes that will garner more trust and confidence in the company. If you do this right, the end user will appreciate the changes, and the company will outperform the competition.
Enterprises should expect failures during experimentation with different models and plan to pressure-test an advancing model for the cracks that will emerge. It is important to invest in failure to understand why and how the model did not perform to expectations. Those failures provide valuable insight and important data, result in significant learning about products and customers and help you know what to improve or modify going forward.
An operations model serves as the backbone for any business that wants to grow. Smart operations investments will ensure adaptability, competitive advantage and customer loyalty. But there’s no one-size-fits-all, easy-to-follow recipe for each enterprise. Whether the investment results in AIOps, NoOps, DevOps or traditional operations is unique to each organization and needs to be calculated with the brand, customer and end goal in mind.