Image via Wikipedia

A little unusual post today, but I figured out how to make iTunes accept a longer ringtone – it is iTunes that limits the ringtone length, not the iPhone itself. And the best thing, you need no extra software and no jailbreak.

So how to do it? A few steps:

1. Create a short ringtone for your iPhone
   1. Make a snippet of one of your favorite mp3 files or use the iTunes Information “Option” settings to Start/Stop quickly
   2. Use iTunes to convert the mp3 to AAC. You might have to set the CD import settings to the AAC codec, if you have set the Start/Stop time this will only convert the snippet
   3. Rename the file extension from .m4a to .m4r (ringtone)
   4. Drag & Drop the file onto your iTunes library
   5. Now you have a ringtone
2. Sync ringtones to your iPhone – I set it to sync all of them
3. Now you have the short ringtone on your iPhone
4. Make an AAC version of the longer file, either resetting the Start/Stop time or using a different mp3 file.
5. Replace the existing (short version) of your ringtone with the new longer one. It might be needed to have the exact same tag information (I have not tested that)
6. Disable the sync in iTunes and apply
   • The ringtones will be removed from your iPhone
7. Re-enable the sync and apply
   • iTunes will now gladly sync your new extra long ringtone to your iPhone

I have a full length song on it right now, so I don’t know what the upper limit is. Enjoy!

What framework to base measurement on?

Most other participants in the project came from the business intelligence side of things, so I was the main responsible in deciding what kind of measurements framework should be used. As I am quite firm in the ITIL® arena I could immediately dismiss the initial idea of using ITIL® as a reference for measurements. I had only used COBIT as a reference  in order to find proper target definitions as well as control objectives and activities  for processes and it worked pretty well at that. Many in the IT service management arena prophesy a nearing war of the frameworks in which COBIT 5 “the delayed” might take on ITIL v3 2011 “the snobbish” (what is the penalty for heresy in castle ITIL®?). So why not check out the challenger and see how he performs in close combat?

Elation

Well at first the proposal of using COBIT was great. Instead of the long bullet lists with generic information COBIT has proper tables. COBIT is much more concise in its description and it has a structure for measurement in it.

Click to enlarge

COBIT 4.1 Component Relationships, Page 23 of COBT 4.1 Main

In contrast to a simple “Book/Life Cycle” then “Process” arrangement (or Activity, or something, btw. how many processes?) COBIT has a goal hierarchy. This suited our ideas very well. It might make measuring more interesting and more meaningful if it would be sorted and organized in a hierarchy of goals (starting at the business goals, finally getting rid of this plaguing inside-out thinking).

Click to enlarge

COBIT 4.1 Goal Relationships, Page 22 of COBT 4.1 Main

All of these goals are directly and indirectly measured by metrics, some called Outcome Measures, some Business/IT or Process Metric and others Performance Indicator. Hey, the decision to use COBIT looks better and better and we just used information up to page 23! What marvels will lay ahead in this treasure trove of a framework?

Click to enlarge

COBIT 4.1 Relationships between Processes, Goals and Metrics, Page 23 of COBIT Main

Disillusion

Well, being on page 23 of COBIT was the issue. I knew that the really interesting parts of COBIT were to be found in the individual process chapters. I really dig the formal input and output definitions, I like the RACI chart (even if it is too high level for many practical aspects, but how should COBIT know the organisation of my current clients) and I often used the concise control activities. But now we wanted to go to a whole new level, we wanted to put COBIT in a complete measurement framework, we wanted to provide the “über-companion” to all COBIT related activities.

Which turned out to be the problem, since people putting things in systems need exact definitions. They need a clear relationships between all objects that will allways hold, they need a mathematical correct definition of your KPI or else you will pay penalty of breaking invariants.

Hierarchy?

The first issue was easily solved. We expected the goals to be in a proper hierarchy. But then the first analysis showed that from Business Goal level down the hierarchy was not a hierarchy. Each IT goal supports more than one business goal and somehow this is hidden in the COBIT documentation. No big deal, with the right definition (turning our hierarchy into a directed non-looping network) we retained the ability to calculate measures and summarize information (a network with loops will often reduce your ability to deduct anything to zero).

Exactness of COBIT

