devopsy.kinsta.cloud

Tag: enterprise IT

The Rise of Composable Architectures to Replace Traditional Platforms

Traditional monolithic platforms have served their purpose. As technologies like artificial intelligence and quantum computing usher in a new digital age, flexible and modular architectures will take their place. Developers and cloud professionals should familiarize themselves with composable architecture’s principles, benefits and implementation best practices to remain competitive in an evolving technological landscape.

Composable Architectures Are Catching On

Composable architecture is not a niche concept. Market research shows it is a rapidly growing trend with significant projected growth. By 2028, its value will reach an estimated $11.8 billion, up from $5.2 billion in 2023. It will achieve a compound annual growth rate of 17.5% during the forecast period, demonstrating its rapid rise in popularity.

This expansion reflects increasing demand from organizations seeking greater flexibility and adaptability in their technology infrastructure, underscoring its importance to enterprise technology stacks.

Understanding Composable Architecture

In traditional monolithic architecture, an entire application is built, deployed and managed as a single inseparable codebase. Components remain tightly coupled despite being separate, creating dependencies that limit flexibility and slow development cycles.

The microservices architecture came next. It shortened development cycles to a mere few weeks by dividing applications into smaller, independently deployable units. Components scaled independently, services were communicated through well-defined APIs and containerization technologies simplified deployment.

While microservices are beneficial, they don’t live up to their promise of independence. If complexity is spread across systems and each deployment requires extensive coordination between teams, the architecture is still a traditional distributed monolith. It forces everything to scale, deploy and fail together.

Composable architecture is a modern software design philosophy that leverages smaller, API-first, modular components. This approach allows organizations to build applications from truly independent, interchangeable parts that communicate through well-defined interfaces.

Modularity, interoperability and reusability are fundamental. Developers achieve them with microservices, API-first, cloud-native and headless (MACH) principles. Professionals deploy and manage services separately.

The Business Benefits of Modularity

By enabling organizations to easily upgrade, swap or add individual functionalities, MACH principles can anchor IT execution to business objectives. This modularity delivers tangible advantages that extend beyond technical improvements.

Organizations can connect to different content repositories, modify individual components or introduce new capabilities without disrupting or overhauling the entire system. The primary benefits are agility, scalability and innovation.

With modular architectures, businesses can replace or update specific functionalities, such as payment gateways, search or content management systems. For instance, they can upgrade enterprise resource planning software by breaking down a monolithic system into flexible API-first modules.

By upgrading legacy systems, companies can benefit from enhanced performance, greater internal controls and decreased maintenance costs. In addition to delivering direct benefits, modularity mitigates opportunity costs by facilitating cloud functionality. These modern capabilities improve collaboration, reduce data loss and prevent technological obsolescence.

Greater resilience would be incredibly beneficial, as the average organization loses approximately $1.5 million to IT downtime each year. Unplanned downtime is even more expensive. With a cloud-native architecture, they can avoid the vast majority of these losses.

Guidance for Successful Adoption

Organizations must methodically implement a composable architecture. A successful transition involves careful strategic planning, a rigorous technology selection process and a culture of continuous improvement among teams.

Teams should choose a new architectural framework that offers an API-first conversion with a centralized hub for managing all component communications. This architectural foundation ensures seamless integration and reduces complexity as the system scales.

They should also fully replace their legacy technology stack with modular, cloud-native components to support this transition. Half-measures that retain monolithic components alongside new modular services create technical debt and limit the advantages of composability.

Preparing for the Next Technological Shift

Adopting composable architectures is a strategic imperative for future-proofing an organization. The adaptability of this approach provides significant cost-efficiency and makes it easier to expand and integrate future AI capabilities.

A modular API-first architecture is inherently better positioned to integrate emerging technologies like advanced AI and quantum computing. High throughput, reliable performance and greater customization are key to quickly adopting transformative technologies. Companies can future-proof their infrastructure to support emerging use cases.

This approach provides a level of adaptability that monolithic systems cannot match, as legacy platforms are having an increasingly difficult time maintaining compatibility with rapidly evolving technologies that are dynamic and data-intensive.

Composing Your Competitive Advantage

Organizations that embrace composable architectures position themselves to respond quickly to market changes, integrate emerging technologies and maintain operational efficiency. This transformative shift is a critical method for building a lasting competitive advantage in a dynamic digital world.

