Tag: application development

Application Outsourcing: Declining Productivity, Rising Anti-Incumbency | Sherpas in Blue Shirts

Enterprise buyers are increasingly realizing the need to improve their application outsourcing (AO) productivity levels in order to curb the spiraling costs of their application functions, whether they are delivered by the internal IT organization, global in-house centers, or a service provider. Many buyers are also decreasing the volume of work that they outsource, due to their increasing frustration with their external service providers’ lack of ability to deliver greater productivity.

Some of the traditional measures buyers have adopted to mitigate these issues include automation of ADM processes, service provider consolidation, sourcing mix optimization, and application rationalization. However, they are not entirely satisfied with the outcome of these initiatives, and believe they can further improve. Everest Group believes they must not only augment these initiatives, but also start an organization-wide reform of application service delivery processes that includes development models, enterprise architecture, sourcing strategy, best practices, etc.

AO productivity

In order to derive meaningful impact and achieve sustained AO productivity improvement, buyers must:

  • adopt arduous measures such as increased centralization of the sourcing function;
  • implement organization-wide strategies (e.g., Six Sigma and lean operations);
  • even completely revamp their application service-related processes, if need be.

Such measures could be initially painstaking and effort-intensive, but are bound to provide sustainable benefits in the long run.

Moreover, buyers need to hold their service providers accountable for productivity enhancement. Most buyers believe that their service providers lack the capability to provide further cost and productivity improvements. Therefore, as noted above, a significant number of buyers are bringing select pieces of work back in-house to gain better control of their processes.

Everest Group believes that if service providers are unable to match buyer’s expectations around productivity improvement, they will witness a significant churn in their client portfolio. Service providers need to first deploy the tried and tested methods of improving productivity (e.g., automation, delivery mix, etc.). However, they need to adopt additional measures, as outlined above, in order to bring about sustained productivity improvement.

For further insights, please read Everest Group’s, “Application Outsourcing (AO) – Annual Report 2013: Declining Productivity Rising Anti-incumbency.” The report discusses the limitations of conventional strategies being adopted by buyers to improve the productivity of their AO functions, and the need for enterprises to evaluate broader organization-wide strategies in order to boost AO productivity.

The report also highlights other interesting trends including a rebound in the European market and the increasing impact of mobility and analytics on application services.

Why the Traditional Infrastructure Outsourcing Market Is about to Shrink Dramatically | Gaining Altitude in the Cloud

For those of us who are industry observers, it is not a secret that the traditional Infrastructure Outsourcing (IO) market has stopped growing and is currently contracting at a rate of 2 percent a year.

Market Size for Traditional Infrastructure Outsourcing Players

The secular trends driving this contraction are numerous and include client frustration with the contracting model, lack of flexibility, poor customer/provider alignment, and alternative sourcing options such as in-house, co-location and remote infrastructure management outsourcing (RIMO).  All of these alternative options present increased flexibility and often more attractive economics.

However, the reason that this market deceleration and consequent contraction has been so slow is that once a client has entered into a significant IO contract it is very hard to move away from the model. It is possible to switch service providers but very difficult to rebuild in-house managed capacity.  As a result, we note that the traditional IO market place is dominated by re-competes with few new logos entering the market.

Nevertheless, this stable market may be about to change in a big way. To understand why, we only need to look at the nature of the workloads that are running in these IO environments. Over the course of the last year, we have taken a close look at these workloads and have determined that between 40-50 percent of the workloads currently hosted via these contracts do not have the security requirements or the mission criticality that prevents them from being migrated to less expensive cloud environments. We estimate that savings can approach 20-40 percent, depending on the workload distribution and the volumes involved, particularly when these workloads are migrated to a pay-as-you-go environment such as those available from public cloud platforms such as Amazon or Rackspace.

To better understand the viability of this happening, let’s look at the use case of Application Test and Development.  Test and Development environments are not subject to the same performance, security or compliance requirements of production workloads. They are, in fact, excellent candidates to be operated in less expensive but more flexible environments. There is little reason for customers to look at these workloads in the same light as production workloads or for the same cost and delivery constructs to be applied.

