CRN Magazine Roundtable on “identity management today”

I spent an interesting couple of hours recently with a bunch of local IDM people – hard to believe but true!

It was certainly good to get a broader perspective on what’s happening across the industry here in Aus.

The transcript of the discussion can be found here: CRN Magazine Article on Identity Management today.

Recklessly Giving Away Intellectual Property

When we build something for a customer, they pay us and they own the IP – a perfectly reasonable exchange.

Fortunately for us, this is simply NOT the case for large systems integrators. I say fortunately because they lose business to organisations like ourselves because they are simply not able to make a call on the risk/reward profile without substantial legal involvement.

I was asked recently if I was worried about instructing a managed services provider on how to deploy a system to production.

“Won’t you be giving away your IP?”

No we won’t – we’ll be providing a very mundane list of instructions to another team so that they can make the system available to the end users. It’s what we were engaged to do.

For the managers, legal staff and sales team who haven’t done delivery:

There is no secret sauce in system integration!

Everything that is done can be found on the internet, in books and in many, many other systems. There is no secret recipe, no herbs and spices, no magic wand! Successful projects are delivered by smart people who know what they’re doing not mediocre consultants who have access to the “Secret Sauce”.

And don’t get me started on software patents!

BigData carves up SQL Swiss army knife

Simple mechanisms scale better than complex ones. If you want a solution that is massively scalable, pick something simple.

The simpler the technology, the easier it is to scale.

There is an associated paradox: the broader the range of problems a tool addresses, the poorer it addresses any one of those problems.

“Is your Swiss army knife that good at carving the Sunday roast?”

Relational databases are the Swiss army knives of the storage world. In fact, they are so useful that they have become the de-facto storage system for all structured data. But, the use of one technology for structured data does have great advantages: well understood from design through to support; adoption provides revenue for companies to conduct R&D and drive continuously improvement; implementation variety makes for a competitive landscape etc.

So, you want to store key/value pairs to look up mobile plan data from mobile numbers? Sure SQL can do that. You want to store call record data between two mobile numbers and understand call relationships between family members, sure SQL can do that too. Why would you use anything else?

There are two problems:

• the complexity of the underlying SQL technology inhibits scaling;
• there is an impedance mismatch between the structure being modeled and the way in which it is stored.

For quite specific, well defined ontologies, a tool built to model the structure from the ground up will be inherently more scalable than its generic counter part. Enter stage left: the Graph Database and Key/Value pair Databases.

Let’s be honest, both these technologies are completely useless for generic structured storage, but, are stunningly scalable for the specific structures they model.

• Key/Value Pair NOSQL database -> great for looking up mobile plan data.
• Graph database -> great for storing call records and understanding relationships.

The simple truth is: BigData forces you to trade generality for specificity as the means to get “massively scalable”. You have to pick the solution that best matches your problem. You have to have the guts to commit to an alien technology. You have to let go of the SQL security blanket!

See: Objectivity’s InfiniteGraph & Oracle’s NOSQL amongst others…

Take a look at the following posts for some interesting opinions on the use of Graph Databases vs RDBMS ones.

For example:

To be honest, I have a hard time not thinking in terms of a Graph/Network because it’s so much easier than designing convoluted table structures to hold object properties and relationships.

Simular scalability arguments apply in the cloud space too. Have a look at Clouds are complex, but simplicity scales; a winning strategy for cloud builders.

IDaaS Looming out of the Fog – or possibly Cloud

I had two different organisations wanting to discuss IDaaS yesterday – 200% more than normal!

I have one or two of these conversations a month, on average, so wondered if the landscape was changing at last.

According to Gartner it is – take a look at their recent paper on the topic:

“A Guide to Making the Right Choices in the Expanding IDaaS Market - 20 April 2012″

It states some interesting things, not least of all that SIs have now entered the market. That’s people like us!

Apart from the usual motivations such as Web SSO and Federation, the paper states:

“… based on Gartner client inquiries, some enterprises are interested in outsourced IAM, either partly, to handle the SaaS requirements, or to get out of direct involvement with IAM altogether.”

Which is hardly surprising given the level of pain experienced by many organisations when it comes to IDM implementations.

It goes on to say:

“These needs have driven the market to offer two primary models for IDaaS delivery: Web-centric IDaaS and cloud-delivered, traditional IAM.”

The “cloud delivered, traditional IAM” is clearly where the SI’s are entering the market and exactly why people are having these conversations with us now.

The report lists IDaaS providers that include a range of offerings from cloud ready vendor products (build your own IDaaS), Vendor X’s product running on a server somewhere and mature IDaaS offerings that do what you might expect them to do.

The simple truth is that an Identity and Access Management System with any level of sophistication (work flow approvals, SoD etc) requires work – a lot of work. The chalenge at the more sophisticated end of the IDaaS market is creating reusable/repeatable services that can accomodate these requirements while NOT becoming a custom SI gig each time. That would simply be IaaS with loads of services on top!

