Retail’s Data Problem — and Its Opportunity

Retailers, consumer packaged goods (CPG) manufacturers, and e-commerce companies generate enormous volumes of data every day. That data flows in from online and mobile transactions, in-store point-of-sale systems, social media interactions, supply chain feeds, and Internet of Things (IoT) sensors. Despite the scale of this resource, most of it goes unused — locked away in legacy systems and organisational data silos.

The COVID-19 pandemic accelerated a shift that was already underway. Lockdowns and changed consumer behaviour pushed shoppers online and forced retailers to rapidly expand their digital presence. As the sector recovers, cloud computing and data analytics have moved from optional investments to operational necessities.

Why Legacy Infrastructure Holds Retailers Back

Analysing large volumes of data across customers, product trends, and supply chains can surface insights that directly improve decision-making and customer satisfaction. However, several structural barriers prevent retailers from realising that value:

• Data silos: Customer data, inventory data, and logistics data often live in separate systems that don’t communicate with each other.
• Legacy systems: Older on-premises infrastructure lacks the flexibility and compute capacity to run modern analytics workloads at scale.
• Poor data governance: Fragmented data management creates security risks and makes real-time data sharing difficult or impossible.
• Slow time-to-insight: Batch-oriented reporting cycles mean decisions are based on stale information rather than current conditions.

Cloud platforms address these issues directly: they provide elastic compute, centralised data storage, built-in security controls, and native integrations with modern analytics tooling.

Key Ways Cloud and Analytics Deliver Value in Retail

1. Predictive Analytics for Supply Chain and Inventory

Supply chains are complex, multi-layered systems where a single bottleneck — a delayed shipment, a demand spike, an out-of-stock item — can cascade into significant revenue loss. Predictive analytics helps retailers get ahead of these problems rather than react to them.

Cloud data warehouses and machine learning pipelines can ingest granular, semi-structured data from every stage of the supply chain — purchase orders, logistics tracking, warehouse sensors, and point-of-sale records — and use that data to forecast demand at the SKU level. Retailers can then:

• Anticipate when specific items will be in high demand and pre-position inventory accordingly.
• Identify underperforming suppliers or logistics routes before they become critical failures.
• Run multiple demand-forecasting models in parallel using cloud-native concurrency, without performance degradation.
• Reduce overstock and stockout costs by making replenishment decisions on real-time data rather than historical averages.

2. Granular, Hyperlocal Business Insights

Successful retail decisions are rarely made at a global level. The most impactful choices happen at the regional or individual store level — what to stock based on local weather patterns, how many staff to schedule during a local holiday, which suppliers offer the best combination of price and delivery time for a given geography.

Cloud data platforms make this hyperlocal analysis practical by consolidating structured and semi-structured data from multiple sources into a single, centralised repository. From there, analysts can drill down to any level of granularity — national trends, regional patterns, or store-by-store comparisons — without maintaining separate reporting infrastructure for each view. This single source of truth enables both strategic planning and day-to-day operational decisions.

3. Personalised Marketing and Customer Reach

E-commerce platforms produce rich behavioural data: what customers browse, what they purchase, how long they spend on a product page, what they abandon in their cart. When this data is accessible and well-structured, marketing teams can move from broad campaigns to highly targeted, personalised outreach.

Cloud data platforms aggregate signals from internal systems (purchase history, loyalty programmes, CRM records) and external sources (social media, third-party market data) into a unified customer profile. Retailers can use this to:

• Serve product recommendations tailored to individual browsing and purchase history.
• Time promotions to moments when a specific customer is most likely to convert.
• Segment audiences with precision and test messaging across channels before broad rollout.
• Measure campaign ROI against actual purchase data rather than proxy metrics.

4. Omnichannel Experience Delivery

Consumers increasingly expect a seamless experience across every touchpoint — browsing online, picking up in-store, returning via a mobile app, or speaking with an in-store associate who can see their full purchase history. Delivering this requires real-time data synchronisation across channels, which is operationally impractical on disconnected legacy systems.

Cloud infrastructure, with its shared data layer and API-driven architecture, is foundational to omnichannel retail. Inventory levels, customer profiles, and order status can be updated and read in real time regardless of which channel triggered the transaction. This enables the hybrid online-and-physical models — buy online, pick up in store (BOPIS); ship from store; endless aisle — that modern consumers expect.

Practical Considerations Before Adopting Cloud Analytics

Technology investment alone does not guarantee results. Retailers looking to adopt cloud and analytics solutions should evaluate the following before committing to a platform:

• Data quality: Analytics outputs are only as reliable as the underlying data. Investing in data governance and cleansing processes before migrating to the cloud reduces the risk of building predictions on corrupted or incomplete records.
• Integration complexity: Connecting cloud platforms to existing ERP, POS, and logistics systems takes time and expertise. Assess integration requirements and vendor support early.
• Skills and organisational readiness: Cloud-native analytics tools require skilled engineers and data analysts to operate effectively. Factor in training and hiring needs.
• Vendor lock-in: Major cloud providers offer proprietary analytics services that can create dependency. Where possible, favour open standards and portable data formats.
• Security and compliance: Customer purchase data is sensitive. Ensure cloud configurations meet applicable data protection regulations in your markets.

The Outlook for Data-Driven Retail

The structural shift toward online and hybrid retail is not temporary. Consumer behaviour changed during the pandemic, and many of those changes are now baseline expectations. Retailers that treat cloud computing and data analytics as core infrastructure — rather than experimental projects — are better positioned to respond quickly to market shifts, manage supply chain disruptions, and deliver the personalised experiences that drive loyalty.

The competitive advantage in retail is increasingly determined not by what products a retailer carries, but by how effectively it uses data to make every decision — from pricing and stocking to marketing and fulfilment — faster and more accurately than its competitors.

The Scale of the Legacy Problem

Banking technology moves slowly — sometimes by design, often by inertia. According to PYMNTS reporting, a significant share of financial institutions were still only beginning to adopt cloud computing solutions as recently as 2020, and the majority of the world’s largest banks continued to rely on physical mainframes running architectures designed in the previous century.

The reasons are well understood inside the industry: regulatory obligations, data residency requirements, decades of accumulated technical debt, and a reasonable caution about moving mission-critical systems. But those justifications are increasingly difficult to defend as digital-native competitors demonstrate what cloud-first banking actually looks like at scale.

Why Challengers Have the Upper Hand

