Mittwoch, 6. August 2008
Do you control what you own?
In the past I have written about some litmus tests of software configuration management. Here is another one.

Does the owner of your application know where the source is stored in the configuration management system? If he knows it, how can he get access to the source without asking anybody from the development team for help?

If you have answered both questions with yes.

Five to ten years ago most companies would have succeeded in this simple test. Nowadays quite a lot fail. This has a simple reason in the increasing number of outsourcing. Development is nowadays outsourced. The discussion, if outsourcing is good or bad, is interesting, but it does not really matter as it is often reality nowadays.
You, pay good money for the hopefully good software which you get in return. You own it. You should manage it similar to all the other assets which you own. As a comparison, I expect your company knows where each of it company cars is. (And cars are normally cheaper than good software).

Why the second question? The owner of the application may want to be able to do an external review, fire or terminate the existing outsourcing contract. Or the outsourcing partner does go out of business for some reason. There are many other reasons why there might arise a need to get access (at least reading) to the owned sources.
In any case he should be able to access his own property.

... link (0 Kommentare)   ... comment

Sonntag, 3. August 2008
eclipse plugin for protocol buffers
Google has released recently the nice api protocolbuffer to the opensource community. (See It is an interesting alternative to XML, if you need an evolvable API, which is more efficient than XML.

My favourite development environment eclipse did not have syntax highlighting for this interesting tool.
So I decided to hack a simple eclipse plugin, which does provide syntax highlighting for this interesting API. I went out today with my laptop to a local music festival here in Hersbruck, the so called Altstadtfest, sat down in front of one music band and hacked the editor. I decided to release the editor with an Lesser Gnu public license.
You can install the editor from the eclipse update site:

If you find this software useful, please let me know at arno.Schmidmeier at senacor dot com. Please do so also, if you found some bugs. If there is enough interest I will host the software on traditional opensource site.

... link (2 Kommentare)   ... comment

Dienstag, 29. April 2008
Missing artefacts in Configuration Management
If you want to apply configuration management, you should put everything under configuration control, what is responsible for the behaviour for the application. The only exception is system configuration data, which you have to change during the staging. Typical examples are hostnames, tcp/ip-addresses, user accounts and passwords.

All other files should be in configuration management and picked up during the build.

So let’s define a second litmus test:

For every application which you own, build and deploy it from the sources which you have got from the configuration systems. The deployment system is the naked target platform, e.g. Some Unix Servers, with a clean new installation of your application server, an empty and clean Oracle database, with the correct set of patchlevels, …

If you need to copy files from somewhere else.
If you have to export some files from some system, and then “modify” it and deploy it.
If you have to export/create/generate one or more files from some very fancy tool, with a very graphical GUI, whose import is not completely under configuration control. Succeeded:
If all you need to deploy the application with a standard process is in the configuration management system. The only exceptions are some updates of configurations settings which do only depend on the environment, (e.g. user accounts passwords, hostnames, etc.)

Most companies (seven out of eight on my personal experience) fail with this more advanced but still “simple” test.

But why and where do they fail? I recognized following major reasons why and where they fail:

  • They have forgotten to put some important artefacts under configuration mangement, e.g. Database schema scripts or application server configuration and customisations.
  • They use something like a workflow engine, a process engine, a business rule engine or any other nice and fancy tool, which is used by “business analysts” to design a workflow or orchestrate some business process or define some business rules.
In the first case, the solution is quite easy and straight forward. Just put the missing elements under configuration management.

The second case is much more critical, because it is based on the WRONG assumption:

Designing a workflow or orchestrating some business processes or defining some business rules is not developing.

The truth is: The business analyst is developing. Period. He is just developing in a kind of DSL (Domain Specific Language), but he is developing. If he makes a mistake, the system has a bug. The process, workflow or business rule will fail or produce wrong results similarly to other buggy development artefacts.
So put also these artefacts under configuration management.

... link (0 Kommentare)   ... comment

The litmus tests of Software Configuration Management
I do a lot of consulting about software development in general and especially about aspect oriented development. I see there a lot of companies, who own some applications. Most of them fail to have the basic software configuration procedures in place. Some fail, because they do not care. But fortunately most care and spend a lot of time and money on software configuration management. But what do they get back? Seven out of eight companies get nothing back, their configuration management system is at most a “developers collaboration tool”, but it should and could be much more.
Why didn’t they get back more? Because they did never any test of their configuration management.

In the next days I like to outline some very simple tests, which anybody can easily perform if you spend your money wise and you have something like a working configuration management system in place. I call these tests litmus tests, because you get an immediate feedback if they work or if they do not work.
So let’s start with the first and the most basic one.

For every application which you own, get the source for the systems as they are in production as fast as possible.
If you need more than one hour for each system you fail. (Assumption, you have a really slow configuration management system)
If the sources do compile and you can install them on the production system.
Two out of three companies fail with this basic test.

More tests coming up, in the near future.

... link (0 Kommentare)   ... comment