Next upon the agenda was extracting proper Business, IT, Process, Activity Goals and their Measurements (remember, Outcome, Goal Metrics and Performance Indicators. So let us have a look at a sample definition, using DS13 Manage Operations.

Click to enlarge

COBIT 4.1 DS13 Manage Operations - Goals and Metrics, Page 151 of COBIT 4.1 Main

So you have 3 IT goals for DS13, which are measured by 2 metrics and driven by 3 metrics. Your 3 process goals are measure by 3 metrics (great!) and driven by 4 metrics (huh?) and the 2 activities are measured by 4 metrics (not driven at all). So anyone designing a system is going to ask you (the so called subject matter expert):

Which metric drives / measures which goal?
What is the (exact!) difference between a metric driving and a metric measuring a process?

OK, you can get through that. You have to rely on the CS™ ability. Common Sense™. Then you get on to defining the metrics, so that they can be measured correctly.

Number of downtime incidents and delays caused by deviating from operations procedures

Ehm, number of incidents and their delays? How do you “AND” these measures? Addition? Maximum? Weighted Average?

Percent of work schedules that are automated

DS13 Overview

OK, so the naive approach for this is storing 2 numbers. Number of “Total Number Work Schedules” and “Number of Automated Work Schedules”. By the way, what is a work schedule? Oh and another thing, which of these are outcome measures, goal/activity metrics and performance indicators? Do we need to separate them? And why is it that the description on page 149 lists the two IT goal metrics and one of the activities metrics and not the other 6 metrics? Oh and while you are at it, what indicator in your incident management database defines that an incident impacting a service level is an operational incident? I could continue here for hours.

So what do you do? You sweat over each of the measure and try define something useful. Something that is sometimes useful and can be measured. Or you go for some normally unmeasurable metrics and make them measurable, like the ratio of unauthorized changes to the infrastructure. Try find the unicorn.

Size does matter!

COBIT has 4 Perspectves, 34 Processes, 115 Activites and a mind-boggeling 340 listed KPIs (approximately, see below). Who manages by looking at 340 KPIs? We wanted to go from top to bottom at least for one business goal (17 in total listed), so we though 340/17 (naive, I know) should result in 20 KPIs beneath a single business goal. We focused on one business goal (BG4) which contained 2 IT goals (3 & 23), which was influenced by 10 processes, which resulted in quite a high number of activities. All of these contained 117 measurements. Let me repeat that: one hundred and seventeen different measurements beneath a single business goal out of 17, which for the reason of simplicity is only supported by 2 IT goals.

…
…
…

After you digested this a bit, let me mention that many of these measurements are not simple measurements, but calculated measurements which result from combining at least 2 different basic measurements (e.g. Percentages). Or other strange combinations seen above. A little chart here to visualize this problem:

Click to enlarge

Size in connections

Data Warehousing

After you somehow and unsatisfactorily solved all these issues, you get to a load of other things that make your life hard. Some are rooted in the way COBIT is working with metrics, some are just basic issues of how to combine several meaningful measures into one meaningful value for a goal metric without loosing too much information and without overwhelming the management user. More on this in later posts.

Reality

Well, in this project we have overcome a lot of these issues. We have used COBIT as a reference framework, but we have used CS™ more on the detail level.
Did COBIT help us with defining a measurement framework?

Yes it did. The overall accepted reference to COBIT makes it easier to present a solution. The predefined goal hierarchy (ehm, non-looping directed network, my graph theory classes are a long time away) was a big help in getting started.

Did COBIT make it more difficult defining a measurement framework?

Yes it did. The KPIs in the framework are quite frankly an untested mess created by people that have never gathered these measures in reality. They may have seen reports containing them, but they never had to gather the information. Many of the listed COBIT measures are not defined, use ambiguous terms, can not be computed, are not worth reporting this way, provide no or dubious value or are just plain nonsense.

So is COBIT practical enough for real world usage? In my opinion it does contain a lot of value but it is in version 4.1 far from a practical how-to. The danger is that it contains information that you can regard as practical advice like the KPIs which does not live up to the kindled expectations.

Final words

Re-reading this post leaves quite a few loose ends and some teasers, but I think that is a good thing. I will try to live up to that in the next weeks.

The project idea started 1,5 years ago, the students put so much effort into it that I can really justify a little tease. Any further ideas on measurement frameworks? Please comment, tweet, google+ message or an old fashioned email is really appreciated.

What happens to documented bad practice? In my opinion it becomes almost indistinguishable from good or bad practice – it becomes the way things are done. And the way things are done is never rethought again. Good or bad, best or worst practices become common practices – things that you don’t think about agin.

Why do I blog about this? Well in a recent project I started to think again about the strange separation that all practices seem to make about Availability-, Capacity- and Performance Management. The more I started to think about this, the more these seem to be different aspects of the same tasks.

1. Gather your requirements
   And this is not just about functionality!
   Gather information about Availability needs (Will people die when this stops working? Will we all lose our jobs? Will some people lose money? Will we all be surprised by what we get in the cantina?) early in your project.
   Do the same for Capacity (Will some people use this? Will this number increase with organic company growth? Will it grow according to the population growth? Or will it just skyrocket as soon as we are published on TechCrunch?).
   Of course the same is true for Performance (Will people accept to wait 15 minutes for our analysis report? Will our customers turn away if they get a bad performance once every 10 requests? Or once every 1000? Will a delayed transaction cause us lose the next war?).
2. Design for these requirements
   That is the easy part: If you provide the requirements, developers, system architects and other specialists will do their job properly.
3. Design & Develop for managed service
   Many applications log issues to some obscure log file. Many report timings somewhere when run in Debug mode. Others will deliver information about the number of concurrent users when treated right. Make sure your application/service/software or system does this all the time. Make this compatible with the monitoring environment your ops is using – allow them to monitor health before (!) you go to your first testing phase. Have this as a basic non-deleteable requirement, including defining thresholds.
4. Prepare for production of these requirements
   The most overlooked part. If you expect skyrocketing growth of usage, prepare for skyrocketing growth in support. If you have 0.1 % of failed transactions that need manual verification or override be aware that increasing usage by 100 also requires you to have more staff on hand. Do not leave this to developers – they tend to underestimate this.
5. Report and Analyse your Quality
   Take the information on availability, capacity and performance and report it regularly. Tweak your monitoring threshold so that the most important stuff generates just enough alerts to keep your staff busy. If they are doing nothing in the night – your alerts need to be more sensitive. If they start ignoring alerts, decrease sensitivity. If your overall agreed targets are not met – tough luck, add people to the problem.
6. Feedback loop by using and empowering Problem Management
   ITIL® does not tell you this, but all the Design processes have a secret interface towards problem management. Every time you do not meet your targets in availability, capacity, performance (and all the others) you need to log a problem. Make sure the design team gets those.

Strange – this started as a simple rant post on the term best vs. good practice – and has changed a bit. Be prepared for innovation.

The goal of request fulfillment is to provide the service requests of the client to the provider and to fulfill these requests successfully in time with minimal risk for the client.

You can immediatly see that the author of this prosaic paragraph was inspired by ITIL®. So what does the original ITIL® tell me about this:

(Service Operation) A request from a User for information, or advice, or for a Standard Change or for Access to an IT Service. For example to reset a password, or to provide standard IT Services for a new User. Service Requests are usually handled by a Service Desk, and do not require an RFC to be submitted.
See Request Fulfilment.

Does this help me? Let us dissect this definition.

We have a list of possible meanings here, separated by or in the first sentence. So let’s check those:

• Request from a user for Information
  Could be, but does not fit in with the request fulfillment idea of menu selection. Does not need financial nor other approval. So not a real good example.
• Request for advice
  Hmmm, request for consulting? OK, but again, not a real standard product you can find on a menu. Could need some form of approval, but in my experience again not the perfect example of a standardized service request.
• Request for a Standard Change
  Is it useful to explain on abstract term with the next similarly abstract term? Not in my opinion. If the definition is stated this way, request fulfillment is reduced to an entry point for standard changes.
• Access to an IT Service
  This is the first entry in the list I can really live with – as an example. One type of service request is getting access to something. Often this is then fulfilled by Access Management, so request fulfillment is the entry to this.
• Reset a Password
  This is one of the classic controversies in IT service management – is a password reset a service request or is it an incident with an inadequate authentication service? I prefer the latter since this enables you to log a problem against all those unnecessary password issues we have.

The second sentence is no better:

• Handled by the Service Desk
  Please do not define a thing by how it is handled. This tells me nothing new.
• Does not require an RfC
  This contradicts the “Request for a Standard Change” line above – even the smallest 3-step variety of “standard operational change” process flow starts with **artistic silence** Create RfC.

So great, ITIL® v3 does one thing right and adds a request fulfillment process and fails misreably in defining it.

OK, next: COBIT 4.1. Well, service requests are hidden in DS8 Manage Service Desk and Incidents. Great COBIT ignores the needed definition of service requests as well.

ISO 20.000? Well section 8.2 in part 1 says one the objective of incident management is to respond to service requests. Part 2 6.2.2 lists the “requests for help” as a part in a report.

So there is no generally accepted definition of service request which achieves at least a basic level of quality? Next up a personal definition of service requests.

In my opinion this will open a huge opportunity for music lovers: Instead of looking for illegal sources of music and then “authorize” them via Apples service there could be a much better option. How?

Just make a list of all the songs you like to have, make a silent mp3 or aac file with the correct meta data – and possibly the correct length. Put it in your music library and ask iTunes to match it. Then you can start streaming happily (and we all know that streams can be stored easily).

So what can Apple do to prevent this? Since iTunes Match promises to be quicker than uploading the whole song Apple, so all Apple could do is start fingerprinting all songs. So my guess is that this fingerprint algorithm will be broken pretty quickly. As soon as the fingerprinting is broken, people will start to share the fingerprints of the songs and software will be available to generate trick mp3 files to fool iTunes into matching the right song.

Can Apple and the music industry stop the sharing of the fingerprints? I don’t think so, since the files would not contain the original work so they could not be protected. But we will se attempts (just as we have seen attempts to protect integers).

Is there any other way for Apple to make sure you really have the song? Even in poor quality?

Image via Wikipedia

Just as last year (and the year before that), I will be speaking at the German itSMF conference on the 7th of December in Darmstadt. My topic will be the “Ménage à Trois” or how to switch providers in outsourcing.

I recently had some additional experiance on this, so I do hope it will be an interesting speach. So please do come to the itSMF yearly forum, not only to see me.

What does a new standard need to become famous? For one it needs its market niche and a few dedicated people to build the first successes. And next?

To become a standard or accepted framework the new ideas need to capture a buzz word. According to marketing experts an exponential growth is achieved by convincing people known as experts, networkers and sales people.

The experts are really deep knowledgeable in their fields. So initially they will only approve of a good idea – for their area of expertise. Most experts are focused on things and not on people, so they are no networkers.

For an idea to spread quickly it needs to be picked up by a networker. A networker is someone who knows an exceptional amount of people (often more than 10-20 times the average) and is well-connected to them. So a networker can spread out an idea.

It then needs to catch a proper sales person. A sales personality is always on the up- and positive side, so they are very convincing. If combined with a networker, they have a strong spreading effect.

So, now the trick question: For whom do these networkers and sales people often work? Do they work for companies that need to adapt to this new framework? Or do they work for companies that want to use new buzz words to sell their products (aka consulting, software, etc.)?

Since now the spreading of the framework is in the hands of people who want to utilizes the fame of the framework, they will start to widen the scope, attribute miracles to it and reduce the amount of expertise in the framework.

This will down the quality of any framework. It will try to set up a theory of everything, will promise instant salvation and is focused on keeping it’s multi-billion dollar industry alive.

Any resemblance to existing frameworks is pure coincidence and not intended by the author.

1. Official “ITIL Tool” endorsement by the OGC
2. Bullshit Alarm: BMC awarded “ITIL(r) Process Compliant” certification
3. Even worse: CobiT Tool Compliancy
4. Will the SW Assessment Scheme ever be open?
5. OGC/APMG open up the SW Assessment scheme – more bullshit?

Some may remember the reaction by many IT service management professionals to the OGC’s endorsement of Ken Turbitts the software assessment scheme announced by Ken Turbitt in March 2009.

One of the most hilarious parts of making a prescriptive set of tool requirements out of a set of non-prescriptive best practices was that the criteria of the assessment were kept a secret. So the only thing such a badge would tell a prospective buyer is: This company paid money to receive this badge of honour and they do have a few clients that are not afraid of publicly stating that they use this product.

Right now this has changed, since at least the mandatory part of the assessment scheme is publicly available at the itil-officialsite (Thanks again to the itskeptic for alerting me to it). It does not state if there are other criteria lists used, so I am going to assume that this is all there is.

I did not have time to scan through all of the 22 listed processes yet, but just reading the first (incident management, staggering 25 questions that need to be in the tool, automated & documented), gave me an urge to write this blog post. If this list is all there is to making a proper “ITIL-Tool”, than I wonder why the vendors charge so much for them.

Each criteria criterion is described in the fine detail of a maximum of 2 sentences or 3 bullets in a list, making the total list of requirements less than 2,5 pages long (changing the layout a bit would fit all on one single page). Questions like

Does the Incident record contain a field or fields to relate a CI record(s) to the Incident?

or

Does the Incident record contain a field or field(s) to assign an initial incident priority according to pre-established or manually overridden conditions? (CI type, Business Services impacted, level of service disruption, security breach, Service Request)?

do not provoke confidence about the quality of this assessment. It ommits a huge amount of requirements you would list for a tool to be usable and it also omits a huge amount of questions about following proper ITIL guidance (e.g. no mention of major incidents, of urgency and impact, recovery within incidents, links to problem- or change management and many other things).

Sorry, but I have to cry bullshit once again. Nobody in his right mind with at least a grain of experience in assessing software or implementing IT service management processes will ever use such a useless list of questions. So as expected in the previous series of this post, it is just a clever simple plot to wrangle some more cash out of the ITIL market without producing anything more substantial than 2 sheets of paper.

You may say that there is no real harm done, just a few bucks taken from the software vendors, so what? Next time I am sitting with a customer asking me why we need all this fuzz for implementing some simple processes that the tool he just purchased brings along out of the box, you ask me again. With this lousy scheme my customer can even say: Hey it has the formal approval of the “owners of ITIL”, so this must be the rigth way.

I will now go and “develop” my Excel based tool for accreditation, dirctly after a short period of proper mourning for the IT service management practice.

Bottom-Up : This means define them technology based. IT should define its services based on what it knows best, the T in IT. This results in services like “Quad Processor 4 Gb WINtel Server 64-Bit Windows Server 2008″. These services can be easily compared to other providers, probably resulting in thoughts about outsourcing, especially since these services do not contain the additional business support effort internal IT provides. IT is way below business in hierarchy and looses out.

Top-Down : This is often used to indicate that the services are business defined. Now IT receives the services it should provide from top down. This indicates that IT is beneath the business and results in IT being a sub par partner, the services will loose touch with IT. Services can not be compared, but since IT is not capable of delivery (the service level targets were set by the business) the perception of IT in business is lousy. Thoughts of outsourcing appear, since the big providers can do this better, can’t they?

Inside-Out : In this scenario IT believes to be on par with the business. They start defining a lot of business related service but do not get early business involvement or acceptance. This results in IT missing the expectations of the business. Usually Inside-Out IT shops quickly become Bottom-Up ones.

Outside-In : IT acts as a proper service provider should and meets the business on par. ITs position is strong but service orientated resulting in business relevant IT services which can be achieved. IT knows when it should say yes and it can say no to requirements that can not be met. Since IT now thinks as a business, it will start to organize itself according to the business requirements. It may decide to out-task certain standard products and will meet IT service providers in a professional manner resulting in functioning agreements.

It contains 4 phases:

1. Phase 1 – The Hatching
   In this phase innovating companies build a set of processes that greatly increases their quality and ability to perform. They talk about this on several events and an interesting label is attached to it. Other innovative people are atracted to it and start to implement similar processes, always adapting them to their need. Initial documents are generated and a simple ownership body is set up.
2. Phase 2 – Adolescence
   As more people learn about the new standard, it undergoes a phase of quick growth. Innovative consultants jump onto the wagon and drive expansion. Initial software vendors create products supporting the young model. Not only adoption rate increases, but also the usefulness is increased during this phase, since it incorporates links to other standards, improves the quality of documentation, etc.
3. Phase 3 – Shism
   Right now the model has reached high acceptance within the relevant communities it seen more and more as a gold mine. Consultants pile upon the term and try to sell anything under its name. Peoples résumés are rewritten indicating they have been implementing the process model for several decades (usually longer than the model is in existance). Software vendors only remotly associated with the process model start selling their tools as the out-of-the-box solution for it. The people that created and have driven the process model up to this point start to turn their attention to new things. And now the shism occurs, the process model is either doomed for stardom and is granted an own ISO standard, or it returns to the crypt of gartners buzz words.
4. Phase 4 – Old Age
   The standards still increase their adoption, but much slower than it did before. New revisions try to expand the scope of the standard in a feeble attempt to gain more market share. This is true for both types of process models, the starred standard as well as the soon to be forgotten one. They both generate less and less benefit to companies embracing them. Some will linger on for quite some time, others will die more quickly.

Does this remind you of something?