May 13, 2026
Why Senior Engineers Still Do Manual Work in Highly Automated Environments
Automation has been part of enterprise IT for many years, and in many environments, it has grown into an extensive network of interdependent workflows that keep routine operations running smoothly.

Scripts provision accounts, automated workflows manage cloud resources, orchestration tools coordinate ITSM processes, and AI-driven tools help employees across the organization complete tasks more efficiently.

On paper, this level of automation should allow the most experienced engineers to spend less time on routine operational work and more time on architecture, optimization, and long-term improvements.

In practice, however, many teams experience the opposite. Even in highly automated environments, senior engineers are frequently pulled back into day-to-day operational tasks. They are asked to rerun failed jobs, correct permissions, verify provisioning results, or investigate why an automated workflow behaved differently than expected. Instead of focusing on higher-value work, they become the people responsible for keeping the automation running when something goes wrong.

As automation architectures grow larger and more complex, they can also become harder to predict and more prone to failure. When execution is inconsistent or difficult to troubleshoot, the most experienced engineers inevitably become the safety net. At that point, the productivity gains automation was meant to deliver begin to erode, and the workload shifts back onto the very people it was supposed to free up.

If Automation Grows Without Control, Consistency Suffers

Most automated environments are not designed all at once. Instead, they evolve over time as different teams solve different problems in different ways. Each new script or workflow improves a specific process, and each addition makes the environment more capable than before.

As the number of automation assets increases, however, consistency often begins to break down. In organically grown environments, scripts may run from different servers, under different user accounts, and with different approaches to permissions, credential management, and logging.

This lack of consistency creates uncertainty:
- A script that works perfectly in one workflow may start to fail when it comes into conflict with a newly created script in another.
- Tasks that succeed during testing may behave differently in production, where dependencies are more complex and systems are more tightly connected.
- Without enforceable permission policies, with credentials embedded directly in scripts, and with logging spread across multiple tools, automation can also introduce security and compliance risks that are unacceptable in an enterprise environment.
These issues are common when automation grows organically rather than as part of a centrally planned architecture.

When something fails in this kind of environment, diagnosing the problem can take significant time. Engineers must determine which workflow ran, what the expected outcome was, which dependencies were involved, and whether permissions or credentials behaved differently than expected.

In these situations, automation no longer reduces complexity as intended. Instead, it creates an environment that demands constant attention, where skilled engineers must step in regularly just to keep automated processes running as they should.

When Automation Becomes Unpredictable, Expertise Becomes a Bottleneck

When automation cannot be relied upon to execute consistently, responsibility naturally shifts upward. Less experienced administrators are often reluctant to run processes they do not fully understand, particularly when those processes affect critical systems. As a result, workflows that should be routine are frequently escalated to senior engineers, who are trusted to diagnose issues quickly and minimise risk.

Over time, this creates a productivity bottleneck that begins to outweigh the intended productivity return on automation. Senior engineers spend less time designing improvements and more time maintaining and correcting existing workflows. Projects slow down, innovation is delayed, and the organisation’s most skilled resources remain tied up in operational work.

This dynamic becomes even more pronounced with the introduction of agentic automation. Autonomous processes can execute actions far more frequently and dynamically than traditional workflows. When execution is not fully controlled, any inconsistency is amplified, increasing both the volume and the impact of failures. In such cases, automation can place a greater strain on operations than manual processes ever did.

Automation is meant to reduce reliance on expert intervention. Without consistent and predictable execution, however, it can produce the opposite outcome, making experienced engineers more essential to routine operations, not less.

Productivity Improves Only When Automation Becomes Predictable

For automation to reduce operational effort, it must behave consistently every time it runs. The same action should produce the same outcome regardless of who initiates it, which system triggers it, or when it executes. Permissions should not depend on individual user accounts, credentials should never be embedded in scripts, and logging should not be fragmented across multiple tools.

Equally important is the ability to delegate automation safely. In many organizations, automation remains the domain of senior engineers not because it is inherently complex, but because the surrounding tools and processes are difficult to use securely. Interfaces are often unintuitive, configuration is buried within scripts, and security models are too fragile to allow broader access without introducing risk.

