Building Components of the Right Scale

So in the last post we discussed using RTC for C/C++ Development.  With such a broad topic it’s not surprising that there is some lack in details.  We will attempt to hit some of these topics going forward.  While not always with explicit answer, but in many cases some reasonable advice based on practical application.  I’m all for discussions, so if there are dissenting points of view or items of curiosity just ping me directly, or add a comment.

What I find most compelling to discuss next is something that appears on the surface obvious but in reality it can become quite complex.  Quite simply the question is… when do I make an RTC Component and what does this component represent?  It seems obvious, if not trivial, but let’s take a moment on why I think this is both a critical, as well as non-trivial, exploratory for any organization adopting RTC for development.

So first, intuitively what do we think of as a component?  Working with many organizations, it is quickly realized that has domain specific connotations.  If I’m talking with an IT delivered entity components have scale, a known value, and when reused they are reused as a whole.  When I talk to embedded manufacturers the typical answer is along the dimensions of a known value, reused as a whole, and capturing variations (often hardware dependencies).  So what is common?  A component has a known value, has potential reusable entity, and (implied in both) has known dimension (size, interface, etc).  Seems pretty fair and not overly different, so what is the problem?  In the whole the major difference appears in scale.  While there are tremendous similarities, the expected scale of components in a typical embedded system is actually quite small.  And yet on a product basis the number of components of these systems are often significantly larger than their IT and consumer electronic counterparts.  The result of this is that their products (for example an automobile) have enormous numbers of components (in the order of thousands!).  And so while at first glance one would typically relate an RTC component to the domain definition of a component, I greatly recommend pausing for a moment and consider some other perspectives before you make that immediate leap.

The quickest way to get there is to shift gears a bit and discuss the concept of an RTC Component.  Before you get the wrong idea, I believe the RTC Component definition is great, just might not be a direct match the component definition your domain typically uses.  The simplest definition that I have been able to develop (thru usage, rather than formalism) is that the RTC Component captures a collection of file objects that must be managed as a set which represent a known value.   Doesn’t clear a whole bunch up does it?  Well consider this …. a RTC Component is the finest file set granularity that you can recreate.  That is a bit closer to a valuable definition.  So in practice RTC says that I only can formally label a component instance (identify specific versions of files and their specific versions as a retrievable set) than suddenly this has a slightly different flavor.  So this is a deliverable entity from the development organization at a specific moment in time rather than a purely technical artifact.  And in this regard it makes great sense.  Software organizations have deliverables, known value points (content and timing), which are delivered as sets of artifacts from teams with known attributes (quality, interface consistency …).  This is really what I believe and have experienced the RTC Components being good at conveying.

Okay so after that tangent, how does this relate to the domain definition of component?  And better yet your RTC usage in (C/C++, System, Java, …) development?  Actually we can bring this together quite cleanly and outline some rules (simple and logical) on how this is conveyed to an installation.  First, consider RTC Components as the macro elements.  These define team deliverable sets and the opportunity to label instances of these deliverables.  Second, we have the technical dimensions of software development that embody themselves as libraries, executables, or other domain appropriate definitions.  Fortunately for many domains these organizational structures and technical structures are exactly the same and in that case it is quite simply that one-to-one relationship.  For the rest of us however, consider the following….

At the abstract level we can consider the team deliverable and technical assets as a simple containment.  In a one-to-many form, an organizational component owns a set of domain component artifacts.  In the sense that for every deliverable of a team there are a set of artifacts that the team can enumerate out of those coherent sets.  The simplest example would be a set of interfaces and a specific set of variant components that implement those interfaces.  While as technical artifacts they clearly identifiable on their own, the team will typically only release and validate sets to manage the complexity of the compositions.

So now we have the simple relationship that an RTC Component contains a coherent set of technical artifacts delivered from a team.  Now naturally there is argument on how these should be versioned separately (and I think I’ve personally made them before 😉 ), but that is not the main point.  The main point is that it is impractical to do so (simply go to the Eclipse IDE and open a stream with 250 components and you will quickly see my point).  The practical alternative is to utilize decomposition within a RTC component to achieve the same purpose.  As an example, if within an RTC Component you fracture each of these technical components into separate Eclipse projects you increase the granularity without the clutter in the SCM system.  You also empower developers to selectively load from components, so that’s a bonus as well.  And the best part in my mind; it is simple!  Teams can get off and running quickly with little overhead.

So what is the bad part?  The major item is the loss of granularity in the baselining.  Your RTC components will appear large in the sets that you version and capture.  However, I find becomes an argument in principle rather than point.  While you can never regain the granularity, you can always perform component baseline compares and see the granularity.  Also in practice it is not always best to have all possible combinations but rather all likely combinations which is usually as significant subset.  The other practical point is it has been significantly easier to add RTC Components to a project than to merge them.   From a deployment standpoint, start with a few and grow rather than create all possibilities and later trim down.

And so why did we need to talk about this?  Well in software we are all about “building” (compiling) and when talking about development it is really difficult to talk about what I’m building until I can describe and organize the pieces and parts.  I always want to be able to recreate my builds so getting to the details of how I version sets is required.  And quite I simply, I want to keep good teams from stepping in bad pot holes with new tools.  It often feels comfortable to build everything you might need at the beginning, but often the best answer is to keep it simply but know how you could scale it.  So now we understand the role of RTC Components as the team deliverable mechanism and the usage of Eclipse projects to provide technical granularity within the team deliverable.  Such a simple solution!  It’s a standard pattern of keeping it simple and knowing how to scale!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: