Archive for May, 2013

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

Thursday, May 30th, 2013

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

 

 

Software upgrades – why do they rarely happen?

Tuesday, May 14th, 2013

Today, customers and vendors cannot stay in technical and business alignment long enough for an upgrade to make sense

Companies look for seamless, cost effective software upgrades…but it can end up being more painful than original implementation. This puts the customer in a difficult position because they cannot cost justify making the change.

The primary reasons for upgrading to the latest software are:

  • to get new features
  • take advantage of technical advances
  • get fixes from previous version
  • Expand business capabilities

These are all great intentions, but the cost and risk usually (OK, always) outweigh the potential and perceived values of the upgrade.

The image below shows the reality of most software packages: they support way more than the customer needs (driving “software bloat”) and not enough to actually run their business (driving “too much customization”)

 Following are the most common challenges in the upgrade process.

Common-

  1. Typical complex applications have tightly coupled components.
  2. It is hard to document/track dependencies of these components with requirement/functionality, code, config over a period of time.
  3. Most of the applications config/calculations change run time so it is hard to tag/associate these changes to a version of the application over a period of time.
  4. These upgrades require fleet of experienced and expensive consultants.

Most vendors care mostly about their “next sale” and upgrading their existing clients isn’t a high priority

Few other challenges in terms of upgrade are either technical or business in nature.

Technical-

  1. Software applications rely on evolving new technologies to support the changes in business needs, also makes applications easy to use and more efficient. In the early days there were software applications which are entirely dependent on programming languages and on specific databases for example: Power Builder and Sybase. Later on as software applications moved on to new technologies it puts limitation on software upgrades from old system to the new ones.
  2. Integration complexity is far greater than expected.

Business-

  1. In order to be competitive in the current market, vendors have to support a breadth of functionality, products, geographies and technologies.
    1. Typically, any given customer only uses a fraction of what is in the software.
    2. In this case when the vendor is investing in their product, only a small amount of new stuff is applicable to the customer
    3. Taking these full upgrades can never be cost justified – there usually just isn’t as much an incentive.
    4. Company then wants to wait “until it is worth it” – by the time there is enough functionality customer actually want, too much time has gone by and the upgrade costs that much more and is that much more risky.
    5. Most of the complex applications are monolithic in nature and customer may need only a part of component of the application which makes it difficult to upgrade.
    6. So much customization goes into initial implementations to give the business people “exactly what they want” and an upgrade typically disrupts that.  So, the users definitely not the ones who are not calling for the upgrades.

While I think the next “silver bullet” is going to be that the “cloud will solve all of our problems”.  While I am a believer in the concepts that should make that statement true, I’m skeptical that the cloud alone will change the behavior of both the customers and the vendors that have gotten us into this mess in the first place.

All the above challenges make us question if we could ever upgrade software applications similar to upgrades on iPhone or Android applications. The answer to this is ‘yes’.  FAST covers all aspects of challenges in their approach.

FAST is leading the way in making upgrade process simple by giving user ability to click and choose component-features(new/modified since last revision) that are valuable to the client, and apply these components-features to their existing application seamlessly in an automated fashion. Sounds exciting? Tom Famularo presented a preview of the “FAST Auto-upgrade Process” at ACORD LOMA this year.  Stay tuned for more information about this.

 

Raj Koltur