For automation to scale effectively, setup, deployment, and monitoring must be accessible through clear and intuitive interfaces, rather than requiring deep technical knowledge of underlying code. At the same time, credentials must be handled in a way that keeps them fully protected. Sensitive information should never be hardcoded or shared between individuals, but instead stored securely and applied automatically during execution.

When scripts and workflows can be reused and shared without exposing credentials, teams gain the confidence to delegate tasks more widely. This reduces dependency on senior engineers, lowers the risk of errors, and ensures that automation remains secure even as adoption increases.

Achieving this level of consistency and control requires a structured execution model that operates beneath the workflows themselves, ensuring that every action runs under defined, repeatable conditions.

How ScriptRunner Keeps Engineers Focused on High-Value Work

ScriptRunner provides the controlled execution layer that allows automation to run consistently across complex Microsoft environments. Instead of scripts executing from multiple tools, servers, and user accounts, all automation actions are routed through a centralized, policy-driven platform.

This ensures that every task follows the same rules, regardless of where it is created or triggered:
- Permissions are assigned through roles and policies, so execution does not depend on individual administrator privileges.
- Credentials are stored securely in a central vault and applied automatically when workflows run.
- Scripts can be reused across service management, orchestration, monitoring, and AI-driven processes without needing to be rewritten for each context.
- Every execution is logged centrally, creating a clear audit trail that simplifies troubleshooting, auditing, and compliance.
With execution standardized, automation becomes something teams can rely on rather than something they need to supervise. Routine operational work can be delegated with confidence, escalations become less frequent, and experienced engineers no longer need to intervene simply to ensure automation behaves correctly.

The result is an environment where skilled staff can focus on architecture, optimization, and innovation instead of spending their time on operational corrections. When senior engineers are no longer required to act as a safety net for routine processes, that’s the point when productivity skyrockets.
May 11, 2026
What the LLM Hype Gets Wrong: What it Takes to Build AI Agents That Work for Enterprises

Enterprise IT leaders are rightly excited about AI’s potential to streamline incident response, accelerate root-cause analysis and ease the burden on overstretched IT teams. However, one persistent misconception continues to blur the path forward: The idea that large language models (LLMs), used alone, are sufficient for solving operational problems inside complex infrastructure environments.

They’re not.

After decades of building and scaling infrastructure systems, I’ve seen firsthand that the leap from chatbot to AI agent is not just about adding automation — it’s about architectural transformation. It’s about embedding reasoning and action in the context of how real enterprises operate.

Here’s what the LLM hype gets wrong — and what it takes to build agents enterprises can trust.

It’s Not About More Data — It’s About the Right Data

Enterprises generate an overwhelming volume of telemetry: The combined output of monitoring systems, application logs, infrastructure metrics, network traces and configuration states. The problem isn’t having too little or too much data. It’s making sense of it.

A full 22% of organizations generate over one terabyte of log data daily; that’s just one slice of the puzzle. When something goes wrong — latency spikes in your checkout service — the answer isn’t buried in all your logs. It’s hidden in a few key pieces of data, scattered across different tools.

An effective AI agent doesn’t just take in everything and hope for the best. It needs to know what data to look for, where to find it and how to separate what matters from the noise. It requires smart orchestration.

Governance isn’t Optional; it’s the Starting Line

Enterprise systems live under strict access controls, audit requirements and compliance frameworks. Any AI solution entering this domain must respect those constraints. This involves inheriting role-based permissions, preventing unauthorized data movement, ensuring controlled and secure data access and verifying that outputs are free of hallucinations, particularly in mission-critical environments where sensitive data is involved.

Trust starts with respecting governance and building that into the agent from day one.

Reasoning Like an Engineer Requires Domain Knowledge

Diagnosing infrastructure issues isn’t a linear process. It’s a cycle of asking questions, checking data, spotting clues, identifying what’s missing and refining hypotheses — over and over again until the real cause emerges.

This is how skilled engineers approach complex systems. They don’t stop at the first plausible answer — they follow threads, test assumptions and dig deeper until they land on something actionable.

AI agents need to operate the same way. They must reason step by step, spot context gaps and adjust their understanding as new information surfaces. Without that kind of iterative thinking, they’re just guessing.

But reasoning alone isn’t enough. To think like an engineer, an agent needs domain-specific expertise. Most LLMs are trained as generalists. They’re good with language but don’t intuitively know when to check a DNS config, correlate alerts with a deployment, or catch a subtle memory leak.

