Component, Component, Component: Everyone says it, few actually “get it”

Can we really get to true plug and play with software?

Every now and then a great technical concept unfolds, everyone starts talking about it, and all of the vendors start defining their own software by it.  This has happened to SOA (related to this topic, but we’ll cover that on a different day), rules-based configuration-driven software (also for another day), and componentized systems.

The vendors hype up the terms and all talk about them as if they’re all really doing it, and it waters down the concept to the point where the true meaning and actual benefits get lost.  It makes it very difficult for the vendors who actually do meet the objectives to differentiate themselves and, makes it difficult for the customers to truly understand the landscape.

The idea of components (“componentization”, “software components”, “componentized software”) is certainly not new, but is one of those concepts that has been watered down.  I was at a conference a couple weeks ago and heard Stacey Cheese, from Edgewater, lead a panel about componentized software and how it can help insurance companies in so many ways.  He did a fantastic job leading the group and drove home all of the benefits companies could achieve by this.  I was mortified later in the conference when I was talking to one of the attendees about this and they said to me “Stacey is right -componentized architectures really can help…in fact, VendorX is releasing their version 16-something soon and it’s going to be componentized.”  (yes, I’m hiding the name of VendorX because I don’t want to offend anyone, but I can assure you that it’s a software package that’s been around since before Mark Zuckerberg was born and the company has continued to layer stuff on top of stuff).  Unless that vendor has basically started over, it would be impossible for them to meet most definitions of “componentized”.

To help people better visualize all of this, I’ve created a parallel story relating our personal entertainment centers to the concepts.  Click here to see more.

How would you describe a component?

  • Software that encapsulates a discrete set of related functions and/or data
  • A component needs to be replaceable or substitutable – components can be upgraded with a newer version or replaced with an alternative without breaking the system in which it operates
  • Anyone using the component doesn’t need to fully understand “how” it works, just what it does and what it’s interface is to perform targeted business functions
  • A component can exist autonomously to perform its functions, or can be part of a greater system, framework, or business process

What characteristics are required to meet the definition of a component?

  • Should be interface driven (web service or direct API) and no calling function should ever access any code or data of the component outside of the published interface
  • Should not have direct access to any other components
  • Should only have access to data that is specific and local to its business purpose (i.e. all additional data should be fed into the interface)
  • Within the component itself (“inside”), it should follow best practices, including concepts of componentization

Now that we know what an individual component is, what is a “componentized system” or “component-based application”? 

Here’s where the deviation usually comes into play.

  • It’s the level of granularity that makes all of the difference.  Quite often people refer to their “componentized system” where the entire system meets the definitions of the components, not that it is a system or systems that are using components to perform business processes.  The age old balancing act is “what is the right level of granularity”.

Ideally, any two pieces of functionality that don’t ALWAYS have to be coupled should be in separate components.  This provides the balance of maximum flexibility without unnecessary “bloat”

  • Thinking of the software as a “system” is a bit of a tell…you should think of it as a framework with a set of pre-built business processes that are combining components to perform the needs of the “traditional system”
  • The components should be able to trigger events and respond to events
  • Applications should be constructed around targeted orchestrations that combine components to form logical business processes
  • Most good software architects and designers have figured out how to normalize data within a single “system”.  Let’s think about your components the same way and figure out how to normalize them across your enterprise.   Here’s an interesting blog on that.
    http://blog.fasttechnology.com/2013/04/data-redundancy-why-is-it-that-its-not-acceptable-in-a-database-but-okay-across-the-enterprise/

It is hard not to be fooled by everyone saying that they’re componentized.  Also, it’s easy to be discouraged when you have to dig in further to separate out the facts from the hype.  Some of the simple questions and characteristics posed above should help figuring out the difference.

 

Tom Famularo

FAST

 

 

Comments are closed.