Cloud Computing Comes of Age

The term cloud computing emerged as a buzzword in the early 2000s, but it has since matured into a foundational pillar of enterprise IT strategy. According to Gartner figures cited in the original source, the worldwide public cloud service market was projected to reach $331.2 billion by 2022, growing at a compound annual growth rate (CAGR) of 12.6% from 2018.

Two factors consistently drive cloud adoption at the enterprise level: agility and cost efficiency. Cloud infrastructure allows organisations to respond faster to shifting market conditions and evolving customer expectations, while freeing IT leaders to focus on data-backed strategy rather than reactive infrastructure management.

Understanding the Need for Business Agility

Business agility is not a one-size-fits-all requirement. The urgency and scope of agility vary significantly between departments and functions within the same organisation.

Consider a retailer aiming to double revenue through an e-commerce channel. In this scenario, improving customer experience becomes a critical priority—far more pressing than incremental changes to product management workflows. Recognising where agility delivers the greatest return prevents organisations from attempting a costly, uniform cloud transformation across the entire IT landscape when budget and capacity are limited.

The first step, therefore, is a deliberate assessment: which parts of the business genuinely require agility, and in what timeframe? This prioritisation shapes every subsequent technology and architecture decision.

Building Agility: A Process-First Approach

Many organisations make the mistake of leading with technology. A more sustainable approach starts with process redesign before selecting tools or platforms.

Refine and Reimagine Processes for a Digital-Native World

Established organisations with complex, legacy systems must reimagine their business processes before attempting to migrate or modernise at scale. Useful techniques include:

• Continuous feedback loops from user groups to surface friction points early
• Design thinking workshops to generate and validate ideas for efficiency improvements
• Guided practices and instant simulation to reduce decision latency
• Iterative prototyping to test process changes before full implementation

A practical example: food delivery aggregators do not rely on order history alone when generating recommendations. They factor in delivery location, order type, time of day, and user behaviour patterns. Investing in a real-time digital data platform that enables on-the-fly analysis and personalisation allows organisations to increase customer wallet share—a capability that process redesign makes possible long before a single line of new code is written.

Select Technologies That Match the Redesigned Processes

Once processes have been restructured, the technology choices follow more naturally. Depending on the business domain and scale requirements, the modern cloud-native stack may include:

• Microservices for decomposing tightly coupled monolithic applications
• Containers and orchestration (e.g., Kubernetes) for portability and scalability
• Platform-as-a-Service (PaaS) to reduce infrastructure management overhead
• Stream processing for real-time data pipelines
• Mobile-first APIs for customer-facing applications
• AI/ML and cognitive services for intelligent automation and recommendations
• IoT and Blockchain where supply chain transparency or device integration is required

Technology selection should be driven by the specific agility goals identified earlier—not by vendor marketing or industry trends alone.

Creating a Modern IT Landscape

The transition to a cloud-ready IT landscape typically happens along two parallel tracks:

1. Building new applications using cloud-native patterns from the outset
2. Decomposing existing monolithic applications by business domain into independently deployable microservices

Decomposition is particularly valuable for large, incumbent systems that cannot be replaced in a single migration. Breaking a monolith apart by business function allows teams to migrate and modernise incrementally, reducing risk while progressively adopting adaptive cloud architecture.

Regardless of the approach, applications operating in an interconnected business ecosystem should expose their capabilities through platform-agnostic APIs. Vendor and technology neutrality ensures that no single architectural decision locks the organisation into a dependency that limits future agility.

Scaling IT Delivery Capabilities

Technology transformation only delivers value when the people operating the systems have the skills—and the culture—to use them effectively. Scaling IT delivery capabilities requires investment in two areas:

Technical Upskilling

Engineering teams need hands-on exposure to cloud-native tooling, container orchestration, CI/CD pipelines, infrastructure-as-code, and observability practices. Formal training programmes, internal guilds, and incremental project ownership are all effective vehicles for building these skills organically.

Cultural Transformation

Technical skills alone are insufficient. Agile working practices, a tolerance for calculated risk, exploratory thinking, and psychological safety to experiment and fail fast are equally important. Organisations may choose to develop these capabilities internally or partner with an IT service provider experienced in cloud-native transformation—not only for technology expertise, but to act as a catalyst for cultural change within the IT organisation.

Key Takeaways for DevOps and Platform Teams

