ICI Basic Training
Last time I talked about how every part of a project must be uniquely identifiable and explained how the Integrity Control Item (ICI) can be used to perform this task. What I didn't really explain was what an ICI looks like, where it lives, and what it can do other than be unique. While being unique is a full time job for many celebrities, it is not extremely useful on its own. If we are going to go through the trouble of giving something a name, it should do a little more than sitting around being unique to earn it! The ICI does. It should provide some practical and useful information of functionality.
First, let’s talk about the structure of an ICI. The question of "what does an ICI look like?" is comparable to the age-old mystery of "how long is a piece of string?” In the case of the string, it is as long as it is, and in the case of the ICI, it looks like it looks. So much for practical, useful information! The reason for giving this apparently useless description (other than wanting to use the string question) is to drive home the point that the ICI is a concept, not a thing. Like a color, it can be useful but it is hard to pick one up and put it in your pocket (no, that is a crayon you are thinking of...only school kids call them "colors"!). This is because as useful as colors are, they are not things. We can speak of them (I have on my blue shirt today) and use them to convey information (the blue lights in my rear view mirror); colors just cannot exist on their own. Instead, they describe other things that already exist. We can even group things logically by color that have no other common properties (make a list of the blue items you see in the room). In many ways, this is what ICIs do. They provide a convenient way to talk about and manage things that may not be very alike otherwise.
In the software world, as many other disciplines, we say that the ICI functions as an abstraction of the various pieces that make up a project. It gives us a way to perform the same actions on very different things that would otherwise be difficult or impossible. For example, your project may contain a configuration file and a packaged database system. Other than being file-based, these items have very little in common. If they were people they would stand on other sides of the room at parties. But what if the hypothetical people are both huge Dolphins fans? This is a common thing that they have in common that they can both relate to, so while the conversation is on politics, they don't talk. DBMS is a Republican and the configuration file is a Democrat. When the conversation turns to movies, still they have no common ground. DBMS is an action movie fan while CF only likes documentaries. But when the subject turns to football, suddenly they are both interested and you can't get them to shut up. That is until DBMS's wife, Web Server, whispers that he should talk to some people of his own grain for a while...then they again drift off to opposite sides of the room. Pretty dramatic, huh?
The purpose of an ICI is to provide that common ground between all of the different pieces of your project. Like Army soldiers' proclamation of "I'm not black or white, I am green" and the even broader "soldier fist" motto, ICIs ignore the differences between the pieces and leverage the commonalities. No matter what a soldier's job is whether field cook, generator repairman, or helicopter pilot, you can assume several things about him without even knowing him. First, he knows how to fire and field strip an M-16. He knows how to throw a grenade without killing himself, and he will put his life on the line to defend his flag. These are things that are common to everyone who wears the Army uniform. They may have different taste in music, different jobs, different religions, and different political views, but when an officer barks out "attention!” they will all snap to attention in the exact same manner.
In the same way the military trains each of its members with common skills and responsibilities, ICIs define things about any item in a project that can apply to every single one, no matter what it is.
This may sound like some kind of shell game of pretending that things are the same when they aren't, but it isn't at all. The key to understanding how to implement ICIs is to understand that nobody is born with the reflex to snap to attention when an officer yells "Atten-hun!" (Anyone who thinks they yell "ten-hut" has never actually been in the Army). This is an artificial behavior that is introduced in their training to allow leaders to control them as a single unit when needed. Using the techniques collectively know as "drill", a leader can move 1000 soldiers with the same effort it takes to move 10. This is significant because anyone who has ever been in a crowd of 1000 or more people trying to move from one place to another will have the word "mob" in their mind. With so many different people with so many different ideas about how to get from point A to point B, the resulting chaos is typically extremely inefficient. By introducing some artificial behaviors into this crowd, they can be treated as a single unit, moving in step and in perfectly straight columns, turning, stopping and even saluting in perfect order. This is the power of abstracted behaviors.
It is important to note that introducing these standardized behaviors does not in any way diminish the individual's ability to do their job or move about on their own when coordinated movement is not required. The same soldier who marches in perfect synchronization with 999 of his fellow troops can, in the next moment, take up a lone position and effectively protect it without any further orders from his commander. He can even be left at this post for days and will perform his job as required with no further intervention. But when he rejoins his platoon and the "FALL IN!" order is given, he will be just as efficient in moving with the others as he was before. Those who have participated in marching bands will recognize the parallels between ICIs and marching drill as well. Each member has their own part to play (literally), but it takes a common set of drill steps and maneuvers to control the overall musical production.
The purpose of an ICI then is, on an abstract level, the same as the purpose of marching drill. It defines a set of characteristics that can be relied on no matter what the underlying item it represents is. For those familiar with object oriented programming, an ICI could be considered an instance of an IC class. They all have the same structure but represent different distinct items.
Once we have established what the structure of our ICI is, we can then "map" it to any item in our project whether it is hardware, software, documentation, or even other abstract things such as routine maintenance tasks and procedures.
Now that you understand the concept of what an ICI is and how it is used, next time I will talk about how bringing all project under the collective control of ICIs can impressively simplify some of the most complex tasks that face projects as they move through the development, testing and deployment phases. Hope you will join me.
-M@
First, let’s talk about the structure of an ICI. The question of "what does an ICI look like?" is comparable to the age-old mystery of "how long is a piece of string?” In the case of the string, it is as long as it is, and in the case of the ICI, it looks like it looks. So much for practical, useful information! The reason for giving this apparently useless description (other than wanting to use the string question) is to drive home the point that the ICI is a concept, not a thing. Like a color, it can be useful but it is hard to pick one up and put it in your pocket (no, that is a crayon you are thinking of...only school kids call them "colors"!). This is because as useful as colors are, they are not things. We can speak of them (I have on my blue shirt today) and use them to convey information (the blue lights in my rear view mirror); colors just cannot exist on their own. Instead, they describe other things that already exist. We can even group things logically by color that have no other common properties (make a list of the blue items you see in the room). In many ways, this is what ICIs do. They provide a convenient way to talk about and manage things that may not be very alike otherwise.
In the software world, as many other disciplines, we say that the ICI functions as an abstraction of the various pieces that make up a project. It gives us a way to perform the same actions on very different things that would otherwise be difficult or impossible. For example, your project may contain a configuration file and a packaged database system. Other than being file-based, these items have very little in common. If they were people they would stand on other sides of the room at parties. But what if the hypothetical people are both huge Dolphins fans? This is a common thing that they have in common that they can both relate to, so while the conversation is on politics, they don't talk. DBMS is a Republican and the configuration file is a Democrat. When the conversation turns to movies, still they have no common ground. DBMS is an action movie fan while CF only likes documentaries. But when the subject turns to football, suddenly they are both interested and you can't get them to shut up. That is until DBMS's wife, Web Server, whispers that he should talk to some people of his own grain for a while...then they again drift off to opposite sides of the room. Pretty dramatic, huh?
The purpose of an ICI is to provide that common ground between all of the different pieces of your project. Like Army soldiers' proclamation of "I'm not black or white, I am green" and the even broader "soldier fist" motto, ICIs ignore the differences between the pieces and leverage the commonalities. No matter what a soldier's job is whether field cook, generator repairman, or helicopter pilot, you can assume several things about him without even knowing him. First, he knows how to fire and field strip an M-16. He knows how to throw a grenade without killing himself, and he will put his life on the line to defend his flag. These are things that are common to everyone who wears the Army uniform. They may have different taste in music, different jobs, different religions, and different political views, but when an officer barks out "attention!” they will all snap to attention in the exact same manner.
In the same way the military trains each of its members with common skills and responsibilities, ICIs define things about any item in a project that can apply to every single one, no matter what it is.
This may sound like some kind of shell game of pretending that things are the same when they aren't, but it isn't at all. The key to understanding how to implement ICIs is to understand that nobody is born with the reflex to snap to attention when an officer yells "Atten-hun!" (Anyone who thinks they yell "ten-hut" has never actually been in the Army). This is an artificial behavior that is introduced in their training to allow leaders to control them as a single unit when needed. Using the techniques collectively know as "drill", a leader can move 1000 soldiers with the same effort it takes to move 10. This is significant because anyone who has ever been in a crowd of 1000 or more people trying to move from one place to another will have the word "mob" in their mind. With so many different people with so many different ideas about how to get from point A to point B, the resulting chaos is typically extremely inefficient. By introducing some artificial behaviors into this crowd, they can be treated as a single unit, moving in step and in perfectly straight columns, turning, stopping and even saluting in perfect order. This is the power of abstracted behaviors.
It is important to note that introducing these standardized behaviors does not in any way diminish the individual's ability to do their job or move about on their own when coordinated movement is not required. The same soldier who marches in perfect synchronization with 999 of his fellow troops can, in the next moment, take up a lone position and effectively protect it without any further orders from his commander. He can even be left at this post for days and will perform his job as required with no further intervention. But when he rejoins his platoon and the "FALL IN!" order is given, he will be just as efficient in moving with the others as he was before. Those who have participated in marching bands will recognize the parallels between ICIs and marching drill as well. Each member has their own part to play (literally), but it takes a common set of drill steps and maneuvers to control the overall musical production.
The purpose of an ICI then is, on an abstract level, the same as the purpose of marching drill. It defines a set of characteristics that can be relied on no matter what the underlying item it represents is. For those familiar with object oriented programming, an ICI could be considered an instance of an IC class. They all have the same structure but represent different distinct items.
Once we have established what the structure of our ICI is, we can then "map" it to any item in our project whether it is hardware, software, documentation, or even other abstract things such as routine maintenance tasks and procedures.
Now that you understand the concept of what an ICI is and how it is used, next time I will talk about how bringing all project under the collective control of ICIs can impressively simplify some of the most complex tasks that face projects as they move through the development, testing and deployment phases. Hope you will join me.
-M@
[0] Comments:
Post a Comment
<< Home