Product Naming Confusion

You marketing types responsible for the constant renaming of your sub-brands in recent years (and are probably still doing it) have a lot to answer for. It's caused me a few headaches recently and I dare say lots of others that just haven't bothered to voice their displeasure.

It wasn't so long ago, that many of the large Identity & Access Management (IAM) vendors had sub-brands under their sub-brands before you even got to the real name of the product. That is no longer the case, but it's still a problem that will continue to hang around as long as we have marketing departments and products to sell. Many of the large vendors still do it, some with good reason. But most of the time, it just causes confusion.

What am I talking about? In the IAM space alone, we had IBM Tivoli SecureWay, CA eTrust and Sun ONE, to name a few. Take what is now known as Tivoli Access Manager. Back then, it was known as IBM Tivoli SecureWay Policy Director. Tivoli was better known as a systems management brand in those days, so the "SecureWay" brand made it clear that Tivoli had a set of security products.

What's beginning to happen now however, is that organisations that have legacy applications from those days and have not upgraded still refer to product by the old name, which would be slightly easier to deal with if everyone used the full name. Unfortunately, no one ever does for the sake of brevity.

Now, I'm not going to name any particular company as this could have happened with any of them. For this reason, let's take a hypothetical company, SCI, with a sub-brand called Onetiv, and yet another sub-brand of the Onetiv sub-brand called TrustWay. SCI, being a large software vendor, has lots of products. But it is quite well known for its SCI Onetiv TrustWay DodgyStandardWidget product, which has a standard, open interface called the DSW protocol. SCI has a few other products under the TrustWay banner which are still commonly used, but not as well known.

An organisation, DodgyBrothers, which uses one of SCI's products, has an external consulting team working on specifying a project which has to integrate with the SCI product in question. In the project specification, it states that DodgyBrothers uses SCI's TrustWay product. If you've been following this story along, you should be saying:

"Hang on a minute, which TrustWay product?"

But imagine I hadn't given you the background and that in your mind, you only know of a single TrustWay product: DodgyStandardWidget. Now, place yourself in the shoes of the technical analyst on the consulting team working on the specification for the project. The next line you write is going to say something along the lines of:

"And the integration into TrustWay is done via the standard DSW protocol".

Based on this project specification, an agreed statement of work was signed between DodgyBrothers and the external consulting company to implement the solution with a set of agreed timelines (based on project estimates derived from the specifications). Along comes the design team who then reads through the specifications and then proceeds to design the solution. As part of the design, the architect needs to talk to relevant teams within DodgyBrothers to gather information regarding each integration point.

When it comes time to speak to the TrustWay team, the architect is greeted with the response:

"What do you mean by DSW protocol? TrustWay doesn't support the DSW protocol."

The architect then asks the TrustWay team to send any documentation they have on the TrustWay product. Upon receiving the information, the architect is horrified to read the title on the first page: "SCI Onetiv TrustWay NotSoDodgyOtherThingy". The architect thinks:

"Maybe it's not so bad, perhaps it uses the DodgyStandardWidget product as the underlying store. Nope. Next. Ok, maybe there's an interface we can leverage to integrate with this thing. Nope. Now what? Oh, command line. S*$%."

I don't need to tell those of you with project experience what just happened. Project plan, blown out. Cost, blown out. Budget, gone. Change request? Let's hope the client agrees. Unlikely. It was the consultant's fault for not doing their homework. Or was it?

Yes, the technical analyst is to blame for not being thorough (due to an assumption they had no reason at the time to think was incorrect). But anyone responsible for using sub-brands, swapping them in and out and constantly renaming products thus confusing the heck out of customers has to accept some of the blame too.

Me? I'm just annoyed at having to be the one doing the due diligence after the fact and be left holding the lump of crap after you've all run away. Thanks.