That kind of judgment comes from embedded expertise — captured through dynamic, domain-specific runbooks shaped by years of hands-on work in production environments. It’s what transforms AI from a chatbot into a trusted teammate.

Systems are Fragmented — Agents Need to Connect the Dots

Enterprise teams rely on numerous tools for monitoring, tracing, deployment, ticketing and more. The data needed to solve a problem is rarely in one place.

According to Gartner, many enterprises use between 10 and 20 observability tools simultaneously. This proliferation of tools underscores the fragmented nature of enterprise observability setups.

A helpful agent must access information securely and reliably. That means integrating with the tools and workflows teams already use, not forcing them to rip and replace. Without this kind of interoperability, AI becomes just another silo.

What it all Means for the Enterprises

There’s no denying that LLMs are powerful. But in enterprise IT, power alone doesn’t translate to solutions. What’s needed is precision, security, adaptability, and a way to apply that power in context. That’s where enterprise agents come in.

A true enterprise AI agent isn’t just a system that can generate answers — it’s one that can take action and carry a task to completion autonomously, just like a trusted engineer would.

For enterprises looking to integrate AI into their operations, the question shouldn’t be, “Can an LLM do it?” It should be, “Can I trust this system to reason, troubleshoot and act like part of my team?”

If the answer is yes, you’re on the right track.

July 14, 2025
Survey Surfaces Raft of Enterprise IT Challenges

A survey of enterprise IT leaders found less than a third (32%) are extremely confident that they have the right technology, processes and people in place to execute an effective approach to IT management.

The survey, conducted by Rocket Software, polled 275 U.S. IT leaders in organizations with more than 1,000 employees. A full 93% of IT leaders are also committed to maximize the value of investments in existing platforms.

As a result, the top priorities for IT leaders are hybrid cloud computing (65%), data and content management (68%) followed by DevOps and infrastructure and application modernization, tied at 58%, and automation (57%).

A total of 62% noted they have a much greater focus on efficiency due to the economic landscape, with faster DevOps processes, automated processes and increasing overall output as the top three improvements that would be most impactful for increasing efficiency.

The survey also suggested many organizations still have much work to do to achieve those goals, with 63% of respondents spending anywhere from six to 15 hours on manual data entry and analysis each week.

Phil Buckellew, president of infrastructure modernization for Rocket Software, said most organizations are still trying to determine the right level of DevOps to adopt. Few organizations have implemented DevOps workflows on an end-to-end basis, with many employing a mix of DevOps and waterfall processes to build and deploy applications across a hybrid cloud computing environment, he noted.

Overall, IT leaders are most worried about improving overall IT performance (60%), data security (50%), process risk and compliance (46%) and the need to improve agility (41%), the survey found. Respondents also noted that they measure success within their IT organization by increased efficiency (71%), optimized resources (67%) and reduced risk (63%).

The survey makes it clear that, despite challenges, enterprise IT organizations are committed to hybrid cloud computing as they become more comfortable with using various platforms that are fit for purpose, said Buckellew.

Mainframes, for example, continue to play a major role in running online transaction processing (OLTP) applications alongside analytics applications that are now being infused with artificial intelligence (AI) capabililities, noted Buckellew.

A quarter of survey respondents also identified providing cloud applications with access to mainframe data as an area where they need additional tools, followed by automation (22%).

The biggest automation obstacles are the complexity of implementing automation (18%), resistance to process change among workforce (18%) and lack of skillsets to implement automation (18%), the survey finds.

As always, the biggest challenge in enterprise IT environments is often simple inertia. Organizations that have been building and deploying applications on mainframes, for example, have been relying on waterfall processes for decades. Many of them have now adopted DevOps processes to varying degrees, but few have completely replaced legacy approaches to building and deploying software, noted Buckellew.

It’s not likely the management of complex hybrid cloud computing environments will be simplified any time soon, but progress continues to be made. Soon, AI may automate many existing manual tasks. In the meantime, however, the number of enterprise IT organizations standardizing on a single IT platform remains few and far between.

June 29, 2023
Linux Foundation Europe to Host RISE Open Source Project

