Building blocks, not jigsaw pieces. Image from countingblocks.com |
In the last of the C-suite articles,
I talked about managing complexity, either by relentlessly simplifying processes and applications, or by abstracting a complex service in such a way that it appears simple to those who consume it. This time, let’s take a closer look at the latter: how to use complexity abstraction and why it’s an underappreciated business tool.
A service oriented enterprise is composed of 4 service tiers (for more on service tiers, see “How Technology Disappears”):
This is not revolutionary, but it’s very actionable. By simplifying and standardizing component parts of complex things, the care taken by providers at each service tier abstracts the complex into a simple, consumable product. How can you do this?
The idea is to create a virtuous circle: structuring for managed services enables simplification and abstraction of complexity, which enables greater agility and higher business efficiencies. It sets you up for “one question to rule them all,” namely, “do I have to care about where that service came from, or can I just put it to work?”
A service oriented enterprise is composed of 4 service tiers (for more on service tiers, see “How Technology Disappears”):
- Lines of business, end users
- Service Orchestration
- Service Management
- Infrastructure
This is not revolutionary, but it’s very actionable. By simplifying and standardizing component parts of complex things, the care taken by providers at each service tier abstracts the complex into a simple, consumable product. How can you do this?
- Standardize: practice strong, almost rigid exception management when customization is requested at lower service tiers. This is an area, especially in IT, where businesses have traditionally operated backwards. Your business and your employees are locked down to enable success of highly customized infrastructure and applications, when it should be exactly the other way: very high levels of standardization at lower levels in support of ease of deployment and customization at the user side. If you are abstracting complex services by standardizing their component parts, you almost automatically guarantee your business is right-side-up here.
- Reliability engineering: Attack the weakest link in a complex process, and do the heavy lifting required to get its reliability up. Think of your car engine: the ignition system and fuel delivery systems were once high-maintenance items that demanded a fairly high level of driver involvement. Today, both are handled by computers. The Bosch computer in my old car has now managed ignition and fuel injection without attention for 22 years. Reliability is a great complexity abstraction if you make it a component of service delivery.
- Building blocks, not jigsaw puzzle pieces: each can be assembled into something useful, but jigsaws can only be assembled one way. Building blocks are the ultimate abstraction, and can create many outcomes from standard shapes. That structure is the metaphor for your abstracted complexity. If it only has one purpose, it it worth it?
- Externalize: instead of creating abstraction inside your own four walls, pay someone else to do it for you, and purchase a consumable service, which appears simple to you as the consumer. This is the province of services like cloud computing, third party payroll managers, and distribution services like UPS. Their success lies in managing away the complex so you don’t have to. It’s their core business strength. Is it really worth it to make it part of yours? The greater core simplicity you can structure into your business--the areas that don’t justify customization or added complexity--the more opportunities this solution presents. The explosive growth in enterprise-ready external services and their abilities is also moving favorably in your direction.
The idea is to create a virtuous circle: structuring for managed services enables simplification and abstraction of complexity, which enables greater agility and higher business efficiencies. It sets you up for “one question to rule them all,” namely, “do I have to care about where that service came from, or can I just put it to work?”
No comments:
Post a Comment