Tag: IT services

DevOps: Disruptive and Changing the Purchase of IT Services | Sherpas in Blue Shirts

Businesses now demand that IT departments dramatically change the velocity of the cycle time it takes to take ideas from concept to production – often from as long as 12-18 months to only four to six weeks. Organizations can’t achieve a change of this magnitude with just a change in methodology. To do this, they must move to DevOps – a disruptive phenomenon with immense implications for the enterprise IT ecosystem and the service providers that support it.

Put another way, many IT firms batch or create software releases once or twice a year in which they bring out updates to their enterprise platforms. Businesses now demand a cycle time of one to two times a month for updates. What they want and need is a continuous-release construct.

Methodology alone cannot create the conditions in which organizations can form ideas, build requirements, develop code, change a system and do integration testing in the new timeframes. Hence the DevOps revolution.

DevOps is the completion of the Agile methodology. It builds the enabling development tools, integrates test conditions, and integrates the IT stack so that when developers make code changes, they also configure the hardware environment and network environment at the same time.

To do this, an organization must have software-defined data centers and software-defined networks, and all of this must be available to be tested with automated test capabilities. By defining coding changes with network and system changes all at the same time and then testing them in one integrated environment, organizations can understand the implications and allocate work as desired. The net result is the ability to make the kind of cycle time shifts that businesses now demand.

DevOps implications

DevOps enables IT departments to meet the cycle time requirements. But the implications for how organizations buy services and how providers sell services are profound. Basically the old ways don’t work as well because of the new mandate for velocity and time. This causes organizations to rethink the technology, test beds, and service providers; and then manage the environment on a more vertical basis that cuts across development, maintenance, and testing, and allows the full benefit of a software-defined environment.

Let’s examine pricing, for example. Historically, coding and testing are provided on a time-and-materials basis. The productivity unleashed in a DevOps environment enables achieving approximately a 50 percent improvement in efficiency or productivity. Therefore, it is as cannibalistic or as disruptive to the development and maintenance space as cloud is to the infrastructure environment.

Furthermore, organizations can only operate a DevOps environment if they have a software-defined hardware environment – aka a private or cloud environment. This forces production into ensuring they perform all future development in elastic cloud frames.

Enterprises today are reevaluating where they locate their talent. Having technical talent in a remote location with difficult time zone challenges complicates and slows down the process, working against the need for speed.

So DevOps is a truly disruptive phenomenon that will disrupt both the existing vendor ecosystem and also the software coding and tool frames. Testing, for example, has been a growth area for the services industry, but DevOps environment largely automate testing services.

Another disruption is that DevOps takes a vertical view of the IT life cycle. It starts to integrate the different functional layers, creating further disruption in how organizations purchase IT services.

DevOps offerings are a new development among service providers, but the services industry to date has been slow to adopt the movement. DevOps is an internal threat to their existing business and requires providers to rethink how they go to market.

Demand Management Is Made Possible through as-a-Service Model | Sherpas in Blue Shirts

Demand management has been the unicorn of enterprise IT – something frequently talked about but rarely seen and never captured. Every centralized IT organization would love the ability to accurately manage user demand. It would provide tremendous return if it were possible; but to date it has been largely or completely thwarted in large enterprise IT organizations. But there’s good news, thanks to the as-a-service model.

The reason demand management has been thwarted is that IT is organized on a functional basis; the data center, servers, network, purchasing, and security app development and maintenance are all defined functionally. IT leaders are held responsible for driving out cost and building capability that is shared by multiple departments. The problem is there is no relationship between demand and supply capability because business users don’t understand how to measure their usage/demand.

When IT asks business users how many servers they you use, their response is often “How many did we use last time?” Or when IT asks how many programmers will you use and why, business user typically respond with “We need 10 percent more than we had last time.” There is no relationship between actual demand and the actual demand drivers and the estimates they must provide to IT. This is a hopeless and fruitless exercise. It’s like a broken clock that is right only twice a day. This demand estimate is doomed to be wrong every day.

So what’s the answer? We need a service construct where IT is organized into service models. This construct gives business users a way to understand their usage or demand. For example, a healthcare payer understands how many people it expects to enroll. This is a metric the business can use to predict usage and the time frame in which they will need the service. IT can then manage the demand for the service it provides to the payer based on the number of enrollments.