The Linux Foundation Europe, in collaboration with RISC-V International, announced today it will host a RISC-V Software Ecosystem (RISE) Project. Through the project, multiple organizations will contribute engineering and financial resources to harden critical open source software for use in commercial applications and enterprise IT environments.

Founding members of the project include Andes, Google, Intel, Imagination Technologies, MediaTek, Nvidia, Qualcomm Technologies, Red Hat, Rivos, Samsung, SiFive, T-Head and Ventana.

RISC-V International is defining a set of application processors that includes software development tools, virtualization support, language runtimes, Linux distribution integration and system firmware that is intended to be used primarily in edge computing environments.

Amber Huffman, chair of the RISE Project, said at a minimum, each of the founding members contributing €80,000 and additional engineering resources. The RISE Project deliverables will be prioritized by the RISE Technical Steering Committee (TSC) as the project looks to address performance, security and reliability issues involving open source software, she added.

The TSC will also be able to shift skills from one initiative to another as priorities continue to evolve, Huffman added.

The overall goal is to use a more holistic approach to eliminate duplicate work that each member of the RISC-V community would otherwise do separately to create an application processor, noted Huffman.

The Linux Foundation Europe is an arm of the Linux Foundation that has been created to host projects that are of particular interest to organizations investing in open source software based in Europe. The RISE project is being launched at a time when the European Union debates a proposed Cyber Resilience Act that requires organizations that sell hardware platforms that connect to the internet to ensure that the devices their software runs on comply with cybersecurity best practices.

The Linux Foundation also provides the funding for the Open Source Security Foundation (OpenSSF) that is marshaling resources to enable maintainers of open source software to address vulnerabilities and adopt DevSecOps best practices to better ensure the security of downstream applications that incorporate that code. In addition, the OpenSSF is building out an incident management capability that will assist maintainers in the event a zero-day vulnerability is discovered.

It’s not clear when all these investments might eventually lead to higher-quality open source software. However, it’s clear that vendors that benefit from open source software are rallying to address a range of quality assurance issues. Less clear is the degree to which enterprise IT organizations that benefit from open source software are making similar commitments.

In the meantime, it’s not likely any of these issues will have a material impact on organizations’ reliance on open source software. The benefits of reduced costs and increasingly faster pace of innovation enabled by open source software development far outweigh the risks. However, as cybercriminals become more adept at embedding malware within software supply chains, there’s a clear need for increased vigilance.

May 31, 2023
TechStrong Con: Open Source Software Community Needs Security Help

The only way to make significant improvements in the state of open source security is if more organizations that benefit from open source projects commit to making more resources available to achieve that goal.

At the virtual TechStong Con event, executives on an Open Source and DevOps panel called for more contributions from enterprise IT organizations to ensure the integrity of open source software.

Organizations of all sizes now benefit from open source software whether directly or indirectly. Those organizations have a responsibility to participate in the development of that software in any way they can, said Jeffrey Barnes, senior software engineer for Remote Operations, a provider of medical transcription services. “We need to give back to the community,” he said.

Those efforts don’t necessarily have to involve contributing actual code, added Barnes. Many open source projects are in need of documentation and testing help because the number of actual maintainers of the project is relatively small, he noted.

The challenge is that many enterprise IT organizations don’t understand how to participate in open source software development processes, noted Tom Sweet, CIO for Industrial Refrigeration Pros. An organization might download a piece of open source software and then extend it. Rather than continuing to maintain that branch on their own, organizations should contribute that code back to the project to reduce maintainers’ overall IT burden, Sweet said.

“Many organizations are struggling to contribute back,” said Sweet. “It’s an evolution.”

Organizations clearly need to make contributing code back to open source software projects a natural extension of their DevOps workflows. In the meantime, the Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation, is focusing on 10 streams of investment that, in total, would require more than $150 million in funding to drive greater adoption of DevSecOps best practices among maintainers of open source software projects.

The core issue is that many of those projects are maintained by a small number of programmers that voluntarily contribute their time and effort to build components that others are free to use. Like any other developer, the amount of security expertise those individuals have is limited. The onus for making sure the projects and software are secure is on the organizations that decide to deploy that software.

Unfortunately, many IT vendors and large enterprise IT organizations reuse that code without contributing anything meaningful back to the project—whether that be in terms of financing or helping open source maintainers find and remediate vulnerabilities.

