To componentise or not ?
I have long postulated over componentisation (generally and within Gen) – I speak to people who evangelise about components and how they are a good thing, increasing productivity, flexibility and getting reuse out of your application assets in a controlled fashion.
I haven’t been particularly “into” components and CBD, preferring the traditional approach of utilising common code, as opposed to components.
One of the things that has always put me off investigating componentisation in more detail is that there seemed to be more management of “bits of stuff” required than “traditional” development. You had to have different models, specifications and implementations etc. whereas just a common action block would do, so, in my opinion, the amount of effort required to manage those “bits of stuff” outweighed the benefits of componentisation (rightly or wrongly!).
I therefore was surprised that I took a fresh look at componentisation – at CA World a couple of weeks ago, in the context of a workshop with IET and their new GuardIEn 8.0 product – when I wasn’t expecting to.
As a long-time GuardIEn user, I was aware of the fact that in a large-scale Gen site, you can’t do without it for model and configuration management, but stretch that a little further and get it to manage your “bits of stuff” in the CBD world. So – now the amount of effort required on the configuration management side of things is reduced/eliminated then the benefits of a component-based approach become more tangible.
I am glad you are on the road to enlightenment! As you correctly state – if you do componentisation strictly following the standards, then there is some “unnecessary” objects that need to be managed. Jumar’s experience of componentisation projects is that pragmatism wins out and only required objects should be created. Indeed GuardIEn has not only made the management of CBD easier, it has also made tasks involved in the conversion from traditional systems to CBD a whole lot more efficient.