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.

Why does your organisation buy enterprise security software?

The answer might seem obvious, but it's not.

I had a very interesting chat with Eurekify founder Dr. Ron Rymon the other day about a multitude of things including the GRC market at large as a follow up to my post last week regarding CA. One thing I didn't mention was CA's agreement with Eurekify to resell their Enterprise Role Management product, but you'll find it within the comments in response to the post. Ron also reminded me that Eurekify has a GRC solution offering of their own. A lot of people think of Eurekify as just a role management company because that's what they're best known for. Eurekify specific discussions aside, one of the things we spoke about was the various reasons behind why organisations buy GRC software. This got me thinking a little more, which brings me to the point I'm trying to make.

I went into some amount of detail about approaches and drivers to GRC but one thing I didn't talk very much about was the reality of the situation in some organisations and their attitudes towards security related activities (I'm including compliance here). I've found in my experience that it is the attitude and corporate culture that will ultimately determine if a particular piece of security software is the right solution for the organisation from a decision making and purchasing standpoint. If you are the sales guy, you need to very quickly qualify the opportunity as follows:

1. Is the organisation interested in implementing a security solution to solve real business and IT problems or do they want to "tick check boxes" within a form so they can satisfy specific audit requirements?
2. Is the software product you are selling a tactical or strategic one?
   

Most sales guys will answer question 2 by saying "of course my solution is a strategic one!". Don't kid yourself. You know what it really is so you need to sell it accordingly. I should probably explain the difference between a strategic and tactical software product:

• Tactical - typically a point solution that does one or two things very well. e.g. an encryption product.
• Strategic - a platform or infrastructure solution that solves a larger, high level issue that is of business significance and affects more people (or parts of the organisation). e.g. an Identity & Access Management suite.
  

Taking a very simplistic view in this case, your qualification matrix looks like this:

	Tactical	Strategic
Solution approach	need partners	in
Tick check boxes	in	out

If you are selling a tactical solution, your best bet is to go for organisations trying to tick check boxes that the auditors said to tick. e.g. an auditor might say "if you encrypt all your disks and superglue all your USB ports rendering them unusable, I'll tick the PCI-compliance box for your organisation". If you are selling a strategic solution, go for the organisations that actually want to address an issue properly and more holistically. In other words, they are more interested in proper security. That's not to say you can't go for the strategic sale if you have a tactical solution. You just need to partner with the right vendors to give the organisation a "best of breed" solution.

The thing we need to examine is why so many organisations think ticking check boxes = good security? I'll talk about that another day. I've already written one long essay this week.

For now, ask yourself:

1. If you're in sales - are these guys ticking boxes or addressing security?
   
2. If you work in an environment that buys software - do we tick boxes or do we address security issues?
   

It'll save everyone a lot of wasted time and money.

Commoditisation of Federated Identity software part 2

I blogged about this late last year and outlined a whole bunch of reasons why I thought this would happen sooner rather than later.

I'm bringing this up again because some of the Higgins and Bandit bunch are talking about a proof of concept they will be unveiling at the RSA Conference next week which shows:

how companies can integrate a non-Liberty Alliance identity system and a Liberty Alliance-based federated identity system provided by Novell Access Manager. In particular, the demonstration will have Novell Access Manager authenticate a user via Microsoft's CardSpace using information from an external identity system. In the demonstration, users will be able to access a sample media Wiki and blog using the technology.

The obvious Novell promotional reasons behind this aside, there was a quote from Paul Trevithick (Higgins project lead, amongst other things) which stated:

"One problem in realising the vision of an open-source identity layer is that tends to commoditise existing identity management products, creating a perverse incentive for companies that are in a position to make interoperable identities work."

He goes on to say:

"That may be the reason you hear about interoperability but still haven't seen it. Companies like Oracle and IBM and even Novell have no incentive to do it."

This brings up something I didn't mention previously - the position this puts the big vendors like IBM, Novell, Oracle, Sun etc in. They are all evangelising the need for open standards and interoperability, which is where we all want things to end up. Problem is, the guys holding all the $$$ within the vendors are then put in an interesting position...support these initiatives at the cost of software sales. Because in doing so, they're effectively cannibalising their own market. This is especially prevalent in the Federated Identity space because the whole concept of Federation is built upon open standards.