It’s not clear to what degree business and IT leaders realize how dependent their organizations actually are on open source software. Many of them assume that open source projects are supported by IT vendors when, in reality, there are many projects that are dependent on the efforts of a small handful of developers volunteering their time and skills.

Many organizations, of course, may soon decide not to employ open source software if it doesn’t have a critical mass of developers working on it. However, in an era where DevOps teams and developers routinely download software, enforcing those policies is going to be problematic. The best thing enterprise IT organizations can do is engage with the open source software community more rather than less.

June 24, 2022
Puppet Adds DevOps Consulting Practice

Puppet has launched a DevOps consulting service that promises to help organizations implement best practices that will ultimately make their IT organizations more efficient.

Nigel Kersten, field CTO, Puppet, said the Scaling DevOps Service is especially focused on improving workflows among organizations that have already started down the DevOps path.

Most IT organizations that embrace DevOps eventually encounter bottlenecks that conspire to limit the rate at which they can build and deploy applications. Puppet will make available DevOps experts capable of assessing DevOps workflows as part of an effort to reduce operational friction, said Kersten.

Those consultants can also identify integration opportunities that might further streamline workflows, in addition to providing an overall assessment of an organization’s DevOps maturity based on a model Puppet developed.

Kersten said in many cases, enterprise IT organizations, especially, are trying to adapt DevOps principles that were originally created for small startup companies, with mixed success. Puppet consultants, using observations gleaned from their own engagements with customers that have embraced its tools for automating the management of IT, are often in a better position to identify ways to optimize DevOps workflows across larger IT organizations, Kersten said.

It’s also easy for large enterprise IT organizations to misinterpret how one DevOps principle or another should actually be implemented, Kersten said.

DevOps consulting, of course, has become a cottage industry within the IT services sector over the last decade. Now, almost every systems integrator has a DevOps practice. Most of those practices are focused on enabling organizations to embrace DevOps, versus helping organizations optimize workflows after they have already begun the transition, said Kersten.

It’s not clear to what degree organizations that have not embraced Puppet’s automation framework will embrace consulting services based on a DevOps model created by observing Puppet’s customers. However, it’s apparent many IT organizations have inconsistently implemented DevOps practices across various departments. In many cases, bottlenecks that result in various departments within a larger IT organization are being addressed using a set of manual processes that have been created as a workaround to a specific problem.

Of course, optimizing DevSecOps best processes is only going to become more challenging as emergent technologies such as containers, Kubernetes clusters and serverless computing frameworks are added to the IT mix. More challenging still, many organizations are now trying to shift responsibility for security further left as part of a DevSecOps workflow.

Many IT teams are, naturally, resistant to paying for advice, while others routinely hire small armies of consultants in the hope that ideas and concepts that have worked well elsewhere can make their IT teams more efficient. Regardless of the approach pursued, IT leaders need to remember that DevOps is a continuous journey. Every time a new platform is added to an IT environment, a DevOps workflow will need to evolve. The real issue IT leaders need to come to terms with is how long it will take for their internal teams to adapt, whether it’s via the school of hard knocks or relying on external expertise that has handled most of the issues an internal IT team is likely to encounter.

March 1, 2021
Need for Increased Training — Strained Budgets Strain Enterprise IT Teams

As enterprises have increasingly embraced cloud, hybrid IT environments and DevOps methodologies, many of the old siloes associated with IT departments have crumbled—while demand for training and skills that reflect new technology requirements have risen considerably.

This new reality was reflected in the findings of a new survey from IT management software provider SolarWinds, and was published in the SolarWinds IT Trends Report 2020. While the survey was conducted prior to the novel coronavirus pandemic, the results highlight the challenging environment IT departments faced as they headed into the current economic and operations challenges.

The survey found that the top three ways enterprise technology professional roles are changing include the need to retrain existing staff (43%), increased on-premises responsibilities (40%) and increased work week hours (37%). Concurrently, those IT professionals surveyed cited lack of budget and resources (36%), unclear or shifting priorities (23%) and lack of training for personnel (12%).

That lack of training is a challenge that is getting worse, as 48% of respondents stated that new technology professionals entering the workforce aren’t coming equipped with the skills necessary to manage modern, distributed IT environments. Only 28% of those asked believe that these new workers do come with the skills necessary.