When companies organize IT along service lines, they can translate business activities into technical consumption. The as-a-service construct attempts to make as much of its service chain or supply chain as elastic as possible. It adjusts each part of the supply chain to the usage demand. So unlike the traditional functional IT structure, business users only pay for what they use.

There are three mechanisms to make a technology or service elastic:

  • Share it (such as AWS); when you’re not using it, someone else is
  • Automate it; spin it up, do the work, and shut it down
  • Buy it on a consumption basis

Typically, as-a-service providers use all three of these techniques to allow them to use their full service stack with the business metrics that the technique serves.

The as-a-service model achieves one of the Holy Grails of centralized IT – it provides a realistic demand management vehicle where the business can make accurate estimates. It also provides paying for the services only when they are used; this is the consumption-based model that the services industry is moving to.

Demand management to date has been completely illusive to centralized IT because of the take-or-pay nature of IT. This method for building capability – and business users sharing the cost to be able to use it – has no connection to business metrics that the business can control and understand how to estimate their technology capacity/demand. But the good news is the as-a-service model puts a rope around the unicorn. It creates the ultimate answer to demand management.

In SaaS We Trust (or May be Not) | Sherpas in Blue Shirts

Although Software as a Service (SaaS) has become widely adopted, some organizations’ application management practices have not changed to reflect this.

All too often enterprise SaaS upgrades are handled in the same way as on-site software. Risk averse enterprises tend to rely on their IT service providers and their methodologies to support a mix of on-site and SaaS applications. The methodology is often the same for both types of software: The ITS provider lines up staff, according to its traditional application management strategies; one to oversee the upgrade, another to do impact assessments, another to fix issues on the day and so on. Before you know it, you have a team of half a dozen people lined up to help with the SaaS upgrade. In the meantime, the upgrade gets done remotely overnight by the SaaS software provider who has automated a large part of the process. It is not unusual for the on-site ITS team members to sit there looking embarrassed while twiddling their thumbs.

This is not to say that SaaS clients should throw caution to the wind and rely 100% on the SaaS providers’ best efforts. Instead they need to revisit best practices and follow upgrade strategies that fit the SaaS model. This should result in a reduction in the effort to oversee an enterprise SaaS upgrade by more than 50%.

Cloud and SaaS have had a huge impact on the ITS market already. This is evident by the reducing size of contracts. With increasing automation in the cloud, this trend is set to continue. The more adaptive of organizations will be reaping cost reduction benefits well ahead of those who stick to older approaches for managing their applications. The question to ask yourself: Is your organization stuck in tradition or adapting for its benefit?

Technology Specialists – The New Dinosaur in Making | Sherpas in Blue Shirts

Are you a brilliant Java coder? An expert in the R programming language? A phenomenal database administrator? A brilliant software seller? Sorry to say it, but you’re likely to soon be a member of the “extinct club.”

In corroboration of Scottish economist Adam Smith’s concept of the division of labor, organizations have historically preferred and hired specialists to develop their technologies, and other specialists to sell them. These masters of their craft had acclaimed expertise in their specific areas. And despite the evolution from mainframes to microcomputers to PCs to client server to ERP to the web, it was relatively easy for them to upskill or move to an adjacent skill, as the technologies adopted by companies rarely changed in their fundamental structure.

This gave rise to an “I am a developer, let me develop, I am in sales, let me sell” model within technology companies. It worked well, as enterprises persisted with outdated technologies they had intertwined their business models, and the cost of replacement was prohibitively high. This persistence created the specialists, who were assured of their place in the high echelons of technology as the landscape was not changing fast enough. This also gave rise to the outsourcing industry, which was leveraged to support these outdated systems and reduce the cost of management.

However, those times are gone. Due to digital transformation, organizations expect their professionals to understand not only the technology, but also business users’ perspectives, technology ease of use, consumption flexibility, and creation of top line impact. Development or sales specialists lacking a comprehensive business view are quickly losing their relevance and competitive edge.