Challenger banks such as Monzo and Revolut were built on cloud infrastructure from day one. They have no mainframes to decommission, no batch-processing windows to work around, and no organisational inertia tied to legacy vendor contracts. According to the PYMNTS Tracker, many FinTechs and digital- or mobile-only banks are following the same model, using cloud platforms to deliver core banking services with a responsiveness that traditional institutions struggle to match.

The competitive urgency this creates for legacy banks is real. Customers increasingly expect instant decisions, 24/7 availability, and seamless digital experiences. Branches are secondary. Digital is the default. For a bank still hunting through distributed mainframe records to answer a customer query, that expectation gap is a material business risk.

What “The Data Hunt” Actually Costs

One of the more concrete operational problems the PYMNTS Tracker identifies is what practitioners call the “data hunt” — the process of locating and reconciling customer or transaction data spread across siloed mainframe systems. This is not a theoretical inconvenience. It directly affects the speed at which a bank can respond to customer requests, investigate disputes, or model risk.

Cloud-based data platforms consolidate that information into accessible, queryable stores. BNP Paribas, cited in the Tracker, identified this as a key motivation for building out its private cloud capability — not just to modernise for modernisation’s sake, but to remove the operational friction of chasing data across legacy infrastructure while also creating a foundation for online banking innovation.

Blackrock, the asset management firm, took a different route, partnering with Microsoft Azure to gain both scale and an innovation platform. The examples illustrate that there is no single cloud migration playbook — the right approach depends on the institution’s size, regulatory environment, and strategic priorities.

Technology Partnerships Expanding What’s Possible

One pattern emerging across the industry is the use of targeted technology partnerships to accelerate cloud adoption without requiring a full-scale rip-and-replace of existing systems. The Tracker points to a partnership between banking software company Temenos and distributed SQL database company NuoDB as an illustrative example.

The collaboration allowed challenger banks to access Temenos banking software delivered via cloud, including tooling designed to handle customer queries rapidly and reduce infrastructure overhead. For institutions with limited capital to allocate to infrastructure, reducing that cost base frees budget for product development and customer-facing innovation — which is precisely where challenger banks want to compete.

Agility as an Operational Requirement, Not a Buzzword

In financial services, the word “agility” is often used loosely. The PYMNTS Tracker gives it a more operational definition, particularly in the context of unpredictable demand events. Ariff Kassam, then Chief Technology Officer at NuoDB, articulated the requirement clearly in comments to PYMNTS:

“Business processes and technical infrastructure must be agile enough to ensure a quick response to changing requirements. An agile infrastructure allows companies to accommodate surges or reductions in demand. A firm’s connected ecosystem should enable this agility, which means choosing technology partners that support it.”

Ariff Kassam, CTO, NuoDB (via PYMNTS)

The context here is significant. The original reporting coincided with the early months of the COVID-19 pandemic, when financial institutions faced sudden, massive shifts in transaction volumes — particularly around contactless payments and digital banking adoption. Infrastructure that cannot scale dynamically becomes a direct liability under those conditions. Cloud-native elastic scaling is not a feature; in that environment, it is a continuity requirement.

Key Takeaways for DevOps and Platform Teams in Financial Services

• Legacy mainframes are an organisational risk as much as a technical one. The inability to scale quickly or access data efficiently has measurable business consequences in competitive markets.
• Cloud migration strategies vary. Private cloud (BNP Paribas), hyperscaler partnerships (Blackrock/Azure), and SaaS delivery via vendor partnerships (Temenos/NuoDB) are all valid paths depending on context.
• Elastic scalability is a concrete operational advantage, not a marketing claim. Demand spikes — whether from a pandemic, a market event, or a product launch — expose the limits of fixed-capacity infrastructure immediately.
• Data architecture is central to the cloud case. Consolidating fragmented mainframe data into accessible cloud stores directly improves customer service response times and analytical capability.
• Challenger banks set the competitive baseline. Institutions evaluating cloud adoption should benchmark their target state against digital-native competitors, not against their own previous performance.

The original PYMNTS Digital Banks And The Power Of The Cloud Tracker® was produced in collaboration with NuoDB. Readers seeking the full data and case studies should refer directly to the PYMNTS source publication.

Why Scaling DevOps Is Harder Than Starting It

Early DevOps adoption tends to succeed because it is contained: a small team, clear ownership, and a single delivery pipeline. When leadership asks that same team to replicate the model across dozens of teams and hundreds of services, the informal knowledge and ad-hoc processes that drove initial wins become liabilities.

A common pattern is what practitioners sometimes call the “trailblazer problem”: an organization runs a successful proof-of-concept project but fails to document the practices, decisions, and tooling choices that made it work. Other teams then have nothing concrete to follow, so they start from scratch — or worse, implement inconsistent variants that create integration and governance headaches later.

Hyper-growth engineering organizations face a compounding version of this problem. As team size increases, tracking changes across the whole group becomes difficult. Engineers find themselves unable to understand what other teams have shipped, which creates duplicated effort, merge conflicts, and operational blind spots.

Step One: Build Reusable Processes Before Adding More Teams

The single most important prerequisite for scaling DevOps is standardization. Before onboarding a second or third team onto a DevOps model, invest time in making the first implementation repeatable:

• Document your pipelines as code. CI/CD pipeline definitions, infrastructure templates, and environment configurations should live in version control. New teams can fork a reference implementation rather than building from nothing.
• Create golden-path tooling. Offer opinionated, pre-configured templates for the most common use cases (containerized microservices, scheduled batch jobs, static front-ends). Teams that want to deviate can, but the default path should require the least effort.
• Define shared quality gates. Agree on minimum standards — automated test coverage thresholds, security scanning steps, required approval workflows — before those standards need to be enforced across dozens of pipelines.
• Measure from the start. Capture baseline metrics (deployment frequency, lead time for changes, change failure rate, mean time to restore) on the pilot project so you have a concrete benchmark to compare against as you scale.

The key principle is that agility and standardization are not opposites. Standardizing the scaffolding — how services are built, tested, deployed, and observed — frees teams to focus their creativity on solving business problems rather than reinventing infrastructure decisions.

Securing Top-Level Leadership Support

DevOps scaling is not purely a technical exercise. It requires organizational change: shifting incentives, restructuring teams, and sometimes renegotiating how success is measured. That level of change requires visible, sustained support from senior leadership.

C-level executives and VPs who actively champion DevOps do several concrete things that accelerate adoption:

• Remove organizational blockers. Cross-team dependencies, budget silos, and approval bottlenecks rarely get resolved without executive authority.
• Signal cultural permission to change. Engineers and managers watch leadership behavior closely. When senior leaders visibly support blameless post-mortems, experimentation, and shared ownership of reliability, those values propagate downward.
• Connect DevOps metrics to business outcomes. Leaders who translate deployment frequency and MTTR into customer impact and revenue make the business case for continued investment, which sustains momentum through the inevitable rough patches of a scaling effort.

Conversely, organizations that try to scale DevOps as a purely grassroots effort — without leadership alignment — often find that the transformation stalls at team or department boundaries where politics, budgets, and competing priorities create friction that engineers alone cannot resolve.

Choosing and Standardizing Your Toolchain

One of the most consequential decisions in scaling DevOps is tool selection. The DevOps ecosystem is broad — configuration management, CI/CD, container orchestration, secrets management, observability — and organizations frequently end up with overlapping tools that serve similar purposes, increasing cognitive load and maintenance burden.

Commonly used tool categories and examples include:

• Configuration management: Ansible, Chef, Puppet, Salt — used to define and enforce the state of infrastructure and application environments.
• CI/CD orchestration: Jenkins, GitLab CI, GitHub Actions, CircleCI — used to automate build, test, and deployment pipelines.
• Container platforms: Docker for packaging, Kubernetes for orchestration — widely used to achieve environment consistency and improve deployment velocity.
• Version control and collaboration: GitHub, GitLab, Bitbucket — the foundation of any modern software delivery workflow.

A pragmatic approach for most enterprises is to standardize on a core toolchain that covers 80–90% of use cases, while explicitly allowing teams to use alternative tools when they have a documented, justified reason. The goal is consistency without rigidity.

Containers deserve special attention during scaling. Containerizing workloads increases environment parity between development and production, reduces the “works on my machine” class of bugs, and makes deployments more reproducible. Starting with small, non-critical workloads before migrating production services reduces the risk of learning containerization pitfalls in high-stakes environments.

Using Metrics to Drive and Justify Scaling Decisions

Scaling without measurement is guesswork. A proof-based approach ties each DevOps initiative to specific, measurable outcomes — and uses those outcomes to prioritize where to invest next.

Useful metrics for DevOps scaling programs typically fall into several categories:

• Delivery performance: Deployment frequency, lead time for changes. These indicate how efficiently the engineering organization turns work into shipped software.
• Stability: Change failure rate, mean time to restore (MTTR). These signal whether faster delivery is coming at the cost of reliability.
• Operational efficiency: Infrastructure cost per deployment, time spent on manual toil. These connect DevOps investment to direct cost savings.
• Business outcomes: Release cycle time relative to competitors, customer-reported incidents, feature delivery timelines. These make the business case to leadership.

Metrics also help identify where scaling is bottlenecked. If deployment frequency is high but MTTR is worsening, the scaling effort may be outpacing the observability and incident-response practices needed to support it.

Treating Failure as a Scaling Input, Not a Setback

At scale, failures are inevitable — and the organizations that scale DevOps most effectively treat failures as learning inputs rather than exceptions to be suppressed. This means:

• Conducting blameless post-mortems after significant incidents and publishing their findings broadly, so all teams benefit from the lessons.
• Building rollback and feature-flag capabilities into pipelines so that failed deployments can be reversed quickly without requiring emergency escalations.
• Tracking failure patterns over time to identify systemic weaknesses — for example, a particular service that consistently causes incidents during deployments may need architectural attention, not just better runbooks.

Normalizing failure also reduces the fear that causes teams to avoid deploying frequently, which is one of the most common self-defeating patterns in organizations attempting to scale DevOps.

Modernizing Existing Services During the Scale-Out

Scaling DevOps rarely happens in a greenfield environment. Most organizations have a mix of legacy applications, monolithic architectures, and manual processes that must be migrated or modernized alongside the scale-out effort. A few principles help manage this:

• Migrate incrementally. Attempting a big-bang migration of all services to new pipelines and tooling simultaneously creates unacceptable risk. Prioritize high-change-frequency services first, as they benefit most quickly from automation.
• Do not require perfection before onboarding. A service that ships to a basic CI pipeline with automated testing is meaningfully better than one that ships manually. Teams can mature their pipelines over time.
• Involve the people closest to the systems. Engineers who maintain existing services understand the edge cases, dependencies, and constraints that architects and platform teams may not. Their involvement in migration planning reduces surprises.

Summary: What Successful DevOps Scaling Looks Like

Scaling DevOps is fundamentally an organizational capability-building exercise, supported by — but not reducible to — tooling and automation. The organizations that do it well share several characteristics:

• They document and codify what works before expanding it to new teams.
• They have active, visible leadership support that removes organizational blockers.
• They maintain a coherent, justified toolchain rather than accumulating point solutions.
• They measure delivery performance and stability continuously, and use those metrics to make investment decisions.
• They treat failure as data and build the organizational muscle to respond to it quickly and learn from it systematically.

Done well, scaled DevOps allows engineering organizations to ship more reliably, respond to business needs faster, and build institutional knowledge that compounds over time — without burning out the teams that make it work.

Overview: Azure VMware Solution Gets a Significant Refresh

In May 2020, Microsoft quietly made a significant change to its Azure VMware Solution (AVS), repositioning it as a genuine first-party Azure service. The key benefit for operations and infrastructure teams: existing on-premises VMware workloads can now be migrated to Azure without needing to re-architect applications first — a classic lift-and-shift capability, but delivered inside the Azure ecosystem.

What Azure VMware Solution Offers

The service provisions a full VMware Cloud Foundation environment on Azure infrastructure, giving customers a familiar VMware operational experience within a public cloud. Core components included at the time of this announcement were:

• VMware vSphere — the core hypervisor and virtualization platform
• VMware NSX-T — software-defined networking and security for the data center
• VMware vSAN — hyperconverged infrastructure (HCI) for software-defined storage
• VMware HCX — application mobility and workload migration platform

Customers can also add VMware HCX Enterprise, which extends compatibility so that older versions of vSphere running on-premises can interoperate with newer vSphere versions running on the Azure VMware Solution platform. This is particularly valuable for organisations with heterogeneous VMware estates that cannot easily standardise on a single vSphere version before migrating.

A First-Party Microsoft Service: What That Means Operationally

Takeshi Numoto, Microsoft’s commercial CMO at the time, described AVS as a “first-party service from Microsoft” — meaning it is directly owned, operated, and supported by Microsoft rather than delivered through a third-party or partner arrangement. For DevOps and platform engineering teams, this distinction matters for several practical reasons:

