What to look for in your strategy leadership?
Companies need strategic decision makers and executives with the ability to overcome their own cognitive biases against radical new methods of delivering services to customers. In other words, they need executives that view the world through the lens of modern computing and business paradigms, can take delight in looking at the latest app and getting curious about its AAARR metrics, and can take a startup approach to market size and traction. These things will significantly effect their ability to experiment and grow corporate strategy practice in the brave, new cloudy world.
Interesting mind the gap piece this week taking us back to the stratification of IT discussion. Geoff Smith over at Journey to the Cloud wrote a thought provoking article with some nice infographics that I think will resonate for a lot of us with service management backgrounds. I find myself calling large O&M ITIL organizations legacy a lot nowadays. We need ITIL legislators today to suss out the right service contracts for our cloud vendors - but I get ahead of myself here’s some pieces of the article:
IT management used to be about specialization. We built skills in a swim-lane approach – deep and narrow channels of talent where you could go from point A to B and back in a pretty straight line, all the time being able to see the bottom of the pool. In essence, we operated like a well-oiled Olympic swim team. Each team member had a specialty in their specific discipline, and once in a while we’d all get together for a good ole’ medley event.
Desktop || App || Perimeter || Network || Servers || Middleware || Storage
But is this the way IT is actually consumed by the business? Consumption is by the service, not by the individual layer. From a user perspective, the individual layers are irrelevant. It’s about the results of all the layers combined, or to put a common term around it, it’s about a service. Email is a service, so is Saleforce.com, but both of those have very different implications from a management perspective.
A failure in any one of these underlying layers can dramatically affect to user productivity. For example, if a user is consuming your email service, and there is a storage layer issue, they may see reduced performance. The same “result” could be seen if there is a host, network layer, bandwidth or local client issue. So when a user requests assistance, where do you start?
. . . what if the service was Salesforce.com and not something we fully manage internally? Extract the individual layers and combine them into an operating unit that delivers the service in question. The viewpoint should be from how the service is consumed, not what individually makes up that service. Measurement, metrics, visibility and response should span the lanes in the same direction as consumption. This will require us to alter the tools and processes we use to respond to events.
The other side of this story of course, is if you’re becoming a cloud service provider as an IT organization. Since IT as a service exists, and competes with your IT organization today - it’s only natural to want to go down that path and start a kind of chargeback or showback to drive efficiencies across the enterprise or monetize your capabilities in your market. Thing is, much of these things have never been thought through by IT organizations. Metering, billing, capacity management (yes, many don’t do it right), monitoring of all the layers, encapsulating data or allowing multi-tenancy, the list goes on. Most heat maps I put together for IT organizations who are building out cloud capabilities that they intend to sell are startlingly red to orange, because they’ve only provided services inside their company - kind of like a cobbler making shoes for his family - they may cut corners because they know that they will always be around to deal with any issues that arise. The game changes with external customers, and I think that’s a great topic for debate at length :)
JP:
How did I get moved to last every week?
CloudBees, Cloudsoft Corporation, Huawei, Oracle, Rackspace, Red Hat, and Software AG have announced a new PaaS management API called Cloud Application Management for Platforms (CAMP). The API can be used by cloud service providers and users to create applications for managing resources in the cloud. The initiators start from the idea that cloud users should not deal with low-level resources such as virtual machines, storage or networking, but rather should be able to access high-level resources, such as applications and their components. Also, users should be able to access PaaS services from different vendors using a single management console, and they should be able to easily transfer resources between different clouds.
So many mixed feelings about this:
1) reminiscent of the XML standards efforts of the late 90’s early 00’s
2) Overall a solidly defined specification
3) Didn’t we have application state management already defined in J2EE? Why are we re-inventing the wheel?
4) If a tree falls in the forest will anyone hear? This specification arrived with as much gusto as a a tree falling in the woods with no one around
5) Where’s VMware? Amazon? Can this group expect to succeed if CAMP not adopted by Cloud Foundry and Elastic Beanstalk? Is this just a fool’s folly?