Lack of relevance and competitive edge can, and will, also effect many technology providers. This is due, in large part, to the fact that as the cost of consumption of hardware and software decreases, organizations are increasingly willing to dismantle their existing systems and embrace newer models, e.g., migrating from one SaaS CRM to another. The idea of “fail fast, fail better” is gaining traction within enterprises, and technology companies need to align their business models accordingly to serve them.

The reality is that this sea change requires full-scale overhaul of technology providers’ entire business model – including their investment strategy, product roadmap, partnership ecosystem, and go-to-market approach. Yet executives in these businesses have made their careers and big money by developing and selling technology in a certain manner that promotes status quo. Think about a large software vendor and its partners who earn millions of dollars by just providing “certificate training” for their technologies. If the technologies become redundant, their bottom line will be severely impacted. Therefore, they will invest all their efforts in ensuring their clients stick to their technology platforms, irrespective of whether they are outdated and unable to cater to the business. Of course, there are buyers that do not want to rock the boat by changing something until it is really broken. This comfortable nexus has been going on for ages.

But the times are changing very fast. Technology providers that view their buyers as “cash cows,” rather than valuable partners to be helped to achieve business objectives, will fast lose relevance. The providers that succeed will: 1) embrace this new world of disruption, and create meaningful solutions that are more than beautified version of their outdated platforms wrapped in a pretense of user friendliness; and 2) make their prized specialists realize the new norm of the business wherein they need to at least understand, if not master, the art of viewing the world from a business and end-user perspective that incorporates a holistic paradigm beyond their usual tunnel vision.

If he were alive today, Adam Smith might well have changed his tune, instead suggesting malleable skills to enable technology companies’ success in these uncertain times of technology.


Photo credit: Flickr

Why Is HP Breaking Up? | Sherpas in Blue Shirts

I’ve been blogging about why certain companies such as Accenture, ADP, and TCS are such successful service providers. In contrast, let’s look at HP and examine why it’s breaking up.

I’ve explained in prior blogs that the most successful companies have six operational elements aligned, as shown in the Everest Group assessment framework below.

Assessment framework technology service companies

In successful companies, their promise is consistent with their business model, their talent model is consistent with their promise and model. Their investments align with the talent and business models, and the portfolio they end up with aligns with the other components. In addition, they tune their go-to-market approach to maximize their advantages in these components.

HP, as much talked about, is breaking up, separating its printers and PCs division from software and services. Printers and PCs are late-stage, mature devices and represent a market that is commoditized, mature, and saddled with slow growth. Software and services give the promise of growth.

HP is taking the first steps to create better alignment in both their businesses between the functions of brand, go-to-market, investments, and the other components of the framework illustrated above.

HP’s printers and PCs business is well aligned in terms of its brand promise of high-quality, cost-effective end-user devices. Its go-to-market approach is consistent for both printers and PCs, and the portfolio is rationalized around those devices and the warranty services that support them. Its investments can focus on maintaining market share. The firm can harmonize talent to ensure it’s appropriate for a mature business. And its business model and supply chain are consistent across their offers and can be further refined and focused. So I see the break-away from software and services as a no-brainer.

HP’s software and services area is a more complicated story; here, I think they have further to go. A smaller, more focused organization will allow HP over time to refine its brand to focus on large enterprises. Its go-to-market approach can be more easily integrated. Its portfolio, which is still very diverse, will probably need further refinement over time.

Although they clearly don’t have all six components harmonized for the software and services business, the break-up gives HP a much better fighting chance to work through that. They have further work to do across all these areas – particularly in brand and portfolio. As they get a crisper brand promise into the market and a portfolio aligned with that brand, the firm’s business model, go-to-market approach, and investment choices will become clearer.

HP is still early in this reformatting of the company. But history tells us that, as they succeed in getting these aspects clarified and aligned, the firm’s performance will improve.


Photo credit: Flickr

Three Ways Services Customers Can Switch to as-a-Service Model | Sherpas in Blue Shirts

As the services industry begins moving into the as-a-service era customers look for providers that change their traditional services to make them elastic or consumption based. We at Everest Group have spent some time studying this, and we believe there are three key ways to change take-or-pay (fixed costs oriented) services and make them elastic (pay as used). One or even a combination of all three ways are present in the services model that customers now demand.

1. Multitenant sharing