• Single support contact: Teams deal with Microsoft for both Azure infrastructure and VMware layer issues, rather than managing split accountability between vendors.
• Integrated billing: The service appears on the standard Azure invoice.
• SLA alignment: Microsoft owns the full stack commitment, not just the underlying hardware.
• Single-tenant architecture: Microsoft explicitly noted it rearchitected the preview to focus on a “single-tenant user experience”, which has security and performance isolation implications for enterprise workloads.

Regional Availability at Launch

At the time of this announcement (May 2020), Azure VMware Solution was available as a preview in two regions: Azure US East and West Europe. General availability and broader geographic expansion were planned for later in 2020. Teams evaluating the service today should consult the current Azure VMware Solution product page for up-to-date regional coverage, as availability has expanded significantly since the original preview.

History: How AVS Evolved from the 2019 Announcement

Microsoft first unveiled an Azure VMware service in 2019 as part of a broader partnership involving VMware and its parent company Dell Technologies. That initial arrangement bundled several integrations:

• Joint management of Microsoft 365 and VMware Workspace ONE across devices via Microsoft Intune and Azure Active Directory
• Extended Windows Virtual Desktop capabilities through VMware Horizon Cloud on Microsoft Azure

At the time, Dell Technologies CEO Michael Dell described the intent as providing “a single view from edge to core to cloud — an integrated platform for our customers’ digital future.”

The 2020 refresh was more than an incremental update. According to a Microsoft spokesperson quoted by SDxCentral: “It is an entirely new service. Since the launch of Azure VMware Solutions in May 2019, we have rearchitected the preview to focus on a single-tenant user experience and our first-party technology.”

Competitive Context: AVS vs. VMware Cloud on AWS

Azure VMware Solution competes directly with VMware Cloud on AWS, a partnership that VMware and AWS initiated in 2017. VMware’s CEO Pat Gelsinger characterised that AWS offering as “the ultimate hybrid solution” — a claim that reflects how seriously VMware treated its AWS relationship.

For infrastructure and platform teams evaluating multi-cloud or hybrid VMware strategies, the choice between AVS and VMware Cloud on AWS typically comes down to:

• Existing cloud contracts and commitments — Azure vs. AWS enterprise agreements
• Integration requirements — whether workloads are tightly coupled to Azure-native services (Active Directory, Azure Monitor, ExpressRoute) or AWS-native services
• Support model preferences — Microsoft owning the full stack on AVS vs. the joint VMware/AWS model
• Regional availability at the time of deployment

Key Takeaways for DevOps and Infrastructure Teams

• AVS enables genuine lift-and-shift of VMware workloads to Azure, preserving existing VMware tooling and operational processes.
• The single-tenant architecture and first-party support model reduce vendor ambiguity for enterprise teams.
• HCX Enterprise support for older vSphere versions lowers the barrier for organisations with legacy VMware infrastructure.
• Organisations already invested in Azure identity, networking, and monitoring tooling will find native integration with AVS smoother than a competing cloud alternative.
• This announcement dates from May 2020; current pricing, region availability, and feature set have evolved. Always validate against current Microsoft documentation before committing to architecture decisions.

Why SMBs Keep Choosing Microsoft Azure

Building the right technology stack used to mean negotiating contracts with multiple vendors, each responsible for a narrow slice of the overall solution. Microsoft Azure, combined with Microsoft 365 (formerly Office 365), reduces that complexity by providing a broadly integrated ecosystem: identity management through Azure Active Directory, productivity applications, storage, compute, and developer tooling all sit under the same vendor relationship and billing umbrella.

For smaller organizations with lean IT teams, the practical benefits of this consolidation include:

• Fewer integration points to maintain: Services within the Microsoft ecosystem are designed to work together out of the box, reducing the custom glue code and middleware that multi-vendor stacks often require.
• Simplified licensing and support: A single vendor relationship means a single support channel for a large portion of the stack.
• Familiar tooling for staff: Teams already using Microsoft 365 face a shorter learning curve when extending into Azure compute or storage services.
• Predictable cost modelling: Pay-as-you-go pricing, reserved instances, and Azure Hybrid Benefit (for organizations with existing Windows Server or SQL Server licences) give finance teams more levers to control spend.

Security and Compliance in the Azure Ecosystem

Security is a recurring concern for SMBs that handle sensitive customer data, financial records, or health information. Azure’s security capabilities span several layers:

• Azure Active Directory (Azure AD): Centralised identity and access management with support for multi-factor authentication and conditional access policies.
• Microsoft Defender for Cloud: Continuous security posture assessment across Azure resources, with recommendations mapped to common compliance frameworks.
• Encryption at rest and in transit: Azure storage services encrypt data by default, and Transport Layer Security (TLS) is enforced for data in transit.
• Role-Based Access Control (RBAC): Granular permissions prevent over-provisioning and limit the blast radius of compromised credentials.
• Compliance certifications: Azure holds a broad range of third-party compliance certifications (ISO 27001, SOC 2, HIPAA, GDPR alignment, and others), which can simplify an SMB’s own compliance audits.

Integrating storage, identity, and compute under one security framework reduces the attack surface created when data crosses boundaries between unrelated vendor systems. It also means security policies can be enforced consistently rather than replicated independently in each tool.

Public, Private, and Hybrid Cloud: A Practical Primer

Choosing the right cloud model is not a one-size-fits-all decision. The correct mix depends on your compliance obligations, data sensitivity, uptime requirements, and internal IT capacity. Here is how the three primary models compare.

Public Cloud

In a public cloud deployment, infrastructure is owned and operated by a cloud provider and shared — in logically isolated partitions — across many customers. Azure’s public cloud regions deliver Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS) offerings: virtual machines, managed databases, Kubernetes clusters, serverless functions, and more.

Best suited for: workloads with variable demand, development and test environments, SaaS applications, and organizations that do not have strict data residency requirements. The public cloud offers the lowest barrier to entry and eliminates capital expenditure on physical hardware.

Trade-offs: Multi-tenant architecture means the perimeter is managed by the provider, not the customer. Compliance requirements in highly regulated industries (healthcare, finance, defence) may restrict which workloads can run in a fully public environment.

Private Cloud

A private cloud is dedicated to a single organisation. Resources are not shared with other tenants, providing stronger isolation and more granular control over the environment. Private clouds can be hosted on-premises in the organisation’s own data centre, or they can be hosted by a managed service provider in a dedicated facility.

