Tag: application development

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.