Stepping into the Middle of a Configuration Management Project: Watch Where You Put Your Feet

So what is everyone doing in Configuration Management? I can only speak to what I’ve seen. Lots of clients think of the Configuration Management Data Base (CMDB) as the Holy Grail of IT Service Management. And no doubt, the vendors serving this space aren’t going to do anything to dissuade any potential customer from thinking that to be a true statement. But you just have to understand what the CMDB is conceptually, BEFORE you step off a cliff and into a life-long commitment to a vendor. If you are thrust into the middle of a project that’s already under way, take some time first to think about these issues:
• Understand the requirements. If you’re getting involved in a configuration project that’s already in progress, review the specification that went into the design of the CMDB. Along with the specifications, look into the source of the requirements. That's why I recommend using a traceability matrix which requires clear specifications documentation and stratification of each requirement, where they came from and how they will be addressed in the project plan. Things to look for include ownership, views considered, users and customers of and stakeholders in the process, integration challenges with existing tools, etc. I would also ask how they intend to keep the CMDB evergreen which begs the question: What is the source of truth for the data? You’ll need to know if this is going to be a data warehouse project or a functioning CMDB. What are the CTQs (Critical To Quality) that will tell you if the project is on track?
• On this last point consider a tools assessment to make certain that all required interfaces are considered. This is an ITIL-based assessment of the existing IT Service Management tool set(s). While this is done as a team exercise, vendors are not invited at this discussion - only internal tool experts/owners. Vendors, though, may be invited to a separate session following the initial tools assessment. The tools assessment will provide an objective review of existing tools and their ability or capacity to be integrated with the yet-to-be-developed CMDB.
• Particularly if you’re coming into the middle of a project, consider auditing the project immediately. This would provide immediate insight as to the health of the project and would quickly bring an outsider up to speed on how it's progressing and what its intended outcome is envisioned to be. An effective facilitator will also gain insight as to how the individual project team members really feel about the project.
• Find out what the longer-term vision for the CMDB is intended to be. What you want the team to focus on is a relationships-based service perspective. That entails defining a SERVICE which has the following characteristics:
1. All CIs versioned;
2. Components are reusable;
3. Service is built out of the reusable components;
4. The service components will change, thus the state changes;
5. You should be able to manage the service against the established configuration;
6. You need to be able to identify and record where problems occur in the service - i.e. which component of the service fails when the service is not available.
It's this service concept that has, to some degree, given traction to the SOA. I'm not recommending a fully architected SOA but the service concept is realized as a modularized set of components which is really a robust configuration management process supported by a CMDB.
• The configuration process is tricky but should be addressed as well. If you’re going to build a CMDB, it only makes sense that you’ll need a process to support it. But it's tricky because what is hidden in the ITIL materials is really two parallel but distinctly different processes. One is the configuration process itself which is "owned" by a process owner and regularly measured and audited. The other process is the actual implementation of configuration management.
• Configuration is critical for most organizations today, particularly, government, financial and medical companies because of security and SOX compliance issues. Find out if any of the compliance folks were involved in the configuration requirements. If you accept the premise that standardization is the domain of configuration and that standardization is the only way to ensure compliance, then configuration is essential for compliance. You'll want to make sure that the configuration process is capable and will withstand an audit.

Why Process Improvement Isn’t Enough: The Case for a Learning Organization Culture

Lest anyone think I am a PIG (Process Improvement biGot), let me say right now that I do not believe process improvement and efficient production are enough to sustain competitive advantage. We need only look as far as Dell. Here’s a company, one of my favorites at one time, that ruthlessly drove costs out of its production and delivery system. A volume operations company, Dell took the concept of productivity beyond the routine and turned it into an incredible competitive advantage; an advantage that relied on its competition for research and development. While Dell has never been known to be innovative, it does (or did) do what it does/did better than anyone else. Unfortunately for Dell, the laser focus on operational efficiency came at the expense of market sensitivity and innovation.

Dell’s innovation is limited to its lean sales model. This was mastered through the user-friendly web site which offered low introductory PCs with the option to upgrade. Now, though, others have figured that out. Further, computers available in the stores generally have sufficient power for most users (Business Week 9/4/06). There has been a significant shift toward notebook PCs which Dell wasn’t properly positioned to exploit. Since most notebook computers are made by the same companies for a variety of different brands, Dell had no particular advantage in this niche. Dell is also a victim of Apple’s recent popularity and the evolving relationship between Apple and Intel. In response (retaliation?) Dell is now looking to “AMD for its processors. But all of these are merely symptoms of a greater illness underlying Dell’s performance.

Business Week (9/4/06) says that Dell’s rigid focus on operational excellence has created a culture that is “not inspirational or aspirational” and goes on to say that “being a hero at Dell means saving money”. Michael Porter says that a competitive strategy based solely on cost will lead to “predictably disastrous results” (“Competitive Advantage”,1998). We see this cost-exclusive focus in its choice to outsource customer service. Ouch!

Unfortunately, Dell is not able to adjust its strategic vision to accommodate the market dynamic. Their culture inhibits, impedes and even discourages innovative ideas that do not fit the current strategic vision. They have failed to establish the elements of a learning organization that would be sensitive to a changing market and which would adjust the future state, the vision, in response.

While conquering the market for low-cost PCs and servers, Dell ignored several key principles:
1. Michael Porter’s Competitive Forces model which clearly illustrates the sources of competition and the potential for diluting the current strategic competitive advantage. All competitive forces were at risk and, while Dell’s model kept them at bay for a while, changes in the capabilities of other entrants and substitute products were moving in on the space Dell had carved out. The barrier to entry was high but not so much so that a competitor such as HP couldn’t overcome it. While competitors were modeling the efficiencies pioneered by Dell, suppliers were working with Dell’s competitors and the buyer gained greater leverage in the marketplace.
2. Dell’s rigid and unwavering operations-focused culture discouraged internal innovation that might have found ways to sustain its competitive advantage.
3. Dell failed to implement indicators that would be sensitive to the erosion in their current value proposition. Thus, they were not able to anticipate what was happening in the market. It’s almost as if they had blinders on thinking that what worked for them in the past would continue to work in the future regardless of competitive forces (Michael Porter), technology lifecycle (Geoffrey Moore) and strategic indicators (Kaplan, Norton).

Michel Robert provides sufficient caution to staking your future exclusively on cost reduction. He says that “…adding value to each component of your chain may…give you [just] temporary advantage” (Strategy Pure & Simple, 1993).

The Future Ain’t What It Used to Be (Yogi Berra)

This past spring we attended a talent show at my daughter’s high school. Her dad was confronted with a shocking realization of just how much our society has changed. Do any of you recall, not all that long ago, lifting lighters in support of your favorite band or performer? Lighters are not permitted in the school auditorium for obvious reasons but technology still provides an outlet for the teens. During one performance by the most popular garage band in the school the room was gradually illuminated by the green glow of cell phones raised and swaying in tribute to the band. I found this both humorous and intriguing. First of all, I was amused that the gap between my generation and my daughter’s could be so easily characterized by the technology. Secondly, I was intrigued by the overwhelming proliferation of the technology among the students. It is not that I was surprised that so many students had a cell phone. But seeing all those phones raised at one time in a dark auditorium vividly demonstrated just how deeply technology has permeated our society.

No, I’ve not been living under a rock these past ten years. But physically witnessing the actual pervasiveness of the technology so effectively demonstrated by the eerie glow of the phones was humbling. I was reminded of what Ray Kurzweil describes as the “technology paradigm shift rate” (Kurzweil, “The Singularity Is Near”). While building a case for his thesis of humanity’s ultimate conquering of our biological limitations, Kurzweil points out that the telephone took about fifty years to reach levels of significant usage. In contrast, the cell phone took less than a decade. Such exponential growth and acceptance of technology has profound implications for those of us working in the technology field.

As new technologies gain acceptance at an increasingly accelerating pace, our dependence upon solid process architecture will only increase. You’ve heard it said that automating a broken process only increases the rate at which you break something. We are seeing an incredible acceptance of new and automated technologies driving at the heart of the data center. One such technology is virtualization. A Forrester report cited in Network World (8/21/06) claims that 75% of respondents to a recent survey “are aware of server virtualization technology, with 26% having implemented it and another 8% set to pilot it within the next year.” Vendors see the opportunity and are rapidly stepping up to the plate to offer their solutions in this space with promises of huge savings in hardware and the accompanying management, support and licensing overhead. I do not dispute these results. But I feel compelled to caution our data center managers: With the rate of acceptance of new technologies and the pace of change, you must have a solid understanding of how your processes enable the realization of business goals. You must have control over the variables, measures in place to make certain that the promises of new technologies may be appropriately scaled and personnel trained to make good decisions in the selection and application of these tools. Understanding WHAT is to be automated is a prerequisite to making an informed decision about HOW you design and implement a solution.

Why Customer-Focused Process Improvement?

We had storms move through our little piece of paradise yesterday. About the time the storms started doing their damage, my outgoing email service failed…and hasn’t worked well since. As a good customer of technology who understands the importance of recording each and every “incident”, I submitted a repair ticket. The first response from the service desk agent said there was no indication that there was a problem with my service. OK…that in itself is a problem. First of all, the Level One support desk doesn’t know what’s going on. Secondly, their first reaction was to blame the user - ME! OK, they didn’t come out and say I was committing an I-D 10-T error, but the implication was there.

My second email from the ISP said that their servers were undergoing what they called “maintenance.” OK, so this person knows there is “something” going on and it’s on their end and it may just have impacted my service. Perhaps it’s not the user after all. But maintenance is no excuse for my service being out. Email is so ingrained in our communications now that we quite justifiably expect it to be as “available” as our telephones. Any maintenance that interrupts service for more than one hour should be preceded by notice to the customers of the interruption. Even my blog host tells me when their servers are undergoing maintenance. Hey, come to think of it, why exactly is this “maintenance” being done during prime business hours? If the ISP doesn’t have the required redundancy capacity or fail-over technology, they should get out of the Email business. Because, last I checked, this IS a business. Customer expectations obviously exceed the ISP’s ability to provide the service.

If this outage was caused by a power interruption due to the weather, I can understand, to some degree, the unannounced outage. But we do have solutions for that too. If a server failed due to overheating because of hardware proliferation in the data center, then the ISP needs to invest in consolidation and some clustering, virtual or other management architecture to balance the load. If there has been an upgrade that caused the outgoing mail server outage and the intermittent services of Web Mail, then I suspect Release Management has not yet figured out how to do sufficient and effective testing. The ISP apparently doesn’t have an effective roll-back plan as it is apparent, if this “maintenance” was indeed an upgrade, the release did not work. I’m still not able to send mail so my service is down while they’re figuring this thing out. Perhaps we need Configuration Management. If we do need to roll back to a previous state, we would know exactly what that “previous state” is. What a novel thought!

At any rate, the ISP is in business to provide a service. They need to start thinking about their customers. This isn’t about information technology. It IS about business and service however. This is the ISP’s business and service for their customers - ME. That affects MY business and MY service to MY clients. Information technology is there to help the ISP realize its business obligations. And, by sending me a bill every month, they have an obligation to ME. Speaking of that obligation, since they did not specify a service level or publish a maintenance schedule, I’m assuming my service will be available ALL the time. Unless you state otherwise, that’s my expectation.

If the ISP intends to continue competing in this space, they’ve got to get the basics right. What is more basic than Email? OK, I’m not saying managing Email is easy. But I am saying that from the customer’s point-of-view, the perception of Email is that it is a basic service.

I can assure you, that with the competition among ISPs, when options become available this ISP’s market share will be at risk if they can’t get the basics figured out. No one has time to deal with mediocrity especially for something as straightforward as Email. Keep in mind, too, that customer perception is all-important. If the customer doesn’t have confidence in the ISP’s ability to provide basic services, how can they possibly expect to sell that same customer “more bandwidth”, premium cable services or VOIP? There’s a domino effect here that can either make or break the ISP’s market. Geeze, am I saying that best practices in management and customer service can offer a competitive advantage?

In retrospect, this is the only significant outage of this duration that I recall in the past 18 months. But it really doesn’t matter. If I had known ahead of time, if the ISP had communicated the potential outage, I may not have been so upset. But the fact that they did not communicate, or felt the interruption would not be significant - that I wouldn’t notice(?) - suggests an unacceptable attitude, a disregard for my needs as a customers and blatant disrespect for me as an individual.

So is there a lesson in this for the rest of us? Let’s see:
• Empower your service desk with the tools they need to effectively manage triage.
• Train your service desk agents to be sensitive to their customers. The only personal encounter any customer may ever have with your company just may be the first service desk agent to answer the phone or respond to email when there’s a problem.
• Communicate maintenance windows and potential service disruptions.
• Invest in proper testing processes and technology.
• Invest in controlling the proliferation of hardware. A configuration management process is a good place to start.
• Invest in redundancy if the expected service is 7X24X365
• Invest in resilient architecture with the appropriate management overhead to manage the anticipated work load.
• Think “Service Level Management” to first understand what your customer expects and then to set their expectations for the service you are providing.
• Essentially, get control over the variables that comprise your service offering.

