Monday, August 1, 2011

How Technology Disappears: Part 2 of "A World of Services"

Thinking of technology delivery as an expression of services is a big idea.  Services help technology in business disappear.   
Cheshire Cat image from victorianweb.org

Why is this important?  What’s the payoff?

  1. Agility: The holy grail of business technology is to get to value more quickly.  Services move IT toward plug-and-play, and away from custom-tailored, take-forever-to-deploy solutions.
  2. Cost: standardize, externalize, gain economies of scale. Spend time and money on the things that make you competitive.
  3. Services are a foundational part of the move to stateless devices.  “Your-business-as-a-service” is a perfect match for “any device/any time/anywhere.”
  4. Services are foundational as part of moving decision-making about technology away from those who provide it (the traditional IT department) and toward those who use it.
As we focus on what that means as a trend, let’s examine the idea of services and think of them as part of the future of business.  

Service definition 1: simplify and standardize complex processes

Building a house is a good example of simplified services. Doors and windows are simplified and built to standard sizes.  You can buy what you need off the shelf and install it without customization, secure in the knowledge that it will fit and meet regulatory codes.  Because it was manufactured in large quantities in a standardized way, economies of scale make it much less expensive than a custom-made equivalent.  In exchange, you accept the range of sizes, styles, and colors, and design the house to accept the standards.

In business, most IT functions labeled “-as-a-service” are built on a model like this; users accept some standardization and buy the service as offered.  But that doesn’t fit for every business need, especially when the legacy technology grew up around ever-increasing levels of customization and complexity.  Which leads to:

Service definition 2: abstract complexity

Frankly, some parts of business are complex, and there is no magical way around it.  Even if you overcome the change management issues around greater simplicity of business processes, there are still regulatory and legal complexities that cannot be avoided. There are some complexities that deliver competitive value. But there are ways to abstract that complexity and mask it so that it appears simple. Someone has to manage complexity, but they can deliver it in such a way that those who use the service neither know nor care what is going on behind the scenes.

For an example of this, look to your car.  In the last 25 years, something remarkable has happened to automobiles.  Engines and transmissions, even in inexpensive cars, have growth dramatically more complex than before: turbochargers (sometimes 2 of them), multiple valves per cylinder, with continuously variable valve timing. Direct injection of fuel, electronic automatic transmissions with up to 8 speeds--all controlled by a computer system more powerful than mainframes of the recent past.  

It’s all abstracted from the driver. Start the car and it goes, without you having to care about a single one of those technological marvels.  Furthermore, during the 100,000 mile warranty period, the only maintenance required is fluid and filter changes.  Most of the engine is shrouded in molded plastic, looking more like a plug-in module than a piece of machinery.  Motive power as a service.  

The technology disappears, the benefit is what’s consumed.  

That’s the model current businesses and their IT departments can aspire to as a means of managing the complexity that can’t be eliminated.  The central questions

  1. Does this have to be complex? Is this a complexity of heritage process or legacy technology that is not needed?  Is it a worthwhile tradeoff to lose some customization to gain agility and lower cost? If so, you can move to the “simplify service” route.  Classic examples, standard office applications like word processing and e-mail.  
  2. Is this complexity that adds value, or is unavoidable for structural reasons, such as regulatory compliance?  If so,  the goal would be to abstract that complexity away from processes or people who use it, so that to them it appears simple.  For each complex service, ask question 1 again: are there components of this complexity I can simplify to make the abstraction process faster, easier, cheaper.

If you have succeeded, the result will be “building blocks” for technology and business processes, standard-appearing components.  They can be consumed--used as-is--or recombined to create other services.  

A hallmark of service orientation: those who provide a service know and care about the way it is provided, those who consume it don’t have to: DKDC (don’t know, don’t care.)  As service orientation spreads through IT and a company, DKDC spreads downward from the top, while power to deploy technology and combine services spreads upward toward users.

Service delivery starts with the end user, and works back until it reaches infrastructure. At the top, the main deliverable is “IT as a service.” That service is itself composed of individual and federated services.  This chart shows what that would look like:




The lower levels are foundational for those above. The Service Management level and Service Federation levels represent what I believe to be the future of IT within companies:

  • Definition and management of services becomes a central role, highly technical and specialized positions in the organization tend to be externally sourced as individual service components or packaged as third party services. Internal skills include high levels of focus on service contracts and service level agreements.  The orchestration of services and the management of quality of service delivery take on new importance.
  • Business applications are delivered as a service, either directly by a cloud vendor, as composite applications created in-house through federation of other services, or as legacy applications delivered through desktop virtualization.  
  • At the Delivery level, the close tie-in with stateless computing shows its value.  The entire “business as a service” experience is delivered through a web interface, and IT gets out of the user device management business.  
  • Key vertical roles within the services organization are the technology architect, who works across the various disciplines on service design, integration, and delivery; and the business technology analyst, a main point of contact between top-level service consumers--the users and the business departments--and the various service delivery teams.  But note, DKDC even extends to this level of consumer; if infrastructure-level services are deployed correctly, the analyst does not need to know or care how they are delivered.  

When technology disappears, information technology will have grown up; delivery of business capabilities through services is how that happens.

Next in the Big Ideas series, we’ll look at how stateless computing and a world of services become success triggers for the third major idea: flattening of organizations, and the movement of tech power ever closer to those who use it.

No comments:

Post a Comment