Comedian George Carlin commented that men are stupid and women are crazy — and that the reason that women are crazy is that men are stupid. My observation is that it’s a strikingly similar dynamic to what’s occurring in large enterprises’ spend decisions in the global services market today.
Business stakeholders are “stupid.” They’re off doing their own thing, making snap decisions, stringing together solutions with half-tested as-a-service offerings and believing those solutions will scale up to meet enterprise production needs.
CIOs are “crazy.” They’re tearing their hair out, so to speak, in frustration over the business stakeholders’ actions. They try to engage business stakeholders in conversations, but the biz folks don’t have time for that. Furthermore, the CIOs’ funding has been taken away and given to the business stakeholders.
There is no time to plan, so CIOs must show a complete offering rather than going through a meticulous planning process. And CIOs are told they are accountable for security and compliance, yet they are not given the ability to shape the new solutions going in place. The situation is turning them into crazy people.
Why they talk past each other
CIOs and business stakeholders march to different drums, thus frustrating each other to the point of being stupid or crazy.
But in a way it makes perfect sense since both operate in their own world. And neither perspective is irrelevant. It’s just that the perspectives and operational goals differ in those two worlds, so they misunderstand each other. The business units misunderstand the CIO, and the CIO misunderstands the business units. In the words of Winston Churchill, they are two nations divided by a single language. They both talk technology, but they talk past each other because they come from completely different places.
Carlin’s opinion is that as long as men are stupid, women will be crazy. My opinion: As long as business stakeholders focus on business needs that get met in immediate gratification through SaaS and proofs of concept, the CIOs will be crazy. Look out for some very complicated discussions when it comes to funding and scaling the SaaS and proofs of concept across the enterprise.
One of the better indicators that corporate IT groups are starting to get serious about cloud is their growing interest in solutions that help them aggregate and manage multiple cloud services. Some call these solutions cloud services brokerage and management, and others term them cloud orchestration. While the market hasn’t yet converged on a common set of capabilities or definition, the broad category typically includes the following:
- Service catalogs – “App Store”- like models that provide users access to internal IaaS and PaaS services and in some cases third-party SaaS apps and infrastructure services as well
- Service provisioning – capabilities that support end-user requests, provisioning, and deployment of cloud services
- Service integration – data integration services across multiple cloud services, including “cloud-to-cloud” and “cloud-to-ground” models
- Chargeback and billing – consumption-based metering and billing of cloud services to internal users, including private services and aggregation of public cloud services spend
- Service management – monitoring and management across multiple cloud services, including performance, capacity planning, workload management, and identity management
- Sourcing – contracting and sourcing of cloud services across multiple platforms and providers
These solutions are being offered by a wide variety of players, including not only traditional enterprise systems management vendors – which in some cases are just repackaging SOA offerings – but also global systems integrators (SIs) and focused startups.
What’s important about this phenomenon?
First, corporate IT’s interest in these capabilities is, in a way, an implicit acknowledgement that:
- Cloud services will be adopted in scale across enterprises
- Multiple large scale services will need to be orchestrated and managed
- Orchestrating these services will be hard and will require external third party solutions
This is a far different conversation than corporate IT was having a year ago at this time, which was primarily around what pilot or proof of concept to launch.
Second, interest in cloud orchestration is being “pulled” by corporate IT, rather than “pushed” by the business. A premise we recently heard is that business’ role in driving adoption of cloud is no different than it was in the packaged software era. Packaged software required servers, storage, and networks, all of which required IT management and support. This provided IT with long-term job security and the opportunity to “empire build.” As a result, corporate IT aggressively supported packaged software rollouts and implementations.
The difference in the cloud era is corporate IT’s attitude. To date, it largely perceived the cloud as a threat. But now, IT is discovering it can potentially regain a measure of relevance and control by adopting a service provider mindset, and service catalogs / chargeback models combined with private and public cloud services.
Is corporate IT finally finding a path to building its empire in the cloud? Are you or your IT group considering, or embarking upon, a cloud orchestration initiative? What thoughts and experiences do you have to share with your peers?
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.
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?
While buyers have typically approached, evaluated, and made third-party business process service delivery sourcing decisions at the operational level, and separated out decisions on the underlying software applications and/or technology infrastructure, they are increasingly realizing the value of looking at IT and BPO in an integrated manner.
Enter Business-Process-as-a-Service (BPaaS), a model in which buyers receive standardized business processes on a pay-as-you-go basis by accessing a shared set of resources – people, application, and infrastructure – from a single provider.
There are many potential upsides of BPaaS…but is it right for your organization? The answer lies in evaluating the model based on a holistic business case that looks at a range of factors including total cost of ownership (TCO), the nature of the process/functional area under consideration, business volume fluctuations, time-to-market, position on the technology curve, and internal culture and adaptability to change.
Let’s take a deeper look at the TCO factor, which must be analyzed in terms of both upfront and ongoing costs for all three layers of service delivery.
For our just released research report, Is BPaaS the Model for You?, we developed and used a holistic evaluation framework that compared TCO for BPaaS and the traditional IT+BPO model across three buyer sizes: small (~US$1 billion revenue/5,000 employees), medium (~US$5 billion revenue/20,000 employees), and large (~US$20 billion/100,000 employees.)
BPaaS brings big benefits. It is independent of deal duration, delivers 35-40 percent savings compared to traditional IT+BPO, enables leverage of the provider’s economies of scale, provides access to otherwise cost-prohibitive technology, and allows entry into BPO relationships that as stand-alone’s lack the necessary scale. Small buyers are also highly amenable to BPaaS’ process and technology standardization requirements.
BPaaS is pretty impressive. It delivers 25-30 percent savings over the traditional IT+BPO model, which while less than what small buyers reap is still significant in driving a successful business case. Medium buyers’ increased scale allows them to capture some of the economies of scale benefits even in the traditional IT+BPO model, thereby having a lower differential between the two models.
BPaaS is not too shoddy. While it only provides ~10 percent cost savings compared to traditional IT+BPO, the absolute differential in cumulative TCO can still be substantial given the high base. And, in certain buyer-specific situations such as technology enhancements, exploration of new BPO/IT infrastructure relationships, and expiration of legacy technology licenses, BPaaS can be a good model for large buyers to evaluate. But…their tendency to balk at following a tightly defined, standardized approach – unless significant configuration features offset a good portion of customization needs – reduces BPaaS’ appeal for them.
As you see, our evaluation framework shows an inverse relationship between buyer size and cost savings from BPaaS – i.e., the larger the buyer, the lower the percentage savings. In fact, as buyer size increases, the scale benefits of renting versus owning infrastructure and applications can dip into the negative column over ten years. Of course, the assumptions in our BPaaS to IT+BPO model analysis are ideal, and your organization’s individual reality may be quite different.
To learn more about how to evaluate BPaaS’ applicability to your company, select a BPaaS provider and solution, and implement the selected solution, please read our report, Is BPaaS the Model for You?