I’m sitting on my sofa at home (Yes! Home!) on Sunday morning just before Christmas. I’m “shut down” for the holidays now, but of course, I’m watching Twitter and now listening to my brilliant friends Chris Dancy and Troy DuMoulin discussing CMDB (configuration management database) on the Practitioner Radio podcast. It’s a marvelous episode, covering the topic of CMDB in with impressive clarity! I highly recommend you listen to their conversation. It’s full of beautiful gems of wisdom from two people who have a lot of experience here – and it's pretty entertaining too!
I agree with everything these guys discussed. In particular, I love the part where they cover systems thinking and context as the key to linking everything conceptually. I only have one nit about this podcast, and the greater community discussion about CMDB, though. Let’s stop calling this “thing” a CMDB!
I coauthored a book with the great Carlos Casanova (his real name!) called The CMDB Imperative, but we both hate this CMDB term. This isn’t hypocritical. In fact, we make this point clear in the book. Like the vendors, we used CMDB to hit a nerve. We actually struggled with this decision, but we realized we needed to hit those exposed nerves if we were going to sell any books. Our goal is not to fund a new Aston Martin with book proceeds. If so, we failed miserably! We just wanted to get the word out to as many as possible. I hope we've been able to make even a small difference!
Engaging All Service Engineering Folks: Help Forrester Define “Service Engineering” As A New Role Within Infrastructure & Operations (Or Beyond)! A variety of technology trends such as mobility and clouds are empowering consumers and connects employees who all are interacting and collaborating through apps and devices which are changing the way business is conducted. In response, organizations are forced to accelerate business changes which require the need for agility innovating new technology choices, implementation options, and delivery approaches. In this new pace of change the business demands more of IT to help deliver services which enable and support the age of the customer. Some Infrastructure & Operations teams have made the transformation to manage and support BT services which consist of technology, systems, and processes to win, serve and retain customers. Other organizations still manage and support components which range from operating systems, middleware, general purpose components, applications and custom components built all for specific purposes. I&O teams have become good at building components, but it often lacks the engineering discipline to assemble these components into services that meet specific business needs and are relevant in the age of the customer. To stay relevant and transform Infrastructure & Operations in the age of the customer, I&O needs a new role – service engineering. Service engineers mainly “do” three things:
1. Think and act from the outside-in – this means establishing, managing and continually improving services which are critical and essential for business enablement and business success.
2. Participate and support the DevOps journey – business agility in large parts depends on technology today. The DevOps team plays a large role in the quality and speed of technology delivery.
In August this year I am heading down to our nation’s capital to take part in the annual itSMF Australia event – LEADit. I have taken part in this event to a greater or lesser extent over the past few years across Australia – Sydney, Perth, the Gold Coast and now Canberra. As an analyst who broadly covers the Service Management space (as well as a previously ITIL qualified practitioner), this event is the mecca for those interested in service management in Australia.
Year after year at this event, I see a fair amount of change in the content and focus, but little change in the thinking, and little real movement in the implementation or improvement of the processes – a recent survey between itSMF-USA and Forrester displays the current maturity levels of processes in organisations:
Here we are – years (decades?) after the first ITIL books were written, and demand management is STILL immature. Even financial management has barely shifted in maturity over the past few years. Why is this the case?
As I write this, I am in seat 1A of United flight 1607 from Philly to Houston. playing on the screen in front of me is CNBC. I make no secret of my disdain for much of the so called "news media" so I won't launch into my usual rant there (there are some superb journalists out there, but Murrow and Cronkite must be rolling in their graves!). I am bristling over the coverage right now that is focused on the 787's latest woes. As usual, the talking heads are clueless and painting a doomsday scenario for Boeing! It's a bunch of finance people who don't understand the engineering realities. They're smart bean counters, but not engineers. I am an old engineer, so let me shed light on what the Wall Street mouths don't know. There is an important lesson here for I&O leaders!
There is growing evidence of a harmonic convergence of Infrastructure and Operations (I&O) with Security and it is hardly an accident. We often view them as separate worlds, but it’s obvious that they have more in common than they have differences. I live in the I&O team here at Forrester, but I get pulled into many discussions that would be classified as “security” topics. Examples include compliance analysis of configuration data and process discipline to prevent mistakes. Similarly, our Security analysts get pulled into process discussions and other topics that encroach into Operations territory. This is as it should be.
Some examples of where common DNA between I&O and Security can benefit you and your organization are:
Gain economic benefit by cross-pollinating skills, tools, and organizational entities
Improve service quality AND security with the same actions and strategies
Learn where the two SHOULD remain separate
Combine operational NOC and security SOC monitoring into a unified command center
Develop a plan and the economic and political justifications for intelligent combinations
On 22-Nov-2010, Attachmate Corporation announced it was acquiring the assets of Novell, Inc. Once on top of the IT world, Novell's glory had clearly faded. Along the way, however, it acquired several attractive assets of its own (e.g., PlateSpin, Managed Objects). Towards the end of its independence, the future certainly looked bleak for Novell and especially its management software businesses.
The immediate reaction to the Attachmate acquisition was skepticism among most industry watchers, including yours truly. My reaction was similar when Attachmate acquired NetIQ. After all, what rationale is there to a legacy mainframe software company buying either NetIQ or Novell? The perception was that all of these product families would be milked for their maintenance revenue and innovation, and other development would be killed. It now appears these fears were largely unfounded, though I stand by my original skepticism. Veterans like me have seen such things unravel before.
The various Novell assets have been redistributed across four companies in the Attachmate Group, with the management assets being assimilated under the NetIQ brand. While a full merger of the NetIQ and Novell assets will take at least a year, the (now) NetIQ team has moved with impressive speed to launch its initial consolidated families.
Ciscoannounced today its intent to acquire NewScale, a small, but well-respected automation software vendor. The financial terms were not disclosed, but it is a small deal in terms of money spent. It is big in the sense that Cisco needed the kind of capabilities offered by NewScale, and NewScale has proven to be one of the most innovative and visible players in that market segment.
The market segment in question is what has been described as “the tip of the iceberg” for the advanced automation suites needed to create and operate cloud computing services. The “tip” refers to the part of the overall suite that is exposed to customers, while the majority of the “magic” of cloud automation is hidden from view – as it should be. The main capabilities offered by NewScale deal with building and managing the service catalog and providing a self-service front end that allows cloud consumers to request their own services based on this catalog of available services. Forrester has been bullish on these capabilities because they are the customer-facing side of cloud – the most important aspect – whereas most of the cloud focus has been directed at the “back end” technologies such as virtual server deployment and workload migration. These are certainly important, but a cloud is not a cloud unless the consumers of those services can trigger their deployment on their own. This is the true power of NewScale, one of the best in this sub-segment.
Like many movements before it, IT is rapidly evolving to an industrial model. A process or profession becomes industrialized when it matures from an art form to a widespread, repeatable function with predictable result and accelerated by technology to achieve far higher levels of productivity. Results must be deterministic (trustworthy) and execution must be fast and nimble, two related but different qualities. Customer satisfaction need not be addressed directly because reliability and speed result in lower costs and higher satisfaction.
IT should learn from agriculture and manufacturing, which have perfected industrialization. In agriculture, productivity is orders of magnitude better. Genetic engineering made crops resistant to pests and environmental extremes such as droughts while simultaneously improving consistency. The industrialized evolution of farming means we can feed an expanding population with fewer farmers. It has benefits in nearly every facet of agricultural production.
Manufacturing process improvements like the assembly line and just-in-time manufacturing combined with automation and statistical quality control to ensure that we can make products faster and more consistently, at a lower cost. Most of the products we use could not exist without an industrialized model.