Non-technical, or so-called soft skills, that enable cross-functional teams, are seen increasingly critical to success. These skills include project management (69%), interpersonal communication (57%) and people management (53%). Interestingly, only 53% of those surveyed said they are comfortable communicating with their business leaders when it comes to requesting new technology purchases, investing time/budget into team training and related requests.

These findings are echoed in the recent DevOps Institute Upskilling 2020: Enterprise DevOps Skills Report. Based on 1,300 respondents, this survey found more than 50% of enterprises are challenged managing the people and the processes that make DevOps possible. Most respondents (61%) also said interpersonal skills are crucial.

Other areas where the SolarWinds survey found skills to be essential include application performance management (APM), security and compliance. According to the survey, 54% of those surveyed report spending more time managing applications and services over infrastructure and hardware. And, the survey found, when organizations move to cloud technologies, 57% use network traffic analysis and network application analysis, while 55% said they use user experience monitoring. Finally, 52% said they use log analysis. Sixty-one percent said for APM, 61% said they use both native management tools provided by their cloud vendor and third-party toolsets.

The survey also found that as businesses increase in size, the more IT turns to log analytics (58% for enterprise), and tracing (24% for enterprise) increases. While only 23% of small businesses have not or don’t plan to adopt technology to gain visibility into cloud or SaaS technologies.

The survey also found that 65% of IT professionals spend at least 10% of their day on security management. The top skills they have prioritized to develop within their organizations include network security (48%), security and event management (33%), and backup and recovery (29%).

Additionally, regulatory compliance has fueled the need for increased staff, according to 46% of respondents, with the biggest impact coming from GDPR (45%), PCI DSS (34%) and HIPAA (34%).

The SolarWinds IT Trends Report 2020 was conducted in December 2019, and is based on responses from 227 technology practitioners, managers and directors from public-and private small, mid-size and enterprise businesses within the U.S. and Canada.

May 4, 2020
How Enterprise IT Teams Can Win the Hearts of DevOps

Take your average IT team in a young enterprise in the midst of skyrocketing growth. There’s a good chance the workflows they’ve used since the outset can’t keep up with the ever-increasing volume of requests from the business. In the minds of some DevOps and app development teams in particular, the IT department of the scrappy startup has gradually become the department of slowing things down.

As a result, tasks that once took hours, such as provisioning resources (e.g., virtual machines, workloads, XaaS), can now take days. For agile DevOps teams, this is essentially a showstopper: They need access to resources when they need them–not when you deem them worthy. Anything else feels like a drag on development and the business.

Giving DevOps What They Want

IT needs to make access to resources as seamless as possible for DevOps teams. The ultimate goal is self-service. DevOps should be able to instantly gain the access they need to the resources they need, without the back and forth of ticketing systems, or the complexity of provisioning resources on totally unfamiliar systems. And with a user interface that only serves up the resources relevant to the requesting team, DevOps can easily manage and provision resources on demand.

Maintaining the Controls the Enterprise Needs

Of course, it’s not about just giving DevOps access to whatever they want when they want it. You need real controls in place.

For example, without the right guardrails, DevOps teams can easily spin up more virtual machines than they need and let them run without limit. To give you an example of how bad it can get, Gartner estimates shadow IT accounts for 30-40% of IT spend, from idle resources consuming costs by the minute.

Through blueprints, repeatable ways to orchestrate and automate provisioning of resources, this self-service nirvana to eliminate shadow IT can be a reality for admins. Since blueprints contain set rules and builds sanctioned by IT, they’ll always be able to accurately and securely deliver the right resources, without users going rogue and out of compliance with taking provisioning into their own hands.

For instance, IT can determine who can order servers, workloads and XaaS—along with quotas set for spend and resource usage—to who can approve fulfillment of those orders. This way, resources are never over-provisioned and a real tally is kept as to exactly who is using which resources across the business. By automating routine approval processes and applying the proper conditions to user requests, the errors and time associated with manual provisioning are eliminated and users can get what they need without going at it alone.

Control Doesn’t Have to Come at the Cost of Delight