Are all these investments worth it? Well, do you want to stay in business? Hey guys, if you don’t want to INVEST in a process and systems architecture that will meet your customers needs, that’s fine with me. Someone else will start serving my communication needs in my neighborhood very soon anyway. Maybe that someone is one of my clients. But just try to keep the rubber bands, duct tape and string together a bit longer so I can stay in touch with my clients. I’m not sure about you but I do have a business to run.

Favorite ITSM Tool?

Boy wouldn’t I like to come out and say I have a favorite tool for ITSM. Wouldn’t I love to say that there’s a tool out there that will meet a company’s current needs and is scalable for future needs. But you know what I’m going to say. I will always defer a tool discussion until I understand what the client really needs - there are just too many variables to do otherwise. I had an engagement with a major financial organization to establish a roadmap for an ITSM implementation. While interviewing stakeholders I somehow stumbled across a financial analyst who had worked on a “process” project the year earlier. Note the parenthesis around “process” please because it’s obvious that ‘p’ word never entered into the project lexicon in any way. This guy wasn’t hiding from me but he was never mentioned on my initial inquiry as to who should be interviewed to establish the roadmap parameters. He told me the IT department had spent nearly half a million dollars the year before trying to put a tool solution in place. Now, a year later and a half a million in the hole, they still had no automated change in place nor did they have anything resembling an integrated or scalable configuration management process. Now THAT was a critical piece of information for the program. Now I had to do a root cause on this now visible failure. It was a critical piece of information as this legacy would impact the attitude toward my program. It quickly became apparent that the organization had jumped into an automation solution before really understanding their needs, let alone their processes. As they began developing the solution, they had no project management thus no factors for success and no means to control scope, measure progress or report status.

I suggested, and they eventually agreed, that we use a tools assessment process based on Six Sigma prioritization technology to make sure the program had the right specifications in place BEFORE we spent any additional money. Such a structured evaluation is critical because it provides everyone a means to objectively evaluate any existing tools before looking at vendor products. That way, everyone understands the gaps in their existing tool architecture and is better equipped to address specifications with the vendors.

We all know, of course, that ANY tool with work, in some fashion, if you throw enough money and resources at it. One of my favorite programmers in a former life described this as S.M.O.P - a Simple Matter of Programming. But as the above-described client found out, that was the wrong approach as the “S” is usually translated as a “$”.

I’m still amazed, however, at the laissez-faire attitude this client had toward this black hole. They didn’t think it worthy to mention while we were building a strategic implementation plan. Even without effective project management, even lacking specifications, how is it possible to spend half a million dollars and still get nothing at all - and not feel the least amount of remorse for such an act? Oh, wait. No, I know what you were thinking. But no, this was not a government client.

How Fragile Are Your Processes?

A number of years ago I had rescued a friend stranded at the Ft. Wayne, Indiana bus station. During the course of the trip, a butterfly got entangled, literally wrapped around, the radio antenna of my car. It struck me, much later, just how fragile that formerly beautiful creature was. At the time, I was too busy driving, moving forward, to pay any, or much, attention to the butterfly struggling with the antenna. I couldn’t wait to pass a semi so it would blow off the antenna and stop distracting me. And I certainly wasn’t going to stop my forward progress to take the time to rescue the creature or put it out of its misery. I was in too much of a hurry for that.

I felt no remorse or guilt at the time. But, in hindsight, I still feel a sense of obligation and am disappointed that I didn’t’ feel any discomfort. I was so focused on the short-term act of getting from one place to another in less than 35 minutes; I didn’t really care about any peripheral distractions. I suspect I was immune to any level of emotional concern.

OK, race ahead a whole bunch of years. IT data centers are focused on their short term deliverables. While they are “attending to today’s business” what is the likelihood they will ignore the state of their processes? How likely is it they will ignore the pain of their staff, their customers and their superiors while trying to “get from point ‘A’ to point ‘B’? I see these fragile processes that have been ignored for years, tangled around some obstacle and those responsible are looking the other way. Distracted, self-absorbed, or protecting their jobs and defending their turf, they won’t, or can’t, take time to address the carnage right in front of their noses.

