From 3DN

<google uid="C04" position="none"></google>

Contents 1 CMWiz Introduction 1.1 A Configuration Item 1.2 Business Rules 1.3 Generic CMWiz Object 1.4 Software as a Service 2 Detail Design

CMWiz Introduction

Being the sometimes rather obnoxious person that I usually am, I have an opinion on just about everything. Being the contrarian that I usually am, my opinions often differ from most other opinions. Some say that's a useful character flaw, I personally think it's rather tiring.

Either way, [CMWiz] is an application I will be re-engineering from an old application I have made a long time ago which was intended to monitor a lot of machines I used to manage as a systems administrator at [Amgen's Research Dept.]. As a lot of things in computer science aren't really rocket science as far as I'm concerned, naturally when monitoring a whole range of systems one would try to keep track of which systems to monitor in some sort of database. When those systems are already in a database, what kind of genius does it take to consider that we could more inside this database than just the monitoring aspects of those system? Indeed, not a great genius, remember those words.

However, since a lot of computer consultants appear to enjoy pumping themselves up a bit, keeping track of all sorts of information is also called 'Configuration Management' or 'CM' for short. Configuration Management is a 'discipline' as some would like to call it, of keeping track of all systems you have within an organisation and keeping track of what's in them. As far as I'm concerned the old Greeks probably knew how to keep track of their belongings and what their belongings looked like, so really... 'Configuration Management'? 'Discipline'? I call it common sense.

Since my client at the time blessed me with the noble task of updating all the patch levels on their Sun Solaris systems, I started making some database tables with the patch numbers and versions of those patch numbers installed on each system. All of the sudden I moved into the scary area of, what I later found out, Software Configuration Management or SCM! Whole flocks of overpaid consultants specialize in this and even get little pins on their chest saying they're [ITIL certified], I kid you not, and Software Configuration Management may be even a far bigger thing that good old Configuration Management.

As you guessed from my tone of voice, and the initial paragraph of this introduction, I feel that people certifying themselves with the ability to use simple logic aren't all that logical to begin with. What's so special about the software inside the box other than that it's a plain simple characteristic of the box? Why do we bother distinguishing between 'Software Configuration Management' and 'Configuration Management' when there should be no such distinction? When we describe a simple mechanical clock and call ourselves 'Clock Configuration Managers', will there also emerge a group of people calling themselves the 'Clock Arm Configuration Managers' and pretend that they've just reinvented the clock? I don't think so.

So CMWiz aims to do configuration management but we will break away from ITIL nonsense. A box is just a box. In the box there may be separately identifiable hardware bits, and there may be separately identifiable software bits. These bits and the box itself may have a version number and another hocus pocus ITIL 'discipline' called 'Change Management' attached to it. It's still just a box and CMWiz will describe the box.

"Ah", I hear you say. "Another Configuration Management tool, hence the CM in the name". Indeed, but with an important twist to it. It appears to me that for some reason a large chunk of the IT people (maybe it can be blamed on me working for large companies and Government outfits) have started treating IT as 'an electronic way to continue what we've been doing forever, manual labor to fill in forms and keep track of things'. I'm not sure whether this is caused by the afore mentioned fact that I have worked for some very large companies and that those tend to be set in their ways or if it is because more and more people keep flocking into the IT business and are starting to dominate the way of thinking in the IT business. Certainly, creating MORE work by using computers was not what I once signed up for, I want the computers to do the work for me.

With CMWiz I intend to make the Configuration Management process more automated, smarter.

A Configuration Item

From where I'm standing, a configuration item (CI) is simply a thing, an object, whether I can touch it such as a piece of hardware, or intangible like a piece of software. Every object can obviously have somewhat different attributes. A box full of hardware may have a color if you'd like to record that piece of information, while attributing a color to a piece of software would be extremely silly. Still the piece of software and the box full of hardware are both just objects or CI's, correct? And the only thing we've so far distinguished them by is simply their name, 'piece of software' and 'box full of hardware'. So why not use that and for CMWiz define a Configuration Item to be 'a thing that has a unique name and type'? This should keep maintaining a potentially HUGE database of things nice and tidy, we can use the unique name of the thing as an index into our list of things and later on we can use the type to determine what attributes this type should have.

"But...", the certified configuration managers say, "the thing has much much more to it! It has an owner, it has a partnumber, it has... it has...". Hold your horses there okay? Those are all just attributes, we could add them later on. Some of the attributes may apply to all CI's, some may be specific, but they're all just attributes. See where I'm going with this? It's intentional that I use 'objects' and 'CI' interchangably because we're not talking some weird overpaid ITIL discipline here anymore, we're just talking Object Oriented Programming here (even though some might argue that that's an overrated paradigm as well).

Business Rules

'Business rules' is used for lots of different things but in the context of CMWiz I would like to define it as a rule that applies to CI's and the relations between those CI's. Often businesses have such internal rules like 'every applications (CI!) should have at least one application manager (CI)'. While such rules are often in place they're not always very clearly followed, or so I've noticed in the past. It has often puzzled me why such 'business rules' or 'policies' exist but aren't frequently enforced. I've never been a sr. manager so the chance exists that I'm missing some information to the puzzle.

Generic CMWiz Object

A lot of functions in the CMWiz CI's, Relations, Businessrules etc. classes will be very much the same. Therefore we will implement these functions in a baseclass.

Software as a Service

Another fundamental thing to consider when designing software is who is going to use the software. As the earlier described large and often slow companies are not likely to go crazy about the ideas in this design, they will not (at first) be the primary focus of CMWiz. 3DN would like to create a low-entry Configuration Management service for mostly small companies.

Smaller companies often want to do some form of Configuration Management but the typical solutions are often rather expensive while the available opensource solutions are not always easy to set up for these smaller companies. Configuration Management doesn't even neccesarily just apply to businesses, what to think of having a well-described inventory of your home for insurance purposes?

I believe that software as a service is a great concept. Basically, I'll be developping a web service which can be accessed from a web server but also through (both) a web API and a command-line API. These API's will connect to the webservice and depending on what service you request, or how frequently you access the service you may be charged. In most cases we'll use a very lenient payment model and in reality a lot of small users will be using the webservice for free. This is a way of 'paying it forward', I'll help you and don't expect anything in return as long as you promise me to help somebody else when they need your help. Things eventually have a way of getting back to you.

Larger users, and with that I mean users that use the webservice rather intensely, must really like the service a lot. I'll ask them to pay some money, often based on a 'per service request'. The more interesting situation for 3DN is when a large users decides that their business is starting to rely on CMWiz more than they feel comfortable with. Such an observation may result in this user wanting to have their own copy of CMWiz or a dedicated CMWiz machine managed by 3DN.

Detail Design

In the following chapters we'll more thoroughly and in more detail design the above entities, Objects, CI's, relations and business rules.