Customers benefit from a provider sharing its capacity among multiple clients. AWS and Salesforce are classic examples of this elastic type of service. They redeploy servers or capacity when not in use to other customers and therefore achieve an extremely high utilization rate. In fact, arguably, AWS has over 100 percent utilization rate because it can charge customers for capacity when they’re not using it, yet can use that capacity for other clients. The model is much like an airline selling more seats than its actual capacity.

2. Automation

Repeatable process automation (RPA) or robotics spins up a virtual robot to do the work and then shut it down again. This fundamentally aligns a customer’s costs with usage and thus makes the service elastic.

3. Change purchasing method

The third way customers can have elastic services is to change their purchasing so that they only buy services as they use them. An example of this would be changing the way a customer acquires software, switching from enterprise licenses to consumption-based licenses where the customer pays for the software only as they use it. A note of caution here for customers: Although this makes the service elastic to you, there may be a stranded cost to your provider, and that cost may be embedded at a higher cost to you in your cost structure. So be careful about overly using the purchasing mechanism to make a component of your IT service stack be elastic.

Although customers can use these three methods separately, it is also beneficial to look for service providers that use a combination of all three methods to make a material difference to an entire service line to make the service far more flexible and consumption based to meet your needs.

We have not uncovered other mechanisms to make a provider’s service line elastic, but we are very interested to know if you have discovered another way to achieve elastic services. Please post your comment and share your experience.


Photo credit: Flickr

When It Comes to IT-BPS, the Philippines Knows Its Strengths | Sherpas in Blue Shirts

I was introduced to the Philippines about two years back when I started working in the global services sector. And frankly, I was a bit startled by how little I knew about this giant of the contact center services market – I always thought India was the world’s largest contact center market. But its colonial heritage, accent neutrality, cultural affinity with the west, and BPS-conducive environment puts the Philippines at an altogether different level.

I began following the Philippines IT-BPS markets more regularly as I worked on this location for several client engagements. I observed how this country is a perfect example of the “playing on your strengths” approach. It is incredible how the government, iBPAP, and other partner associations have worked together to achieve the growth potential we highlighted in the Roadmap we developed in association with then BPAP and Outsource2Philippines back in 2009. Indeed, the market has doubled in size in less than six years. Today, the Philippines employs over a million FTEs, and is the second largest offshore services delivery location, next only to India.

While voice-based services have always been Philippines’ strength, it has experienced remarkable success in other areas, such as IT services, which grew at ~25 percent CAGR since 2010, and now accounts for ~10 percent share of country’s entire offshore market. While service providers have been key drivers of the growth in IT, Global In-house Centers (GICs) have pushed for growth in FAO and banking services. Several global banking companies, such as American Express, ANZ, Citibank, Deutsche Bank, HSBC, ING Group, JP Morgan Chase, and Wells Fargo, have established sizable centers in the country. Even though Bank of America has exited the country (it shut down its shop in 2014 as part of a global GIC restructuring), and JP Morgan Chase is scaling down owing to global cost cutting, overall outlook remains positive. The country has also made good use of its strong nursing talent—the largest pool of U.S.-licensed nurses outside of the U.S.—and is now the largest healthcare services provider to the U.S. The healthcare BPS sector has grown at over 40 percent YoY since 2012.

Another success area for the Philippines has been its ability to attract global companies. Over 100 have set up their GICs in the country, and close to one-fourth of them are on the Fortune 500. These GICs are expanding their Philippines strategy beyond cost arbitrage, and establishing regional hubs/HQs/CoEs. The U.S. remains the leading buyer market, with ~70 percent total demand. However, demand from Asian markets has been increasing steadily, with several Japanese and Australian companies establishing their captive centers in the metro Manila region.

With increasing emphasis on adoption of digital globally, government agencies (such as iBPAP and PSIA) are making proactive efforts to ensure that the Philippines stays ahead of the curve. It is already investing in building capabilities – from teaching the right curriculum at the universities to supporting companies’ development of required infrastructure to setting up training labs at colleges and universities –  to deliver mobility, analytics and cloud-based services. We have seen some evidence of companies already delivering mobility (focused application development services for mobile) from the Philippines in the last year or so. Digital has been the buzzword in the majority of our interactions with our clients looking into the Philippines lately.