We’ll be spending more time with our heads in the cloud shortly – we’re very keen to talk to organisations who are considering IDaaS in any shape or form.

I’m keen to understand what your thoughts are on this topic and what problems you think it might solve. I’ll pay for coffee.

Moving house, bereavement and IDAM in the cloud

If you’re looking to move your IDAM system into the cloud, what’s going to be your main problem?

• Security?
  Probably not. Often mentioned but if the truth be known, you’re probably more secure in the cloud than you are right now. That doesn’t make it right, but it’s likely to be true.
• Data privacy?
  Yes quite possibly. Hosting location does matter. But then again, even if it’s here, you might have problems.
• Price?
  Looks cheep but people say there are hidden costs? Is this true? Have you looked at the hidden (or not so hidden) costs of your crippling outsourcing deal?
• Are there companies doing this?
  Sure there are. There IDaaS offerings (private and public cloud) and software that is now more cloud friendly so you could build your own. Really not an issue.

So it should be easy? Apparently not! Take a look at Dave Linthicum’s recent article on growing mullets and moving to the cloud - it got me thinking.

And when I stopped thinking about mullets, this is what I thought: The real problem is that while moving to the cloud has a great attraction, it’s a bit like wanting to buy a new house – you have to go through the agony of moving!

Moving house is up there with bereavement and relationship issues as one of the top causes of stress in people’s lives. In the world of IT, moving your existing IDAM capability to the cloud will be much the same.

Why? For most organisations, moving to the cloud means you have surgically remove the current system, deploy an equivalent  in the cloud and plum the whole thing back together again. All this without a disruption to the business! This is a very difficult thing to achieve and often missed in the simplistic attraction of getting rid of your current nightmare and moving to a clean efficient environment looked after by someone else.

This is essentially a systems integration problem, not an IDAM problem.

For companies like ourselves, I believe this will be a major focus area in the not too distant future. Understanding how to move effectively and efficiently is something we’ll be working on – we have one significant client who’s interested. I’m sure there’ll be more.

If you’re interested in doing this, give us a call and I’ll share where we’re up to.

IDAM and Security resources, where would you start?

I recently had a call from James Turner of IBRS to talk about what we do in the IDAM and Security space.
IBRS had been tasked with conducting an Australia wide survey for NEHTA of companies who work in this space. The purpose is to build a catalogue of organisations who they could reach out to from time to time when the need arrose.

This I think is an excellent idea as understanding who to contact in times of need is a very difficult thing to do for many organisations.

Vendors will tell you a bit about their partners but often don’t understand our capability beyond our ability to deploy their products. Where else do you go? Google is probably your next option but then you have to interpret the services offerings of every organisation you come across.

So who do you turn to understand who can help with strategy and architecture? roadmaps? training? heterogeneous integration? business continuity for an upgrade etc etc?
If you’re an organisation in such a position then you might want to consider such an approach. Probably a much more cost effective and lower risk strategy than trawling the web!

Is there anybody out there?

IAM Mortality 7: monitoring and manageability

This, the final of seven blog posts on essential IAM development capabilities, is on monitoring and manageability.

IAM Mortality 4: functional testing

This is the fourth in a series of seven short blog posts that discuss the essential determinants of long term success or failure for IAM systems.

Remarkably, many organisations get away with almost no capability in this area. So while we would regard this as best practice and certainly something to strive for, a company with a good understanding of its current system and a strong delivery team can often get away with a relatively weak testing capability.

However, there’s a limit to the amount of functionality that can be added to an IAM system before the wheels fall off. Unfortunately you won’t know where that point is until it’s too late. The result? Production instabilities, rollbacks and the expensive activity of debugging in production. If you like bungee jumping, swimming with sharks and playing with live ammunition then this is probably fine.

Do you have these?

• A (relatively) complete and up-to-date set of functional test cases
• A (relatively) complete set of unit tests for system testing
• Automated regression tests.

Almost no one does, but you should at least strive to get there!

In the next blog post: integration testing.

Read part 1 - understanding

Read part 2 - information quality & sharing

Read part 3 - the delivery team

IAM Mortality 6: non-functional testing

We’re on the home straight in this series of seven blog posts on IAM system development capabilities. This is the penultimate post – and it’s on non-functional testing.

If you have a large, highly available, highly secure system then you simply have to be able to conduct non-functional testing.

You will need this if you want to grow the system because you will want to be certain that that the underlying infrastructure has sufficient capacity, supports fail-over, and is secure and reliable.

Without this, you are likely to struggle to maintain a reliable and available production environment. Poor performance, capacity issues and brittle production environments are a common result.

Do you have the following?

• A production support environment where production issues can be faithfully reproduced and where pre-production releases can be faithfully tested?
• The ability to conduct non-functional testing for load and performance, high availability, fail-over and back-up and restore?