• Prioritise before you migrate. Map agility needs to specific business functions before committing to a broad cloud programme.
• Start with process, not platforms. Poorly designed processes migrated to the cloud remain poorly designed—just more expensive.
• Decompose incrementally. Microservices and cloud-native architectures are a journey, not a big-bang cutover.
• Build for interoperability. Platform-agnostic APIs protect long-term architectural flexibility.
• Invest in people as much as infrastructure. Upskilling and cultural change determine whether cloud investment translates into real business agility.

From a leadership perspective, it is hard to argue against the goals of the current DevOps trend. DevOps seeks to integrate the work performed by a company’s application development team with the work performed by its systems operations team. The aim is to improve the quality and flow of that work through better communication, standardization, simplification, collaboration and automation.

DevOps builds on the Lean and Agile development practices that promote systemic thinking and rapid value creation. In many ways, the DevOps trend teaches IT professionals that they are critical links in a business supply chain, rather than a collection of technical experts narrowly focused on specific IT capabilities. These are laudable aims and goals.

However, it’s important to note that these aims and goals are not new — they were not created by the DevOps movement. IT organizations have long had the means, frameworks, tools and prescriptive guidance to achieve them. Our industry is blessed with a library of best practices and guidance on how to improve communication and facilitate standardization, simplification and collaboration. IT tools for decades have been capable of much higher levels of integration and automation.

Despite the fact that the means have long been there to solve our internal IT delivery problems, the upshot is that our actual experience has been one of silo-based cultures, tribal leadership, intentional process variation and tool strategies that place more value on “best of breed” software than on integrated IT management suites.

So, is there anything different now that has not been the case for the last 20 years? Why do we think that the DevOps trend will result in success where many other frameworks have come and gone without invoking meaningful change?

The answers to these questions do not lie in what is new or unique about the DevOps trend, but in the external pressures that are driving IT to change.

Like most self-help or personal improvement programs, we typically do not pay attention or get serious about real change until there is some external force that intrudes on old habits in a way that makes it difficult if not impossible to ignore. Until the doctor gives you a shock by predicting your early demise, regular visits to the gym remain an elusive goal. Today, a multitude of urgent external drivers are forcing IT shops to change old ways– and fast.

The cloud-enabled competitor at the door

Chief among those external drivers is cloud computing — IT’s big bad wolf at the door. The availability of cloud-based services has flattened the competitive IT landscape across all industries.

The ubiquitous availability of cloud-based technical services, coupled with inexpensive offshoring options, has rendered traditional delivery models obsolete. The lease vs. buy cloud services model has leveled the playing field and enabled business competition to rapidly come to market and disrupt traditional commercial models without having made years of investment in data centers, software factories or network infrastructure.

Thus, newly formed, built-on-the-web, app-enabled brands are now able to use cloud-based services and software-as-a-service business automation for core business processes in a matter of weeks, if not days. So enabled, they come to market with new and disruptive products in a fraction of the time it would take a traditional brick-and-mortar organization to respond.

Digitally disruptive competition does not apply to just external business competition. Another, observable trend is an increase in the use of so-called shadow IT investments, i.e., line of business purchases of IT services directly from the external market or in support of their own IT capability. Often, shadow IT is due to the perception by the business that internal IT’s services are of poor quality, slow speed or cost more than what they can buy or contract for themselves. Rather than shadow IT, I prefer to call this phenomenon what it truly is: loss of market share for internal IT. If it goes on long enough and an IT organization loses the funding it requires based on expected revenue, there is only one financial outcome possible.

Disruptive competition and the emergence of DevOps

Digitally disruptive competition is at the CIO’s door. And with this new degree of external pressure, organizations are forced to finally address long-standing cultural issues, political barriers and leadership gaps that have traditionally brought most IT improvement programs to their knees. So, now is the time to change — and change rapidly — in order to survive.

The banner many organizations are flying to combat digitally disruptive competition is DevOps.

To test this hypothesis, Pink Elephant recently conducted research into the motivations and critical success factors behind DevOps adoption. This research demonstrated that out of the 160 companies surveyed, more than two-thirds are focused on increasing “speed to value” by using the various principles and practices of the DevOps movement.

A summary of some of the key findings demonstrate the reality of the DevOps movement in our industry and why we believe that the IT push to improve the quality and flow of that work through better communication, standardization, simplification, collaboration and automation is different this time around.