Best suited for: organisations with strict regulatory, data residency, or security requirements — for example, handling personally identifiable information (PII) under GDPR, or processing payment card data under PCI DSS.

Trade-offs: Higher cost and operational overhead. Maintaining a private cloud requires either skilled internal staff or a managed service provider relationship. Azure Stack Hub is Microsoft’s offering for running Azure services on-premises in a private cloud configuration.

Hybrid Cloud

A hybrid cloud architecture combines on-premises or private cloud infrastructure with public cloud services, connected through secure networking (typically VPN or Azure ExpressRoute). An organisation might keep sensitive databases on-premises while running customer-facing web applications in the public cloud, bursting capacity into Azure during peak demand.

Best suited for: organisations that cannot move all workloads to the public cloud due to compliance or latency requirements, but still want the elasticity and managed services that public cloud provides for appropriate workloads.

Trade-offs: Hybrid architectures introduce additional complexity in networking, identity federation, and operational tooling. Azure Arc extends Azure management and policy to on-premises and multi-cloud environments, reducing some of that operational friction.

Choosing the Right Model for Your Organization

The decision between public, private, and hybrid cloud should be driven by a structured assessment of the following factors:

1. Data classification: Identify which data is sensitive or regulated and where it must reside.
2. Compliance requirements: Map applicable regulations (HIPAA, PCI DSS, GDPR, SOC 2) to the deployment models they permit.
3. Availability and recovery objectives: Define your Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for each workload.
4. Internal IT capacity: A private cloud requires ongoing management expertise. If that capacity does not exist internally, a managed service provider or a managed Azure offering reduces the burden.
5. Total cost of ownership: Compare the full cost — including engineering time, licensing, and networking — not just the raw compute price.

For many SMBs, engaging a Microsoft-certified managed service provider (MSP) accelerates this assessment and reduces the risk of a poorly matched architecture. An MSP with Azure expertise brings experience across multiple client environments and can pattern-match your requirements against proven reference architectures.

Getting Started with Azure

Microsoft provides several resources for SMBs evaluating Azure:

• Azure free account: A limited free tier allows exploration of core services without immediate cost commitment.
• Microsoft for Startups (Founders Hub): Provides Azure credits and support for qualifying early-stage companies.
• Azure Pricing Calculator: Estimates monthly cost for a given architecture before committing resources.
• Microsoft Partner Network: The official directory for finding vetted Azure-certified managed service providers and consultants.

Cloud strategy is not a one-time decision. As your organisation grows, the workloads and compliance landscape evolve, and periodic architectural reviews ensure the cloud model continues to serve the business rather than constrain it.

Chef has revamped its channel approach, rolling out a new partner program that addresses inconsistencies in the company’s previous partnering efforts; more IT channel news.

Chef, a DevOps tool provider, has launched a new channel program that the company said provides a uniform structure for working with its nearly 500 Chef partners, which include systems integrators, managed service providers and resellers.

Chef, based in Seattle, offers four tools covering various facets of DevOps and DevSecOps. Chef Infra automates infrastructure configuration, Chef InSpec automates security and compliance, Chef Habitat automates application lifecycle management and Chef Automate provides a DevOps dashboard for operational visibility. Chef partners typically use the tools on digital transformation projects in which they help customers adopt modern software development practices.

Chef had been offering Chef Infra, InSpec and Habitat on an open source basis, but in 2019 extended open source licensing to Chef Automate, which originated as a propriety product. The previously mixed licensing model contributed to an uneven partnering approach, which Chef is looking to remedy with its revised program.

“We had no consistent way of interacting with these partners,” said Vikram Ghosh, vice president of business development at Chef.

The previous channel effort relied heavily on partner managers. But when a manager moved to a different job within Chef or left the company, the relationship with the partner would “go sideways,” Ghosh said.

The larger issue, however, was a conflict with service-oriented Chef partners who saw value in the vendor’s open source tools but were asked to sell the Chef Automate observational layer. The revised partner program, which builds upon the company’s 100% open source approach, aims to align Chef’s business model with partner needs, Ghosh said.

Components of the Chef Partner Program include a co-sell incentive model for partners who don’t wish to pursue product transactions as part of their service offerings. The program also includes support for the recurring revenue model and co-marketing opportunities as well as sales/technical enablement programs and tools.

Chef’s channel program offers three partner tiers: Principal, Senior and Junior. Top-level Principal partners are those that deliver “great customer outcomes” with Chef, differentiate themselves through integration with Chef’s technology partners and take advantage of Chef’s go-to-market programs, Ghosh said. Chef’s technology partners include Cloudbees, HashiCorp and Jenkins.

Channel partners play a number of roles in the Chef ecosystem. For one, they provide resources for delivering and supporting Chef technology. “From our standpoint, we are a relatively small company,” Ghosh said. “We need the scale that our partners provide.”

Systems integrator partners help customers integrate Chef’s offerings into the broader DevOps tool chain and CI/CD pipeline, he noted. MSPs, for their part, help customers manage the system an integrator sets up. “Customers don’t want to manage the underlying system that is delivering a business outcome,” Ghosh said.

The need for DevOps managed services has contributed to an SI-to-MSP shift, he added.

The Chef Partner Program in the coming months plans to highlight partner success stories through its marketing channels, including blog posts, events and webinars. Some of those stories, Ghosh said, will focus on SIs that found ways to provide ongoing services that drive recurring revenue.

Digital transformation projects, DR and marketing spell channel work
A channel partner to-do list might include restarting stalled digital transformation projects, boosting customer confidence in disaster recovery, and investing in sales and marketing — based on the results of industry surveys released this week.

Forty-two percent of the 293 U.S.-based IT decision-makers polled in a survey sponsored by Ahead, an enterprise cloud solutions provider based in Chicago, said they struggle to achieve success in digital transformation. The most-cited stumbling blocks are legacy systems and technical debt, according to the survey, which Hanover Research conducted on Ahead’s behalf. Overall, 67% of respondents identified infrastructure as a big part of their digital transformation strategies.

A US Signal survey, meanwhile, revealed three-quarters of the 110 U.S.-based IT decision makers it polled now use backup and disaster recovery from a third-party edge data center provider. That said, a significant portion of the respondents were not completely at ease with the business continuity offerings they’ve purchased. Fifty-four percent said they are somewhat or not very confident in their DR and backup solutions in the event of cyberattacks, outages or other incidents.