Like I said before, I don't think they can stop the freight train and the Federated software products look to be next in line for commoditisation.

Increased competition in the Enterprise Identity Management space

The recent spate of announcements made by the large Enterprise Identity Management (IDM) vendors has made the competitive landscape very interesting for the suite vendors (IBM, Oracle, CA, BMC, Sun, HP).

Oracle just released (OK so it was in August, but that's still quite recent) version 10g release 3 of their IDM suite with much more tightly integrated components and increased functionality.

The very recent Gartner Identity and Access Management summit has also yielded announcements from HP and CA. HP has announced increased functionality in their suite, although I'm not convinced they are that integrated yet. Their focus has not been on their IDM business and as a result, they've taken a little longer to integrate all their acquisitions. CA announced new versions of the major products in their suite. They coupled this with the announcement of an OEM agreement with Ping Identity to incorporate their federation technology into the eTrust SiteMinder product. They're also further along in their acquisition integration journey than some of the other vendors so by now they have probably gotten their act together and have an integrated suite to rival IBM. It'll be interesting to see what happens in the next year or so in this space with IBM yet to announce new versions of their products this year (other than the new Tivoli Federated Identity Manager Business Gateway for SMB).

Next move, IBM? Or maybe some kind soul will finally integrate Sun's suite for them as they've pretty much "Open Sourced" everything. They can only hope.

Commoditisation of Federated Identity software

Federated Identity software products will be commoditised. OK, so I'm not saying anything anyone couldn't have figured out for themselves. But this will happen much sooner than many of us expect.

Most software eventually goes the way of commoditisation unless the vendor innovates to the point where it morphs into something different. I won't even mention hardware as this market is largely commoditised and vendors are having to differentiate themselves using "bells and whistles" like performance improvements and aesthetic qualities (e.g. an Apple Mac laptop).

Back to software...

Take the following obvious examples of recent times:

• HTTP web servers
• J2EE application servers
• Relational databases
• LDAP servers

We can probably all agree that these are all are pieces of critical software infrastructure that form the basis of many of our IT environments. Microsoft is a different proposition. It is its own market and should be treated as such. Why? Because they are not known for interoperability. If you buy Microsoft, you will typically have non-commoditised products because they operate the "Microsoft way". ie. they are not like the other products on the market simply because they refuse to be. I don't mean this in a good way of course. It is simply a fact and makes life harder for the IT community at large because of it (unless an organisation goes 100% Microsoft - which is essentially Microsoft's preference).

So why did all these examples become commoditised? Not only did they become commoditised, then did it very quickly. There's 2 common threads between all of them:

1. They are all essential building blocks for most IT environments.
2. They all conform to standards.

Point number 2 is the key. The reason for the fast and widespread success of these technologies is the exact same reason why they became commodities so quickly. Open, standardised interoperability begets almost forced implementation of the relevant accompanying technology to "keep up with the Joneses". If you wanted to be able to "e-business-enable" your organisation, you better have an easy way lower ongoing development costs and reduce the risks involved with implementing ever-evolving technologies. Standardisation does that. Every software vendor of note wanted in. They saw these technologies as key pieces of software that would allow them to seed more software on top of them. The Operating system wars of years past were now being fought on a "higher plane" further up the application stack. These technologies put together have become the "operating system" of everyone's "e-business". As far as vendors were concerned, it would cost more in the longer term to NOT be in the game.

So it didn't matter that vendors did not make money from these technologies, as long as it meant they had a seat at the table for future software evaluation activities. In fact, most vendors give their LDAP and web servers away for free, with application servers just trailing behind in the "free stakes". Relational databases aren't explicitly free, but they are usually given away as part of another software offering. Or if someone is willing to go for the SMB option, they could download the open source relational database.