DevOps Adoption Is Growing — and So Are the Risks

Enterprise adoption of DevOps has steadily accelerated as organisations look to close the gap between software development and IT operations. By breaking down silos and enabling continuous delivery pipelines, DevOps helps teams ship software faster, respond to market changes more quickly, and collaborate more effectively across business functions.

But as more CIOs bring DevOps into their organisations, a critical tension is emerging: the same speed and openness that makes DevOps powerful also creates measurable security and compliance risks. Managing that tension is fast becoming one of the defining challenges for enterprise IT leadership.

The Business Case for DevOps

The appeal of DevOps to business leaders is straightforward. Faster release cycles mean faster time to market — a decisive competitive advantage in industries where digital products and services are core to the business model.

“It certainly does offer benefits in terms of time to market. In this day and age, IT is part of doing business and it has to deliver at the speed matching the need of business.”

— Sumit Singh, CIO, Wockhardt Hospitals Ltd.

Singh notes that Wockhardt Hospitals deployed a small, dedicated team working in a DevOps-like model to deliver a GST compliance project — an example of how even traditionally conservative sectors such as healthcare are experimenting with agile delivery practices.

“DevOps will reduce risk and improve quality of IT delivery. This is not risky and no worry, mainly because we are using DevOps as a copy of productions — a simulated environment — and this is very much required for the future to address statutory changes like GST.”

— Satyanarayana Kasturi, GM & CIO – Projects Business, Essar Projects (India) Limited

The drive toward continuous innovation is another core motivator. As Arsalaan Kashif, Associate Director of Product Engineering Services at Happiest Minds Technologies, puts it:

“DevOps is driven by the need to continuously innovate and deliver, to reach the market before the ever-shrinking window of opportunity shuts down.”

— Arsalaan Kashif, Happiest Minds Technologies

Where DevOps Creates Security and Compliance Risk

The same urgency that drives DevOps adoption can undermine security. When teams are under pressure to ship continuously, security reviews and compliance checks are frequently treated as friction rather than fundamentals — and they get skipped.

“Even with the best of intentions in place, the rush to deliver on tight deadlines can cause DevOps teams to cut corners and be out of compliance with their company’s security policies. As security teams are left in the dark, there could be a lapse in judgement about what potentially is leaked to the internet, exposing the organization to unnecessary risk.”

— Arsalaan Kashif, Happiest Minds Technologies

Privileged access is a particularly acute concern. DevOps environments depend heavily on automation, scripts, and service accounts — all of which require credentials. If those credentials are poorly managed, they become high-value attack targets.

“DevOps is an area which again is a bit of a challenge in terms of cybersecurity because the developers would typically want to access everything and anything that means agility for software development. The DevOps team would download a lot of freeware and experiment with it, as they would want to test all possible conditions because they want to have agility, but don’t want laws around it.”

— Rohan Vaidya, Regional Director – Sales India, CyberArk

CyberArk is an enterprise security company specialising in privileged access management, including purpose-built tooling for securing DevOps pipelines and secrets management. The risks Vaidya describes — unmanaged credentials, ungoverned tool downloads, over-permissioned service accounts — are well-documented attack vectors in modern CI/CD environments.

The Answer: DevSecOps and Continuous Security

The consensus among practitioners is that treating security as a post-delivery audit is incompatible with DevOps. Instead, security must be embedded into the pipeline itself — shifting left so that vulnerabilities are caught earlier and more cheaply.

“The key ingredient of DevOps is the automation of infrastructure, testing and delivery. In my opinion, to make it safe, DevOps needs to become DevSecOps — which means security and risk assessment need to become continuous and adaptive. Like Continuous Integration and Continuous Delivery (CI/CD), security needs to become continuous as well. In many organisations the code will be shipped to a security team to assess vulnerabilities, which can take days to weeks. In DevSecOps, this process needs to be automated as part of the Continuous Delivery framework.”

— Meerah Rajavel, CIO, Forcepoint

Rajavel’s point is practical and well-supported by industry experience. Manual security reviews at the end of a sprint create bottlenecks, delay releases, and generate friction between security and engineering teams. Automating vulnerability scanning, compliance checks, and secrets detection within the CI/CD pipeline removes that bottleneck without sacrificing security rigour.

