Now that Germany has a new Government which is not composed of the two larger blocks (CDU & SPD), I would have hoped for an increase in momentum of political progress. unfortunately Chancellor Merkel and Vice Westerwelle continue their old faults in believing their voters to be extremely dumb.

They have a firm majority and have a strong backing for implementing change due to the current economical downturn and what do they do? They promise to reduce tax rates in the believe that the increases in debt will be paid back by increased incomes which would increase total tax turnout. All real estimations on this effect will tell you, that it will not return the full 100%, but will basically stop at approx. 60% of the loss. So we happily increase our national debt, which has just been hit extremely hard by the financial crisis. And for what? For reducing taxes, which is not at the heart of our problems.

So what would my proposal be? Boost productivity by setting hard to reach missions that a whole country (of even a continent) could rally behind. The current innovations (internet, eco-tech, bio-tech and nano-tech) should allow a country like Germany to produce a turnaround. One of the projects to improve on would be about money. Why do we still have these small printed papers (easily reproduced by modern technology) and strange round pieces of metal? These are too hard to transfer, keeping transaction costs way to high.

So Germany (along with the european economic and monetary union) should create the e-Euro. The e-Euro (e€) should allow the following:

• Quick transaction with marginal transaction costs (less than 1%) for businesses
• No base fee for transactions, enabling small transactions (transfer 2 cents would cost no more than 0,02 cents)
• Free transaction between individuals (when I give you a 10 € bill, there are no transaction costs)
• Allowing anonymous online transactions up to a defined limit (a limit will be necessary for law enforcement requirements, cashing large sums at a bank will also trigger inquiries these days).
• Make sure that the required infrastructure is in the hands of the european central bank (normal banks should not control cash, nor should they be able to track its usage)

The provision of a monetary system is one of the core tasks of a country. So it should provide a modern version of it. If micro payments can be made affordable, many new business models become viable. For example you would allow news to again become a paid for resource. News right now is expected to be available for free, along with some advertising. Many of us would pay a small fee for more in-depth news, either per article (1 article = 5 cent) or per time frame (e.g. 1 hour = 50 cent). With all current payment models available, this is not a suitable payment option due to the high transaction costs.

The ask a question sites could be a source of income for people, when a small sum could be paid for a proper answer to a question. Bands would be able to host their own music download website if you could easily transfer money to them. Charities would not have to rely on an overly expensive, un-democratic and often unfair payment system (like paypal) but could accept money directly from their donators.

My mission will probably not generate the same passion as

I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the Moon and returning him back safely to the earth.

did, but maybe it could jumpstart our society into a more productive and innovative culture.

aRTessen auction flyer

From every piece of art you buy, we donate 50% to the project, so join us on November 22nd and get yourself some interesting art! More information at http://www.aRTessen.de (sorry, only in German).

Do you know the following type of issue? When a process receives broken input it usually produces a broken output. But one of the most commonly observed approaches is to require the process to fix it’s output, even if it’s input continues to be invalid.

Some call this the “shit-in-shit-out” principle, but I try to explain this a little bit differently:

When the gas stations started selling petrol (gas) and diesel they found out that many people put diesel into their petrol / gas cars. This ruins your car and requires the engine to be cleaned. So there were two solutions available:

• Make the hoses in different sizes, so that you can not fill diesel into a petrol car or
• setup a “diesel-removal-station” immediatly behind the pump.

What would your choice be?

One of the most important things in changeing peoples work environment is to get the people that are affected to be the people that are involved. Some people just don’t grasp the difference. This is where I usually use the following metaphore:

Most people tend to remember the difference from that point on.