The problem is the processes won’t “blow off the antenna.” They’ll hang on, broken and disfigured as they might be, and continue to hamper efficiency and productivity. Why do some managers take such a dispassionate stance when it comes to their processes?
• They don’t bother to put controls (and a control plan) in place to manage their processes.
• They’re too busy with day-to-day, “keep the lights on” activity, to be concerned with the processes that are vital to their production activities.
• They don’t have time or perhaps the insight, to put monitors and key metrics in place to gauge the health of their processes.
• They think process improvement is hard; perhaps the mystique surrounding legacy quality initiatives is intimidating.
• There is no perceived financial incentive to pay attention to process health.
• It’s easier to bypass an existing process rather than fix or revise it.
• There are no process owners in the organization or those present don’t understand process fundamentals.
• There is no coherent strategy to resolve issues permanently; true problem management does not exist.
• They do not recognize how the time and associated expense of repeatedly fixing issues impacts overall availability and ultimately revenue.
• They cannot justify dedicating staff to permanent fixes.
• The culture of the company does not support process documentation, process improvement, process monitoring or alignment of processes with organizational vision.

I’ll not preach about the value of being proactive. I’ll just say that, just as I ignored that butterfly, managers who disregard the tenuous nature of their processes are destined to a spiraling cycle of destruction. These processes which were functional, effective and beautiful at one time are now ignored and totally disconnected from the current needs of the organization. They have become disfigured and broken. The trip, from ‘A’ to ‘B’ will be mined with traps and hazards. Caught up in the adrenaline of fixing an issue, managers will only feel remorse much later. They will continue to handle availability events and service delivery failures as one-offs, and fail to see them holistically, as they impede production, profitability and employee and customer satisfaction. By the time they get around to thinking about strengthening their processes, it may be too late.

Are Recruiters Adding Value to IT?

As an independent, one of the vehicles I use to secure leads is the Web-based job search facilities. Though they always generate interest, none, so far, have generated any real business. The reason, I believe, is the recruiter element. Recruiters routinely search the web in search of warm bodies to fill a contract. With only one or two exceptions, no recruiter has really taken the time to understand the job they are trying to fill. Rarely does a recruiter have any knowledge at all of ITIL, business strategy, SOA, COBIT or even Six Sigma. Now, understand, I don’t expect them to be experts, but how can they possibly present a potential candidates skills appropriately, with conviction and insight if they don’t even understand the role they’re trying to fill? OK, I’ll excuse their lack of knowledge in this space. But I cannot excuse their ignorance of the job they’re working. They know nothing more about the job than what might be posted in the job description. None, absolutely none of the recruiters I’ve spoken with can answer any of my questions about the position pertaining to the level of sponsorship, relevant work that may have preceded the project, the team currently on-site, etc.

Even this ignorance wouldn’t be such an issue if it weren’t for the fact that every recruiter wants to know “your rate”. This is usually raised as the second or third question in the initial conversation. My rate, dear recruiter, depends upon what the position requires and the potential for project success. My goal is to spend my time on projects that will succeed. I’ve had a lifetime of working on mediocre projects. I want to know, going in, what the success factors are. We can’t get to that level of discussion if I’m forced to commit to a rate even before you, dear recruiter, can answer my questions about the project. Certainly, every recruiter offers to be available to answer questions. But rarely can any of them really come up with a substantial answer. Most recently, one recruiter, when asked if the position was a leadership or task-oriented function and at what level in the company the project was sponsored, begged off, saying he would have to get back to me. Five hours later I got the answer: “The position is mostly functional.” OK, what the hell does that mean?

So, I ask, is your company getting its value out of the recruiters it hires? Are you doing enough to audit the quality of candidates they send you? Are you working closely enough with your recruiter to prepare them to be effective in running interference for you?

If these basic components are missing, you, as a corporate IT manager, are likely missing out on valuable candidates that can add to the potential for project success. Far too many recruiters I speak with really know NOTHING about the industry I serve. They're just matching warm bodies with key buzz words in the industry.

Automated Detachment?

An acquaintance of mine just bought one of those heavy-duty slide rules in a leather case. I've not seen it but it sounds like the slide rules I always wanted when I was in high school. The TI 30 had just come out about that time and had fast, accurate calculations for addition, subtraction, multiplication AND division!