What DevSecOps Looks Like in Practice

• Shift-left security testing: Static application security testing (SAST) and dependency scanning run automatically on every code commit, not just at release time.
• Secrets management: Credentials, API keys, and certificates are managed through a dedicated secrets manager (such as HashiCorp Vault or a cloud-native equivalent) rather than hardcoded in repositories.
• Policy-as-code: Infrastructure and deployment policies are codified and enforced automatically, preventing out-of-compliance configurations from reaching production.
• Continuous monitoring: Runtime security monitoring and logging are built into the deployment pipeline, not bolted on afterwards.
• Penetration testing cadence: Regular pen tests and red team exercises are scheduled as ongoing operations, not one-off pre-launch activities.

The Adaptive Risk Model: CARTA

The broader strategic framework for this approach is the concept of Continuous Adaptive Risk and Trust Assessment (CARTA), a model introduced by Gartner. CARTA argues that in a digital-first environment, static perimeter-based security is insufficient. Instead, organisations must continuously evaluate risk and trust in real time, adjusting access and controls dynamically based on context.

For CIOs pursuing digital transformation — where DevOps and Agile are core delivery tools — CARTA provides a governance framework that accommodates speed without abandoning risk management. The emphasis is on monitoring, adaptive response, and continuous learning rather than binary allow/deny decisions made at a fixed point in time.

Organisational Culture Is the Hardest Problem

Technology and tooling are only part of the challenge. DevOps — and by extension DevSecOps — requires a cultural shift that many enterprises find difficult to sustain.

“A ‘generative’ culture where information and ideas are exchanged freely is critical for DevOps to succeed. When the core driving principle is ‘failing fast’ and learning from it, it is important to foster an environment where failures aren’t brushed under the carpet. Collaboration is another key factor that cannot be overstated. Apart from the development and operations teams coming together, there is also a need to collaborate with the security group to ensure compliance and high-quality releases that aren’t just timely but secure.”

— Arsalaan Kashif, Happiest Minds Technologies

This is a well-established finding in DevOps research. The Westrum organisational model — which categorises cultures as pathological, bureaucratic, or generative — has been cited in multiple State of DevOps reports as a strong predictor of software delivery performance. Teams operating in generative cultures consistently outperform those in more siloed environments, regardless of the tools they use.

Introducing security as a shared responsibility — rather than a gate owned exclusively by a separate security team — requires trust, clear communication, and executive support. CIOs play a pivotal role in creating the conditions for that cultural change.

What CIOs Should Do

Forcepoint CIO Meerah Rajavel offers a useful analogy: the goal of business is to fly high and fast, which carries inherent risk. The CIO’s job is not to ground the aircraft — it is to design a flight system safe enough to fly confidently.

“The CIO job should be to design a solid security and risk framework, which will enable the business to fly safe, not hold them back saying flying is dangerous.”

— Meerah Rajavel, CIO, Forcepoint

Practically, that means CIOs should:

• Reframe the security conversation: Position security as a delivery enabler, not a blocker. Automated security in the pipeline means fewer late-stage surprises, not slower releases.
• Mandate DevSecOps from the start: Security requirements, threat modelling, and compliance checks should be part of project inception, not a review that happens after the code is written.
• Invest in automation: Manual security gates do not scale with DevOps velocity. Tooling for SAST, DAST, secrets scanning, and infrastructure compliance checks must be embedded in CI/CD pipelines.
• Build cross-functional security literacy: Developers do not need to become security specialists, but they do need enough context to write defensively and recognise risk.
• Communicate risk transparently to business stakeholders: Business leaders who understand the risk landscape can make better-informed decisions about acceptable trade-offs between speed and security.
• Adopt an adaptive monitoring posture: Assume breach. Invest in runtime monitoring, anomaly detection, and incident response capabilities that work continuously — not just at release time.

Bottom Line

DevOps is not a passing trend — it is the operational model that modern software delivery is built around. But its benefits are only sustainable when security is treated as a first-class concern, not an afterthought. The shift from DevOps to DevSecOps is less a change of tooling than a change of mindset: security belongs in every sprint, every commit, and every deployment — not just at the end of the release cycle.

CIOs who build that security-first culture, automate compliance within their pipelines, and communicate risk clearly to business stakeholders will be positioned to capture the full value of DevOps without exposing their organisations to avoidable harm.