I know the story is used by many people (e.g. http://en.wikipedia.org/wiki/The_Chicken_and_the_Pig) but I swear I developed it independantly and I have never heard of scrum before.

The party model is a method of generalization of relational data modelling (not explicitly named, but some information found here http://en.wikipedia.org/wiki/Generic_data_model#Generic_patterns). It defines a generic table (or object) called PARTY, which represents all types of persons, organizations, employees, regions and so on as well as a relationship table, which defines the relations between these parties. Sound familiar?

Relationships can be typed, the involved parties are typed, relationships may form hierarchies and other interesting things. If you replace PARTY with CI you have almost half of a CMDB. Is anyone knowledgeable about the party datamodel? Let’s discuss using this as a base for a “better CMDB”.

In my recent consulting works, I found out that quite a few people working on ITIL® process definitions are not sure how to proceed with their definitions. Especially after they have defined (or copied) a rough process diagram along with some responsible roles they are unsure how to continue.

I recommend using the following 10 steps to get to a defined process.

1. Identify the main stake holders
   Find out who sponsors your process, who should participate, who triggers it and who benefits from the results. Also identify the main supporters and your main opposition. Make sure you select the opinion leaders of the participating teams.
2. Define and agree the goals, high level roles and basic rules of the process
   Do this with the most important stake holders. Make sure your goals are exact, measurable and complete and that your rules are simple, verifiable and realistic. Remember the rules are subject to change based on your further findings. Name the most important contributor’s roles for the process.
3. Define the main process activities or phases
   If you are redesigning an existing process, take the view of the current process participants into account. Also use frameworks and other information to define your basic process steps. Do not overcomplicate things and stay away from complete process diagrams (incl. events, decisions and other things). Best is to use a simple tool like powerpoint to represent the flow.
4. Define the target and roles (RACI) of each of the phases
   Focus on responsible and accountable roles and make sure that you can define the real target for each step. Again let targets be exact, measurable and complete. The summary of all individual targets should result in the overall process goals.
5. Detail the individual steps back to front
   Start with the last step of your process and talk to the people targeted for the responsible & accountable roles. Define the output, input and trigger(s) of the step, add required consulted or informed roles and, if necessary, detail the step into subtasks. These subtasks are modeled in greater detail as the containing process. Build a list of required inputs while travelling backwards through the process. Try to match the required inputs with the outputs a step can (or should) provide.
6. Repeat the steps 4 & 5 for the detailed subtasks
   All your subtasks have to be detailed and defined based on responsibility, input, output and trigger. If needed you can add another layer of detail beneath this and continue the detailing process until all tasks/activities or steps are defined.
7. Match remaining input requirements with sources outside of your process and define interfaces to them
   All required input has to be provided from somewhere. So either the inputs are provided by the overall process trigger or other processes provide the required information. In that case you need to define an interface and agree on the method of delivery.
8. Produce an information model
   Based on the input & output information define your information or data model. Combine individual information requirements into the fitting objects and document them. This will be the basis for the realization of a process flow within a tool.
9. Combine the detailed subtasks into a complete process chart along with the inputs and outputs
   Include the original activities as phases within the detailed process flow chart. This helps to identify where each detail activity is located and improves the overall overview.
10. Review, finalize and agree with all participants
    Take your process documentation and your information model and discuss this with all participants. For each role prepare RACI chart based on the information gathered in the previous steps.

The most important advice is to work your way up from the end of your process. This ensures that you focus on your deliverables and do not have to ask the people “What do you do in the step x?” but you may say “What do you need to do and know to produce this output?”.

During all the steps you should communicate openly through your enterprise and align your findings with tools used to realize your process. These steps help you to achieve an implemented and accepted process.

Well, I’ve done it. I have bridged my v2 service manager qualification to the new ITIL(r) v3 Expert. Besides the not appropriate name this still feels as a downgrade, though. For my service manager certificate I sat down for 5 hours and wrote 16 pages worth of IT service management know-how (which still hurt my fingers more than my brain). Now all I had to do was answer 20 multiple choice questions (only one answer is correct) and get 16 of them right.

But it was not easy, because of the way the questions were defined. I doubt that I can find the right answer for the 4 questions I failed on, even using all the material available. 

Additionally the german exam had one error. All the answers had to be marked on a seperate paper showing A, B, C & D as possible answers. One of the questions did not have A-D but 1-4 as answers. This whould have been not a big deal (not such hard code to break) if there weren’t other questions where the initial 4 point numbered 1-4 where then combined into groups in the answer (e.g. A – 1&2 are correct, B – 2-4 are correct, C – all are correct, D – none). This left some ambiguity.

All in all, the world has another “Expert”

You can now also follow me on twitter, if you prefer doing so.

Follow me!

I have been following the Iranian election and its aftermath since Saturday and I suggest everybody to keep an eye on twitter  #IranElection. Previously governments controlled what comes out of a crisis situation (they even perfected it during the invasion of Iraq with embedded journalists), but now we can see what an open communication platform can do.

I hope sincerly that the people of Iran will find a good end to the current unrest. When that comes we all have to start thinking about what more we can do to give this power of communication to all people in the world.

When reading ITILversion 2 you could clearly see software distribution stamped across the whole release management process. Version 3 release management aims to be more than that. Its purpose seems to have grown to be the transition motor. But in my opinion, the release management process is still a mixture of sound project management (ITIL v3 is extremely ignorant on project management interfaces), the software release cycle and deployment and some management of change (not change management). If you thumb through the ITIL v3 documentation you will not find a precise goal of release (and deployment) management.

The ISO 20000 specification contains a short summary of the objective of release management:

Objective: To deliver, distribute and track one or more changes in a release into the live environment.

The emphasis is added by me. The version with the phrase “in a release” comes from the part 1 of the specification, while part 2 (the code of practice) contains the objective without the word release.

A while ago I had some high hopes on the then still forthcoming ITIL v3 release management. They were not fulfilled as I would have like it to be. So I will try to define what I would like to see in release management.

Goal of Release Management

Release management coordinates and verifies the introduction of new or updated items into the live IT environment. It controls the roll-out of these items starting from build and/or acquisition to hand over to production.

Proper release management controls the variety of items used in your IT environment.

In my opinion, everything that has not been used in your IT environment should undergo the release management process. The exact scope of this of course depends on your own risk and security requirements. For some organisations a minor patch to an application needs to be regarded in full detail, others will be happy when every major software version is under control. The same is true for services and hardware (e.g. a new server model versus a new hard disk size/version).

The Principles of Release Management

1. Define release units & scope

   What is the contents of each individual release? Define this in cooperation with your service catalog/portfolio and service level management. Define release units for your services and also for your internal environment.

2. Define your release policy

   Define one general release policy, which is flexible enough to handle the different rate of change vs. stability requirements your organisation needs. Then define the release policy for each individual release unit. Never assume there is only one type of release policy requirement for all release units.

   A too strict a policy

   I remember one organisation that applied a single policy one release management, which contained 2 major releases each year, no minor releases and individually created patches without timing restrictions. This was OK for their central services, but it wrought havoc with all the other services and internal environments. This resulted in an enormous flood of individual patches that were not implemented in releases. Release management was having a negative impact on the quality of building and implementing changes.

3. Define release and deployment models

   Not every release unit can be deployed using the same plan and methods. Define models that allow a customizationof the way your deployment works. Many people think of deployment as a software roll-out. Deployment can also be the roll-out of upgraded hardware. If you have defined for example a “Basic Midrange Windows Server”, you may upgrade the hardware platform at a given point in time. All new “Basic Midrange Windows Servers” will receive the new hardware and existing servers will be upgraded according to the release policy, which should be based upon your hardware refresh agreement or plans.

4. Align release management with IT architecture management

   If release management is the gate through which all new things have to go, it is the most important interface for your IT architects.

5. Release management defines CI models in the CMDB

   In a good CMDB (maybe SKMS?) you have a model for each CI. This model defines what the CI is and contains all the general information that is common amongst all the instances of this model. This data needs to come from the release management process.

6. Define your project management interface

   In many IT shops every larger modification of the current status is a project. I do envision a time when the number of projects will decrease, because many of the modifications will be handled in processes. But this a far future. In the mean time you have to make sure that projects will not bypass your release management process.

Make sure your goal and principles for release management are well understood. It is far too easy to confuse change- and release management and it is your task make the distinction clear. The most common distinction unfortunately is a bad one. Release is often driven by the development side, while change management is driven by the production side. That should not be the case. Both are driven by transition side!

Activities of Release Management

It is quite hard to find the official trigger for release management to start in the ITIL(r) documentation. I would propose that every time a change is requested that includes an up to now unknown object (unavailable piece of software, new service requirement, new hardware type, etc.) release management is triggered. Additionally the deployment activities may be triggered for known items, if there is a new deployment need (e.g. new location to be setup).

1. Release Planning
   Define your parameters for your upcoming release. Make sure you define the most important of the magic triangle (time – completeness – budget) at this stage. If you target a dedicated date for final roll-out, you may be more variable on the exact content of your release or your budget will be flexible (usually not the preferred option). The release management planing activity is covering the same grounds as most project management methods do on planning a release project. So my advice is to leverage what you have and integrate release into project management standards, if available. Remember to include requirement engineering, build/acquisition, test (and test design), training, pilot, deployment and financial management criteria in your plans.
2. Preparation of Build & Test
   The new or updated service design (service design package, SDP) should be made available. This is the task of service design, but release management has to wait for them to complete. This is also the place where transition-, release- and deployment criteria should be added to the service design at latest. This step should include defining the CI types and models your new release will be made from within the configuration management system.
3. Build & Test
   Build your release package and start testing against the v-model (every level of design of a service has corresponding tests assigned, highest level is designed first but tested last, lowest level designed last, tested first). Make sure to also test your deployment process as realistically as possible. As an example, if you expect to update software at the client level, try to update in a normal office network, not an empty dedicated testing network. If the current release is a self developed application, make sure to have separate teams in place to do development, build and testing.
4. Plan & Prepare Deployment
   Some may notice that I list this activity earlier as in the ITIL(r) v3 books. This is because a pilot to be also a pilot for your deployment and this requires you to have plans in place when your pilot should start. This
5. Service Testing & Pilot
   Often seen as the highest version of the tests. Here you have to make sure that you can meet your service value, so you test for utility (the previous phase tests functionality, which is slightly different) and for warranty. You should test your serviceability here as well. Try to open an incident at the service desk, request some service requests and recover your service from disaster.
6. Transfer, Deployment, Go Live & Phase Out
   This is where your service enters the big stage. It is very hard to do this right and the failure usually originates from earlier activities. Make sure you do all the required steps right and still be prepared for the unexpected. If you big-bang your service, make sure you have all resources at hand to make it work. If you prefer a phased approach, make sure you cover all the little issues that appear when two different services compete for the same business situation. Make sure the business done within the old and the new service are either completely separate or prepare for interfaces. If you replace an existing service (system, software, whatever) remember to phase out the old versions. Your users may like to cling to the environment the had before and finding out that the old version is used more than the new service after your roll-out is a little embarrassing.
7. Verification
   Make sure your service does what is supposed to be doing. In a big-bang situation with a migration on weekends (quite common) make sure that you have the business within your migration / deployment team to do the final acceptance test and sign off. There may still be things the business does that you are not aware off.
8. Early Life Support
   Make sure that you can handle the added support requirements that any new or drastically changed service will generate. Work together with Service Desk, Incident-, Problem and Change Management to handle the additional load. Interface with Service Level Management to get feedback in early in the life-cycle to see if you are meeting your targets. Basically: Show responsibility.
9. Hand Over
   I added this step as a separate one. It is the milestone in your plan showing that now the full responsibility of production is with the production teams. Do this for every release and have the production team verify that they have the information they need. The service is described, the configuration is registered, event management settings and thresholds are OK, operating procedures are defined, new processes or activities are in place, new categories for incident and problem management are registered within the tools, known errors are forwarded to problem management, new standard change models are available, the service request types are not only described but realized in the proper tool and tested. Warning: This list is not exhaustive.
10. Review and Closure
    As always, check what you have done and learn from it. Formally get acceptance from your client, customers and/or users. In large transitions postpone this to occur after the first service review meeting. Forward findings to your improvement programs (SIP / CSI) or create problem records for the more mundane things.

As stated in the Planning activity, many companies handle the deployment of a new release (of anything) as a project, sometimes as part of the project that produces a new service, sometimes as a seperate one. Try not to reinvent the weel when you are working in such a company. Reuse what you have and cooperate with development procedure owners and project management offices.

Some additional not process orientated activities of release management are:

• Release Policy MaintenanceMake sure your policies fit your requirements. Review them, discuss them with the business and improve.
• Define Release ModelsAs with the other processes, release management can benefit hugely from previous experience. The definition of a project is that it is supposed to be a new endeavour to be undertaken. Luckily in processes we may do something we have done before. What the project template is to project managers, the process model is to process managers. Try to define standards, checklists and job lists required for dedicated types or groups of releases / transitions.
• NamingA big thing in ITIL(r) certification, but to most just one of the things you have to do. Make sure to be consistent.

Attributes of a Release

For release management I can not provide all the required data fields you should record. This is partially due to the difference in size that release management targets. The release and deployment of a new version of WinZIP will require less information than replacing the core transaction system of an international bank with a new in-house developed solution. Make sure that you record the data the steps require in one place and try to integrate with CMS and the Change Management System. Do not expect your software distribution system to hold your primary data on release management, nor solely rely on your project management environment.

Try to reference all requirements, grouped changes, tests, service levels, CIs and CI Models / Types from your release. If possible record the baseline assumptions of your deployment.

Conclusion

My prior blog posts on release management received the most traffic from search engines. That showed me the huge interest in proper release management. Unfortunatly it is still a common topic of misunderstanding and there is no widely accepted school of release mamagement, since ITIL(r) by itself has too many shortcomings (even though my activities are based upon ITIL(r) v3).

Proper release management brings the benefit of doing complex things right the first time and guards you from failed service releases and helps you to handle the issues that will inevitably arise (issues like Nokias OVI Store rollout).