In the Identity and Access Management arena, the LDAP plays a big part. Like I said, this is usually free. Moving up the stack, we get to the meta-directories, synchronisation, provisioning and access control tools. It's been said for quite awhile that the access control solutions around have become commodities. To an extent, that is true. But that's simply what it looks like from the outside. The real reason in my opinion is that IBM Tivoli and CA Netegrity own most of the access control/application reverse proxy market. So if you talk access management, you're probably "standardised" the Tivoli way, or the Netegrity way. I know I'm ignoring RSA Cleartrust, but they have a MUCH smaller market so I'm treating them as a non-factor. In other words, this "commoditisation of access control" is only a perception. I dare say that's not really the case. Can you say "I want an access management solution so I'll do a design and just buy the cheapest product out there and my design will work"? Hell no! You could however, say this if you're talking about an LDAP design or a J2EE design (yes I know there are small differences between each vendor's implementation, but these end up being configuration, deployment/infrastructure and tuning tweaks rather than real business design issues). In other words, access management solutions are not really commoditised. They just seem to be because of the total market domination of IBM and CA in this space. I dare say, it'll be awhile before they truly become commoditised (disclaimer: "awhile" in the IT world is not really that long - I'm just saying this bearing in mind that we're talking within the IT context). XACML will need to be widely adopted and implemented in all access management products before we can say this area is anywhere near being truly commoditised. As for the meta-directories, synchronisation and provisioning tools, it may be awhile longer before we see commoditisation of these things. The next one after access management will probably be provisioning. Why? SPML goes some way towards some sort of standard. Even so, all that does is to give us a standard way to talk to the provisioning endpoints. It does not standardise the provisioning policies, processes, transactions, workflows, roles, delegation, reporting, audit and compliance requirements (and so on) and how they are implemented. ie. all the important business things. So, we have a ways to go here.

Back to my point. The next piece of technology in the Identity space to be commoditised (even before the access management products) will be the Federated products. The reason? Standardisation of the protocols. Yes I know we have a few around today:

• WS-*
• Liberty
• SAML
• Shibboleth

So there's 4 at the moment. This will very quickly become 2. Microsoft, and the rest of us. So what else is new. Shibboleth is the BIG thing in education circles, but it's essentially SAML 2.0 with some extra bits. Liberty is also a subset of SAML 2.0. So, what are we going to be left with? SAML and WS-*. Non-Microsoft vs Microsoft. Much like J2EE vs .NET. What this means is that we'll be left with everyone being able to "speak" SAML and some being bilingual and able to translate between SAML and WS-* and Microsoft only being able to converse in WS-*. So with everyone being able to interoperate (sort of), organisations will be left with 2 decisions to make. Which protocol to use (maybe both) and which vendor's product to buy or download for free. e.g. if I want to use SAML 2.0, I just need to pick a vendor that supports it. In other words, any vendor not named Microsoft. This means my decision will centre around the price, support agreements, company stability (whether I like them and if I think they'll still be around tomorrow) and business relationships I have with the vendor. Nothing technical in my decision making process. Of course, all the vendors will argue scalability, reliability, product maturity, ease of deployment, references, happy customers, blah blah blah - which is exactly what hardware manufacturers do. Sounds like a commodity to me!

All the identity vendors are in the federation game of course (there's also a few niche players out there like Ping Identity.). They can't afford not to be - except this time, they are positioning Services Oriented Architecture (SOA) as the endgame and saying that Federation is the key to security in the SOA world (it is of course key...if we're talking about identity exchange, propogation and trust - but there's more to security than just identity). So starting at the SOA and web services layer to get the "foothold", they are instead working down the stack. With this, vendors can now work at potential customers from both ends of the application stack. For example, if someone buys the application server, the vendor sells software up the stack leveraging the application server. If someone buys the SOA and federated stuff, vendors simple sell down the stack and push the "tight coupling" and "close integration" aspects of the non-commoditised software products.

I dare say, in a year or 2 the federated identity landscape may look like this:

• JBoss application server will support SAML federation natively (JBoss is already working on JBoss Federation SSO using a SAML token. It's all Open Source of course...in the JBoss way).
• BEA WebLogic will follow suit (BEA doesn't have identity products).
• Microsoft will WS-* the hell out of anything and everything and include lots of "CardSpace working with WS-*" examples to "quick start your customer applications".
• Apache Geronimo will have some sort of SAML federation extension.
• Oracle Application Server will ship with Oracle Identity Federation "light".
• WebSphere Application Server will have IBM Tivoli Federated Identity Manager "express" natively installed.

So which application server do you want? Hopefully it'll dawn on us at the time when we're all feeling a sense of deja-vu why it is so.