But I still wanted a really good slide rule in a leather case. Really. Mine were always the plastic kind. I still have one or two. But, that $130 calculator we bought my daughter last week for “integrated math” in high school blows the darn thing away. That said, though, there's something, well, stable or reassuring about "mechanically" manipulating the log scales as opposed to the impersonal and detached button-pushing on a calculator. It seems as more of an art in which you become engaged and actually participate. You have to put some of yourself into the answer. It requires you to understand the logic and to use some piece of your brain to get your answer. It's engaging. "Eyes attached to a brain" as one of my colleagues has said. The calculator though fast, accurate and convenient, somehow cheapens the process.

That seems to be the problem with so much of the work I do today. Infrastructure managers are looking to take the thought out of building and maintaining and improving the processes used to manage the infrastructure and support business needs. They are looking for easy templates, quick hits that will yield drastic improvements with minimal investment, planning or even a modicum of thought. This is the reason we use a RACI chart for all our project plans, implementation roadmaps and process architecture designs. We need to force managers to think through what they want to accomplish, to take ownership and responsibility and to be accountable for the results. There’s a problem with accountability and a resistance to taking the time to understand the drivers of good performance. Managers often take actions that impact the productivity and efficiency of their operations with no more thought than they might use when they enter variables into a calculator. Just as we push the buttons on our calculators and wait for the “correct response to an infinite level of accuracy” infrastructure managers detach themselves from the structures, drivers and variables that make up their operations and look outside for a solution that will magically transform their environment. We only ask that they engage themselves in the process and actively participate in the results. I miss the power and satisfaction I felt as I manipulated the scales on my slide rule.

So Now What?

We've got a turf war going on in the ITIL certification space. At least, lacking any more specific information, that's what it appears to be. EXIN, ISEB and the itSMF look like they're about to be left out in the cold.

The OGC has signed an ITIL contract with the APMG. That indicates that the APMG will be "the" certification authority for ITIL. Up to this point EXIN and the ISEB have, shall I say, "competitively shared" certification for the Foundations and Master's/Manager's levels. Their certified courses were mostly comparable and the final certifications were considered interchangeable.

Lately, however, EXIN was beginning to adopt a slightly different approach to its "Practitioner" certifications. This approach is, in my opinion, more strategic and reasonable. EXIN has been working toward a strategic grouping of related disciplines such as Service Desk, Incident and Problem as one module or Change, Release and Configuration as another. Such a strategy is makes sense because, for example, Change and Configuration cannot exist without one another and Release is a major element in the execution of change and in the maintenance of the CMDB. This is certainly more reasonable from a financial perspective. Under the traditional ISEB plan, the student would have to sign on for three individual classes to get the same level of knowledge offered by just one EXIN class.

I’ve spent some time on this to point out one possible reason for the OGC’s decision to sign with APMG. Now don't get me wrong. I sincerely believe the EXIN strategy is good for the industry. But with two different certification authorities in the mix trying to differentiate themselves in the marketplace, the student can easily become confused. Managers approving training need to evaluate one certification body over another. When push comes to shove in the course of business, the manager may elect to avoid the purchase decision altogether if he or she cannot distinguish between the two bodies. So, the agreement may lead to more consistency in training and certification, although again, except for the Practitioner training, there was really no significant difference between EXIN and ISEB.

As of this writing there is little clarity on what the OGC decision means for either certification organization. They have published a joint statement in response to the OGC’s decision. But it really only adds to my suspicion that EXIN and ISEB really don’t know what this decision means.

While the confusion is rampant for EXIN and ISEB, the itSMF is on the outside looking in right now trying to figure out what it means to them. To this point they’ve been the recognized advocate and promoter of the ITIL framework for the user. They were the authoritative resource for information. Their future is uncertain because we really don’t know what the APMG agreement really means.

The national itSMF site recently published an article which is getting a lot of readership that provides a better perspective on the decision than that offered by either the EXIN/ISEB joint statement or the OGC. The article, "OGC signs ITIL contract with APMG" presents some thoughts of interest. Two lines stand out in this article:
1. itSMF is still trying to find its position and there's little chance they'll be in charge of ITIL any more. This may degrade the role of itSMF to that of a supporter.
2. APMG usually makes the accredited organizations pay for the right to perform their business. So this will probably clash. Which leaves APMG with just one option: create a new certification mechanism - without EXIN and ISEB.

OK, so now what? What does all this mean? Well, I don’t even pretend to know because I’m not sure anyone who has published a statement on the matter really knows what it means. No one is particularly forthcoming in making the announcement public. I’m on a direct mail list for both EXIN and ISEB and have yet to hear anything from them. The itSMF hasn’t been real forthcoming on information either.