The survey from US Signal, a data center services provider, based in Grand Rapids, Mich., also noted 66% of respondents reported operating a hybrid IT infrastructure, while 20% said they were entirely in the cloud and 14% said they were entirely on-premises.

Beyond infrastructure issues, the MSP portion of the channel continues to grapple with sales and marketing. The North American MSPs surveyed in a SolarWinds report listed sales, lack of resources and marketing as their biggest growth obstacles. The results are consistent with other service provider surveys that have also cited sales and marketing as an MSP challenge.

The SolarWinds survey, conducted in conjunction with The 2112 Group, also pointed to patterns in MSP security. North American respondents said they were most comfortable offering and using antivirus, firewalls, data backup and recovery, and endpoint security. They were the least comfortable with biometrics, cloud access security brokers and digital rights management, according to the report.

Offshore players continue cloud consultancy purchases
Infosys, a $12 billion digital services and consulting firm based in Bengaluru, India, agreed to acquire Simplus, a Salesforce partner with headquarters in Salt Lake City.

The $250-million transaction is expected to close in the next 30 days, according to a Simplus spokesperson. Simplus offers cloud consulting, implementation, data integration, change management and training services for Salesforce CPQ and the Salesforce Billing add-on package. Simplus has offices in North America, Australia, the United Kingdom, and operates a delivery center in Manila.

The pending deal closely follows Atos’ acquisition of Maven Wave, a Google Cloud partner based in Chicago. Atos, a Paris-based IT services company, said the acquisition will bolster its cloud services footprint in North America. The Infosys-Simplus transaction is also reminiscent of Wipro Ltd.’s acquisition of Appirio, a Salesforce consulting firm, Appirio in 2016.

Other news
IBM Storage updated and consolidated its Storewize and FlashSystem products under the IBM FlashSystem brand, a move that was largely shaped by partner input, the vendor said. A company spokesperson said close to 150 partners and distributors globally gave feedback on the design and performance of the FlashSystem offering. In a blog post, Eric Herzog, IBM’s chief marketing officer and vice president of worldwide storage channels, noted the FlashSystem launch doesn’t affect IBM Storage’s go-to-market strategy. FlashSystem models 5000, 5100 and 7200 will continue to be offered exclusively through IBM business partners, he said.
Nerdio, a Microsoft Azure automation platform company that targets MSPs, closed $80 million in funding. The company said it would use the funding to drive product development and support for Microsoft Azure offerings, including Windows Virtual Desktop, as well as build out operations and resources for its channel partners. According to a Nerdio spokesperson, Nerdio expanded aggressively in the channel through 2019 by striking distributor agreements with Pax8 and Ingram Micro and pushing into international markets, such as Latin America, Belgium and the Netherlands.
TPx Communications, a Los Angeles-based MSP, has been acquired by affiliates of private equity firm Siris Capital Group. In conjunction with the acquisition, TPx said, its CEO, Richard A. Jalkut, will retire, and Siris executive partner Joseph A. Cozzolino will serve as executive chairman of the board and interim CEO.
US Signal tapped Infinidat, a data storage company based in Waltham, Mass., to provide storage arrays for a Detroit area data center scheduled to open in March 2020. US Signal already uses 12 Infinidat InfiniBox systems in seven data centers in the Midwest.
In the managed detection and response sector, eSentire Inc., based in Waterloo, Ont., launched esCLOUD, which extends its on-premises MDR offerings to cloud environments. In addition, Agio, a managed security services provider based in New York, unveiled a partnership with Respond Software. Agio is incorporating Respond Software’s technology into its MDR services.
Pax8, a cloud distribution company based in Denver, formed a partnership with Novacoast, an IT services and solutions provider. Under the arrangement, Pax8 will offer Novacoast’s novaSOC, a monitoring and alerting security service.
Atera, an IT automation platform based in New York, launched Atera Network Discovery, a tool the company said scans networks and extracts a list of business opportunities and tasks for MSPs.
Unified Office Inc., an MSP based in Nashua, N.H., developed an offering for the hospitality industry, based on its Total Connect Now business communication product. The hospitality offering will integrate with hotel management and messaging services such as Opera, Synergy and Kipsu, according to the company.
Atos is forming a systems integrator relationship with RingCentral. The companies plan to launch a co-branded unified communications as a service
Netsurion, a managed security service provider (MSSP), integrated its co-managed SIEM offering, EventTracker, with the Mitre ATT&CK cybersecurity framework. The ATTT&CK framework is a public knowledge base of threat tactics and techniques developed by Mitre Corp., a nonprofit research and development organization. Netsuiron said the integration will be available in the upcoming 9.3 release of EventTracker.
High Wire Networks, an MSSP, launched Overwatch 24/7, a new security platform for managed service providers. The platform integrates detection and response technology with High Wire Network’s security operations center as a service, the company said.
DLT Solutions, a technology aggregator and Tech Data subsidiary based in Herndon, Va., added offerings from Glasswall, Illumio, NetBrain, Parasoft, Perfect Sense, TYCHON and ZorroSign to its product roster.
Apps Associates, an MSP and Oracle cloud migration specialist, rolled out a diagnostic and management toolset, dubbed Apps Pack.
Extreme Networks signed a 10-year agreement with Gannon University to establish a regional networking training center for students and professionals. Additionally, Gannon and Extreme will integrate Extreme’s training curriculum and technical certification into the academic curriculum of Gannon’s undergraduate and graduate engineering and computing programs, the vendor said. An Extreme spokesperson noted that partners in the region will have access the facility, dubbed Extreme Academy, for on-site training. Under the partnership, Extreme will work alongside Networking Technologies, a value-added reseller (VAR) and integration, to outfit and upgrade equipment for the Extreme Academy and other Gannon academic buildings.
Axonius, a cybersecurity asset management platform vendor, appointed Mark Daggett as its vice president of channels and alliances. Dagget joins Axonius from Cylance, where he served as director of global distribution.
MSP360, a data backup and recovery solutions provider based in Lewes, Del., appointed Kate Knyazheva as head of inside sales. She joins the company from Veeam.
Matrix Integration, an IT solutions provider based in Jasper, Ind., appointed Rob Wildman as vice president of professional services.

Why Cloud Computing Matters for Business

The cloud enables small and mid-sized businesses to access enterprise-grade capabilities — including data analytics, artificial intelligence, and scalable compute resources — without the capital expenditure of building and maintaining on-premises hardware. As infrastructure demands grow and digital transformation accelerates across industries, cloud-based systems are increasingly positioned as the foundation of future IT strategy.