When you dig further into existing IO contracts you find that many of these customers are operating well above their contracted minimum volumes thus allowing them to shift these workloads without fear of having to renegotiate contracts or pay early termination fees. When you consider that test and development alone often take up 25-35 percent of the capacity in the traditional IO environment it becomes clear that it is only a matter of time before customers move to shift these workloads and move from these low-hanging fruit to other workloads that exhibit similar favorable characteristics.

We have researched what conditions are necessary to allow a traditional IO client to move down this path. It appears that three key conditions need to be met.

  1. A vision or understanding by the customer that savings are possible, large and attainable.
  2. Orchestration tools that allow the client to organize, manage and coordinate. These tools have recently come on the market with several strong case studies to demonstrate their success.  What makes the business case compelling is that it is entirely possible for customers to “test” the cloud model by moving incremental workloads without investing in such tools though a larger scale of transformation would require such investments.
  3.  The willingness to invest the time and money to implement the program.

Given the strong ROI resulting from these initiatives it is likely that many if not all ITO customers will explore this option.  Already, more than half of enterprise customers are actively migrating or considering migration of development and testing environments to the cloud, next only to email/collaboration and disaster recovery/archiving.

Cloud Adoption for Application Dev Test Environments

With significant portions of IO workloads vulnerable to this emerging threat it’s only logical to conclude that we will see this market contract sharply in the next few years.

Application Development Productivity – You’ve Got to Be on the Indifference Curve! | Sherpas in Blue Shirts

The main indicator of productivity in application development (AD) – periodic reduction in the number of application defects per 1000 lines of code written in X man hours – has stood the test of time at a modular level, as have CMMI standard metrics against which any calculation of productivity can be benchmarked.

However, in the midst of mounting pressure to optimize discretionary IT spend, buyers have no option but to justify their spending via data that evaluates productivity at the enterprise level. CIOs must meet this requirement, while also facing the following two challenges:

  • First, they must simultaneously deliver increasing value and achieve year-on-year annual reduction in costs
  • Second, they have to contend with educated business users who may not have the patience to deal with a behemoth enterprise IT organization to get their functional needs fulfilled. Indeed, with the advent of market forces such as social media, mobility, analytics, and cloud (SMAC), business users today understand more about applications and technology than they ever did in the past

As a result, IT buyers must ignore all the ambient noise created by multiple metrics and focus only on the following two factors:

  • Business functions: The functionality that the business users are demanding, complete with SLAs
  • Application cost: The cost to acquire the applications that provide the required functions.

Fortunately for them, data indicates that “business functions versus cost” can be useful in benchmarking the productivity of any application development project.  As the following image illustrates, for AD projects of specified complexity and type, a combination of the number of functions (F) in an application and the cost (C) to acquire that application can be plotted into an “indifference curve.” An indifference curve is a graph showing different bundles of two variables between which a consumer is indifferent. Basically, all points on the curve deliver the same level of utility (satisfaction) to the consumer.

Application Develop Productivity

Based on benchmarking data over many years, all points that form these indifference curves deliver an optimal level of productivity for the complexity specified.

This productivity benchmarking can be used to assess and optimize the productivity of AD projects. For instance, if a particular AD project, for example application 3 in the above image, falls below its indifference curve, it is delivering sub-optimal productivity. Thus, by using this method of benchmarking, a buyer can immediately raise a flag with its service provider and force it to either:

  • Reduce costs to achieve optimal productivity, or
  • Provide more functionality to align the project with productivity indifference curve

This benchmarking tool also delivers benefits to service providers. If their case in point AD project is application 1, which falls above the indifference curve, they: 1) have consumer surplus into which they can dig (i.e., buyers could be willing to more); and 2) can use the data to advertise their higher productivity performance to generate more business and differentiate themselves from their competition.

We’d love to hear your thoughts on this type of productivity benchmarking. Have you employed it? What lessons learned can you share with your peers?

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.