Third-Party Software Products and Components

For the want of a nail the shoe was lost,
For the want of a shoe the horse was lost,
For the want of a horse the rider was lost,
For the want of a rider the battle was lost,
For the want of a battle the kingdom was lost,
And all for the want of a horseshoe-nail.

- Benjamin Franklin, Poor Richard's Almanac [well, at least this version of the proverb]

There are a lot of great software products out there and a lot of companies and developers do a great job of giving their customers what they need.  But sometimes you need a capability that isn't there and that's where the a "third-party" comes into the picture.

What Exactly Am I Talking About?

It is a relative term, not an absolute one, so don't get hung up on the semantics.  For the purposes of this discussion, I am referring to software products and components.

Software products includes applications or a collection of applications. On a individual level, the numerous applications made by various developers for your favorite smart phone would fall into this category.  At the enterprise level, a good example would be a software suite that lacks a special need that is critical to your business, but not common enough for the suite vendor to develop; so, you turn to a third party that fills that gap and enables the suite to meet your business needs.

Software components are more "under the hood"; they refer to components at the software engineering level.  A simple example would be grabbing a library off sourceforge or github that includes a set of functions for email to incorporate into a larger application you are developing for customer relationship management.

While these may seem like very different things, many of the key considerations are similar when making decisions related to them.

Why Use Third Parties?

More parties means more complications.  So, why bother?

• There is no other way to meet the need
• It enables using a product that is otherwise the best fit for your needs
• It saves a lot of money or time, e.g., a relatively inexpensive third-party module lets you keep using your existing suite and avoids significant lost revenue, transformation management, retraining, etc.

Things To Consider

The core of any good decision is weighing benefit and risk.  Some good questions to consider are:

What Exactly Are You Trying to Achieve?

Sure, this may seem incredibly obvious, but be sure that the primary consumers of the services provided by the third-party product/component will actually meet their needs.  That is best achieved with robust requirements-gathering and conversations with the primary consumer of the services the product will provide.

Once those requirements are identified confirming that there is a common understanding and agreement on what those final requirements are is valuable.  In the case of complete software products, a demonstration for the key stakeholders can be priceless; ideally, you would provide the script for the demo, to insure it covers the capabilities that matter to your users.

Need to Have or Nice to Have?

This is another part of requirements gathering that is critical to understand.  If you are purchasing a massive enterprise content management suite so that you can centralize and digitize Accounts Payable, but it does not support your accountant's business needs, you may have a very costly problem.  However, if the problem comes down to a personal preference, then you might be okay.

In a nutshell, it's good to know that if integration or development becomes too problematic or costly, whether or not the business/user's needs can be met without the feature(s).  For bonus points, if there are multiple needs, assigning weights to their relative value can be very helpful.

What is Plan B?

If you do have to abort buying, integrating, or implementing the feature(s), what are your options?

• Simply forego the capability altogether
• Find another third party
• Push the vendor/developer to create the capability
• Look into another product/vendor that provides the full capabilities

What is the full cost?

There are a lot of factors to consider beyond just the explicit price tag associated with incorporating a product or component.  Some key ones.

• How much time will it take to integrate/implement?
• Will you need to increase/expand the staff or their skill sets?
• If this capability does not function adequately, what will the impact be? (business operations, other features/capabilities, cost, liability, strategy, brand, etc.)

The Song Remains The Same

Ultimately, it's a lot like any selection, except that dependencies between the systems become more critical.  You don't want that nifty app killing your phone's battery or crashing it.  You don't want that nifty little workflow enhancement module to shut down your company's enterprise content management suite.

To return to the proverb that started this discussion, it sure would be a shame to use the wrong nail and lose the kingdom.