Major cloud hosting platforms such as Microsoft Azure and Amazon Web Services (AWS) provide a wide spectrum of services, but they are not the only options available. Choosing the right cloud solution requires understanding which service model aligns with your team’s skills, your application requirements, and your operational budget.

Cloud Service Models Explained

Cloud computing is typically delivered through four primary service models. Each model offers a different level of control, responsibility, and flexibility.

1. Web-Based Services

Web-based services allow businesses to adopt individual, discrete cloud functions rather than committing to a full application suite. These services rely on open standards and protocols — such as REST or SOAP — to integrate with existing systems and workflows. For example, a business might use a standalone web-based service for payroll processing, accounts receivable, or customer identity verification. Because these services are modular, organizations can mix and match providers to build a tailored technology stack.

2. SaaS — Software as a Service

Software as a Service (SaaS) is one of the most widely adopted cloud delivery models. In a SaaS arrangement, the provider hosts and manages the application, and users access it through a web browser or thin client. The end user does not manage the underlying infrastructure, operating system, or application runtime.

Microsoft 365 (formerly Office 365) is a well-known example of SaaS. Subscribers gain access to productivity applications without needing to install or maintain software locally. SaaS is particularly well-suited to daily business operations — email, collaboration, CRM, HR platforms, and accounting tools are all commonly delivered via this model. Because the IT services provider manages maintenance, patching, and availability, SaaS reduces operational overhead for in-house teams.

3. IaaS — Infrastructure as a Service

Infrastructure as a Service (IaaS) provides the fundamental building blocks of a cloud environment: virtual machines, networking, storage, and in some cases dedicated hardware. Rather than purchasing and maintaining physical servers, organizations rent infrastructure capacity from a provider on a pay-as-you-go basis.

Amazon Web Services is a leading IaaS provider, offering services such as virtual private networks, message queues, object storage, and non-relational databases. IaaS gives teams maximum control over their environment — including choice of operating system and software stack — while offloading the physical infrastructure burden to the provider. It serves as a foundation on which SaaS and PaaS solutions can also be built or deployed.

4. PaaS — Platform as a Service

Platform as a Service (PaaS) sits between IaaS and SaaS in the cloud stack. A PaaS provider supplies the operating system, runtime environment, middleware, and development tools, allowing developers to build, test, and deploy applications without managing the underlying infrastructure.

PaaS is especially valuable for development teams. Many PaaS offerings include software development kits (SDKs), managed databases, build pipelines, and deployment automation, which reduce the time and complexity involved in bringing applications to production. Organizations frequently use IaaS and PaaS together — IaaS for core infrastructure and PaaS for the application layer — to get the benefits of both control and developer productivity.

Cloud Deployment Models

Beyond the service model, businesses must also decide how they want their cloud environment deployed. There are three primary options:

• Public Cloud (Hosted): A third-party provider owns, manages, and maintains all infrastructure. The customer accesses services over the internet and shares underlying physical resources with other tenants. This model offers the lowest barrier to entry and the greatest scalability.
• Hybrid Cloud: A hybrid arrangement combines on-premises infrastructure (or a private cloud) with public cloud services. Data and workloads can move between environments depending on cost, performance, compliance, or security requirements. This model is common in regulated industries where certain data must remain on-premises.
• On-Premises / Private Cloud: Infrastructure is deployed within the organization’s own data center. While this is not typically considered “cloud” in the public sense, organizations can implement private cloud platforms to gain cloud-like flexibility while retaining full control over their environment. This approach carries the highest capital cost but offers the greatest control over security and compliance.

Choosing the Right Cloud Strategy

There is no single “right” approach to cloud adoption. The best strategy depends on your organization’s size, industry, regulatory environment, existing IT capabilities, and long-term goals. A small business with limited IT staff may find a pure SaaS approach the most practical starting point. A software company with a dedicated engineering team may prefer IaaS or PaaS for the control and customization they offer. Larger enterprises with complex compliance requirements often adopt a hybrid model.

Regardless of which path you choose, cloud computing provides access to resources and capabilities that would be prohibitively expensive to replicate through an on-premises IT department alone. When evaluated carefully against your operational needs, cloud solutions can deliver meaningful improvements in efficiency, resilience, and cost predictability.

Original source reference: azbigmedia.com (2019)

Mphasis Stelligent Earns AWS Security Competency Designation

Mphasis Stelligent, a technology services company specializing in DevOps automation on Amazon Web Services (AWS), announced in July 2019 that it had achieved AWS Security Competency status. The designation recognizes the company’s demonstrated technical proficiency and proven customer success in Security Operations and Automation—particularly in the area of DevSecOps.

The AWS Security Competency differentiates Mphasis Stelligent within the AWS Partner Network (APN) as a consulting partner capable of helping enterprises adopt, develop, and deploy complex security projects on AWS. To receive the designation, APN Partners must demonstrate deep AWS expertise and the ability to deliver solutions seamlessly on the platform.

Security as a Foundation for DevOps Automation

Paul Duvall, founder and CTO of Mphasis Stelligent, emphasized the company’s philosophy on security in DevOps engagements:

“A strong security posture is absolutely essential to effective DevOps automation. With our exclusive focus on Amazon Web Services, we’re able to put security at the foundation of our AWS customer solutions. Our team takes an ‘automate everything’ approach to each engagement by automating security controls and governance through the Continuous Delivery (CD) pipeline. This allows customers to develop on AWS with more speed, consistency, visibility, and confidence, knowing security is built-in.”

— Paul Duvall, Founder and CTO, Mphasis Stelligent

Four-Phase Approach to AWS Security Automation

Mphasis Stelligent uses a structured, four-phase methodology to help enterprises automate security on AWS:

1. Assessment – Profile the existing environment and identify areas for improvement in security posture and compliance gaps.
2. Foundations – Determine the security strategy and lay the architectural groundwork for security and compliance controls on AWS.
3. Extended Controls – Implement additional controls designed to mitigate and reduce business risk across cloud workloads.
4. DevSecOps – Automate security testing and infrastructure security inspections directly within the Continuous Delivery pipeline, embedding security as a first-class concern rather than an afterthought.

Notable Customers

At the time of the announcement, Mphasis Stelligent was working with a range of enterprise customers—including 3M Health Information Systems, Verizon, and The Washington Post—to strengthen their cloud security posture while streamlining development workflows on AWS.

About the AWS Competency Program