Having done well so far, I am intrigued to see how the Philippines will sustain its growth in the evolving IT-BPS ecosystem. It needs to adapt to rapidly changing consumer needs, e.g., the adoption of digital, development of multi-channel delivery systems, and a multi-skilled labor force. It also needs to ensure continuous growth in other service lines, such as banking BPS, FAO, HRO services, animation and gaming, and creative services, by leveraging its interpersonal, voice-based, and strong domain-specific skills to build scale.

It will be interesting to watch what lies ahead in the years to come. Can the Philippines continue shaping its own destiny in the global services market?

SaaS versus Enterprise IT as-a-Service | Sherpas in Blue Shirts

New business models are capturing growth and stand to reshape the services industry. Two of the most promising of these are SaaS and “Enterprise IT as-a-Service.” Buyers need to understand that each model takes a different approach to delivering services; their risks also are not the same, and each approach has different consequences.

They are the same in one aspect: both models attempt to change the relationship of IT to the business by better aligning the IT environment to the customer or business needs and making the IT infrastructure more agile and responsive to changes in the business environment. So the prize is better alignment to business value, more responsiveness, shorter time to get new functionality, and more efficient use of IT dollars.

But how they deliver that prize is very different.

SaaS approach

The SaaS promise is strong on efficiency gains. SaaS is inherently a multitenant-leveraged approach in which common platforms are built, standard functionality is developed and is allowed to be configured to a customer’s needs. The platforms come with flexible, powerful APIs that allow the SaaS offerings to be integrated into enterprise systems. But at its heart, SaaS is a one-size-fits-all, unyielding standard. Efficiency gains in a SaaS approach come from having many customers use the same software and hardware, limiting customization through configuration and APIs.

SaaS apps are typically function-based, so they evolve quickly. When the SaaS owner brings innovations, it does so in one stable environment, not having to update or take into account very diverse environments that traditional software packages must accommodate. Therefore, SaaS delivers rapid changes in functionality that benefit the entire ecosystem. In contrast, the traditional software model evolves much more slowly and imposes constant requirements for upgrades that are both expensive and have knock-on consequences for the systems that integrate with them.

Enterprise IT as-a-Service approach

The Enterprise IT as-a-Service model takes a supply-chain approach, moving each component of the supply chain into an as-a-service model. This allows the whole supply chain to be better aligned. It loosely couples each part of the supply chain, allowing each component to evolve and allowing the supply chain to capture the benefits as each component evolves at its own pace.

Similarity in benefits

Both models deliver similar flexibility and agility benefits, but they achieve them in different ways. The Enterprise IT as-a-Service model allows far more customization than the SaaS model. It assembles components into a customized end-to-end offering, whereas a SaaS vehicle achieves those aims through API configuration.

Both models also achieve similar benefits in cost savings. Both approaches can achieve significant efficiencies. SaaS achieves this through high leverage over an unyielding standard. The Enterprise IT as-a-service approach achieves efficiencies partly through reducing the over-capacity that all functional-driven IT departments maintain inside their ecosystem.

Substantial differences in cost, risk, and technical requirements

The two models differ substantially in cost, risk, and technical depth. The risk and technical depth to adopt a SaaS vehicle can be very substantial, particularly if it’s a system of records. Existing systems of records come with substantial technical depth in terms of the integration of the system, unamortized assets and also ongoing software licenses. In moving from that environment over to SaaS, organizations often face substantial write-downs and a risky implementation.

The risk is different in the Enterprise IT as-a-service model in that it can be managed component by component. Organizations can achieve substantial flexibility by not having to move off existing systems of records or existing software. Those platforms can be migrated down this path, therefore lessening the technical debt and presenting a different risk profile.

Which approach is better?

I believe that both approaches are important to the future of IT. At the moment, large enterprises adopt SaaS mostly as point solutions. Enterprise IT as-a-service poses the opportunity to operate at the enterprise level, not at a point-solution level.

I don’t believe the two approaches are mutually exclusive and expect that organizations will embrace both capabilities over time.

How can we engage?

Please let us know how we can help you on your journey.

Contact Us

"*" indicates required fields

Please review our Privacy Notice and check the box below to consent to the use of Personal Data that you provide.