In the absence of the right tools and the right processes, IT can start to seem like a slow-moving gatekeeper to DevOps teams, who need resources fast. Consuming resources needs to be easy and quick for agile developers who need to ship products to market fast. In this sense, the self-service IT model plays greatly to agility: By presenting only the resources needed for DevOps teams, and orchestrating automated processes, resources are provisioned in seconds versus the days involved with an IT ticket. Additionally, with built-in, automated permissions and role-based controls, IT teams can still protect the enterprise, as they should, but at the same time delight users.

Take for example an organization as big as Home Depot, with over 385,000 employees: By rolling out a self-service approach to provisioning resources, they were able to completely reign in VM sprawl and at the same time make their developers’ lives easier with a provisioning time decreased from two weeks to just under 20 minutes.

Indeed, IT admins can win the hearts of DevOps and at the same time win back their role as an enabler of enterprise-wide innovation. By empowering users with intuitive self-service to quickly get resources when they need them, IT becomes the heroes that enterprises–and their DevOps teams—need.

— Brian J. Kelly

October 16, 2019
Modern Workers Demand Modern Technology

Companies today must think of their employees as customers and employ technology, including mobile apps, that employees want to use.

I have always been a bit of a technophile. Many years ago, in another life, when I worked in technology sales, I was one of the first sales engineers on my team to buy a personal laptop to use as a way to manage leads and accounts. The advantages of doing so over pen and paper became clear to me within weeks. I was able to track my activities more effectively and follow-up more precisely than my associates.

For similar productivity reasons, I also equip my home office with the best tools that make the most sense from a productivity standpoint. This has been true for both the years I worked out of my home office self-employed and as an employee.

I expected the tech I bought for my work to always be better than the tech that was provided to me by my employers. I grew to dislike the outdated computers, software and support services provided by employers. Why didn’t these employers invest in their employees to make them as productive as possible? There was never a good answer to that question.

However, in the late 1980s and early 1990s, I was an outlier. Most workers didn’t have personal computers and most appreciated whatever outdated green screen hardware and software was planted in front of them. Today, it’s the other way around: Employees don’t just want state-of-the-art technology that matches their work—they demand it.

Consider a recent note from research firm Gartner that found outdated technology pushes Australian workers away from their employers. In fact, Gartner’s “Q4 2018 Global Talent Monitor” found that technology now ranks ninth in the top 10 reasons Australian employees will leave their current role.

“People have become so used to advanced technology in their day-to-day lives, that they expect the same thing from their workplace. However, businesses are having a hard time matching the speed at which technology is adopted at home,” noted Aaron McEwan, human resources advisory leader at Gartner. “It’s not surprising that employees are becoming frustrated when they find themselves wasting valuable time navigating complicated systems and processes that utilize slow and old technology. It’s unproductive and inefficient for everyone involved.”

According to McEwan, businesses no longer can ignore the needs of their employees and must start thinking of them as they do their customers, making it a priority to offer a personalized, seamless and efficient experience.

This recent Gartner Australian survey taps into trends that have been underway for some time. A few years ago, Microsoft partnered with SurveyMonkey to conducted a survey of about 1,000 millennials in the United States. That survey found 93 percent of respondents said modern technology was one of the top aspects of a good workplace.

This isn’t just about new hardware or off-the-shelf software. It’s also about custom-built enterprise apps. For decades it has been accepted practice that enterprise software didn’t have to compete with consumer software, and poor-to-lackluster design was considered acceptable.

This is no longer the case. Most employees today are technically savvy and their enterprise apps are on their tablets and phones, right next to the consumer apps that they love to use.

Enterprise IT can try to force them to use leaden software, but this strategy increasingly is unlikely to prove productive. If they don’t like a collaboration platform, they’ll turn to one of the widely available cloud alternatives. If they don’t like the enterprise CRM, they’re likely to turn to Salesforce or a competitor.

When consumer apps are designed—think Evernote, Uber, Instagram or another favorite consumer mobile app—a considerable amount of thought is invested into the user interface and making the app enticing to use, designing an intuitive workflow and hiding complexity from the user into the background of the app. The same should be true for the enterprise apps designed for the enterprise.

A recent survey from Adobe found that 61 percent of 1,500 enterprise leaders believe organizations that don’t deploy mobile apps are at a competitive disadvantage. I’d take that a step further and conclude that deploying isn’t enough. But it’s more than simply deploying an app; organizations that don’t deploy effective and compelling apps will find they are at a competitive disadvantage.

— George V. Hulme

March 28, 2019