The AWS Competency Program was established by Amazon Web Services to help customers identify APN Consulting and Technology Partners with validated experience and expertise in specific domains—including security, machine learning, migration, and more. Achieving a competency designation requires partners to pass a technical validation review and demonstrate proven customer success.

About Mphasis Stelligent

Stelligent is part of Mphasis, a global IT solutions provider specializing in cloud and cognitive services. Operating within the Mphasis Digital Business Unit, Mphasis Stelligent delivers DevOps automation professional services exclusively on AWS. The company focuses on building fundamentally secure infrastructure-as-code, deployment pipelines, and feedback mechanisms that enable engineering teams to ship software faster and more consistently—without sacrificing security or compliance.

DevOps Is Not One-Size-Fits-All — Even Inside Government

Federal agencies face a unique challenge when adopting DevOps: they must balance speed of delivery with rigorous security, oversight requirements, and mission-critical reliability. Panelists at a June 2017 FCW DevOps workshop made clear that the most productive path forward is a deliberate, case-by-case approach — applying DevOps practices where they deliver measurable value rather than mandating a wholesale transformation overnight.

SEC: Relationships Before Process

At the Securities and Exchange Commission, one of the most effective early DevOps enablers was surprisingly simple: a weekly cross-functional meeting. SEC Branch Chief Michael Fairless described a cloud implementation team that brings together staff from security, applications, and network teams to surface and prioritize pressing issues.

“We are thinking in an agile way, but not necessarily working from an agile process. It is building relationships that pay off down the road.”

— Michael Fairless, SEC Branch Chief, FCW DevOps Workshop, June 21, 2017

The practical payoff from those meetings is faster problem resolution. When a security issue surfaces, Fairless noted, team members can immediately turn to a colleague they have been collaborating with for weeks rather than escalating through formal channels. That accumulated trust compresses response time significantly.

Fairless was also candid about the SEC’s constraints. The agency cannot operate on the near-continuous deployment cadence of consumer software products. Instead, the realistic DevOps win is compressing the time required to identify bad actors in financial markets — from the traditional three-to-five-year cycle down to six-to-twelve months.

DTRA and JIDO: Be Selective About What You Automate

Leonel Garciga, J6 Chief and CTO at the Joint Improvised Threat Defeat Organization (JIDO) within the Defense Threat Reduction Agency (DTRA), echoed the need for speed — particularly in getting new tools to warfighters faster. But he was equally clear that automation is not universally appropriate.

“My honest answer is that we need to look at the capabilities that we are deploying and make a conscious decision about what we are doing today. Three to five years from now it could look very different… but we need to be really smart on the software that we are pushing to DevOps.”

— Leonel Garciga, J6 Chief and CTO, JIDO/DTRA

For systems that require mandatory human review — particularly those with direct operational or safety implications — fully automated pipelines may introduce unacceptable risk. Garciga’s advice: audit your portfolio, identify which systems genuinely benefit from automation, and prioritize those first.

He also offered a practical delivery heuristic: release the first 20 percent of an IT solution to users as soon as it is ready, rather than waiting for a complete feature set. Pushing partial but functional capabilities out earlier validates assumptions and builds momentum.

DHS: From 2.5 Months to 2.5 Minutes

Department of Homeland Security Deputy CTO Rob Palmer framed DevOps automation around one concrete metric: deployment time. The goal, Palmer said, is compressing deployment windows from roughly 2.5 months to 2.5 minutes through automation.

“We are midway through building a foundation. We started with a particular cloud vendor to prove out the use case, and we are actively working through the process with our stakeholders.”

— Rob Palmer, Deputy CTO, Department of Homeland Security

Palmer’s approach reflects a proven strategy for large organizations: start with a single cloud vendor and a well-scoped pilot to validate the model before scaling. This reduces early risk and generates concrete evidence to support broader adoption with stakeholders.

USCIS: Government Oversight Structures Work Against Small Batches

Citizenship and Immigration Services CIO Mark Schwartz identified a structural tension that affects virtually every federal DevOps initiative: government program oversight is designed around large, multi-year projects — the opposite of the small, frequent delivery cycles that DevOps requires.

“There is a strong imperative to get the cycle time down in general, which requires working with smaller pieces. However, government’s oversight and program structure is completely built around bigness, which is the important conflict that stops us from getting the value out of DevOps.”

— Mark Schwartz, CIO, U.S. Citizenship and Immigration Services

Schwartz’s observation is a well-recognized challenge in public-sector DevOps adoption. Budget cycles, acquisition frameworks, and reporting requirements tend to favor large, monolithic contracts — making it structurally difficult to fund and govern a stream of small, iterative deployments. Addressing this conflict often requires changes at the policy and procurement level, not just the engineering level.

Engaging Vendors at a Technical Level: The Containers Example

Garciga highlighted another practical lever for accelerating DevOps in defense environments: direct technical engagement with commercial vendors. He described productive conversations with Docker around container technology, noting that vendors who deeply understand DoD’s operational constraints can build supporting capabilities directly into their core products.

“We need to be more aggressive on the government side to really engage these companies on a technical level and have mature discussions. They understand our constraints and what it means to be an insider at DOD, so they can start working on their products and adding new capabilities to support DOD into their core capabilities.”

— Leonel Garciga, J6 Chief and CTO, JIDO/DTRA

This shifts the relationship from passive procurement — where government agencies simply buy commercial products — to active co-development, where vendor roadmaps incorporate government requirements from the start.

Key Takeaways for DevOps in Regulated and Mission-Critical Environments

• Build relationships first. Cross-functional trust, established through regular collaboration, reduces the coordination friction that slows incident response and deployment approvals.
• Audit before automating. Not every system is a good DevOps candidate. Human review requirements, safety implications, and operational criticality should all factor into the decision.
• Start small and prove the model. Pilot with a single cloud vendor or a single system before attempting agency-wide adoption. Evidence from a working pilot is the most effective tool for winning stakeholder support.
• Ship the first 20 percent early. Partial capabilities delivered quickly generate real feedback and build momentum, rather than waiting years for a complete solution.
• Address structural barriers explicitly. If program oversight, budgeting, or acquisition rules are incompatible with iterative delivery, those systemic issues need to be part of the DevOps conversation — not treated as fixed constraints.
• Engage vendors technically, not just commercially. Deep technical dialogue with software vendors can result in government-specific capabilities being built into commercial products, reducing the need for costly custom development.

Original reporting by gcn.com. Quotes sourced from the FCW DevOps Workshop, June 21, 2017.