Qubit Consulting Articles

Moving house, bereavement and IDAM in the cloud

john.jones — Tue, 05 Jun 2012 16:00:59 +0000

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.

Moving house, bereavement and IDAM in the cloud is a post from: Qubit Consulting Articles

IDAM and Security resources, where would you start?

john.jones — Mon, 04 Jun 2012 01:48:06 +0000

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!

IDAM and Security resources, where would you start? is a post from: Qubit Consulting Articles

Is there anybody out there?

john.jones — Mon, 04 Jun 2012 00:47:58 +0000

We are looking to grow again and are interested in talking to anyone in the Identity Management space who’s looking for interesting work with a smart team.

We are based mainly in NSW but have the occasional need to work interstate for short periods. The work varies from deep technical challenges through to consulting and advisory services. You will need to be a good self starter and hold your own in an account. The engagements will vary from days to a few months.

Even if you’re not looking to move right now, we’re happy to catch up and tell you a bit about what we do. That way, if you ever feel like moving you’ll have at least one option!

Do you have any of these skills?

Oracle Identity Management product knowledge: OIM, OAM, OIF, OIA OVD, OID?
Any other IDAM product knowledge and an urge to learn more?

If so, drop us an email and let us buy you a coffee!
john.jones@qubitconsulting.com

Is there anybody out there? is a post from: Qubit Consulting Articles

IAM Mortality 7: monitoring and manageability

john.jones — Wed, 16 May 2012 07:59:33 +0000

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

All to often organisations put IAM systems into production with almost no way of knowing what’s actually happening under the hood. It’s not uncommon for organisations to rely on customers to calls them as the primary means of detecting when their IAM system fails! Hard to believe but true.

Why do you need to know what’s happening? Why can you just leave it run? Why can’t you just rely on the high availability configuration? After all, it cost enough!

The number of things that can go wrong with a system and still provide a service is always interesting. A server may fail in a HA configuration and the system carries on. Another may fail and it carries on – great! But eventually the last server will fail, customers will call and then you’ll realise that there is nowhere to turn. It’s over. You wished you known about the first failure when it happened as it turns out that it’s going to take a long while to sort out.

It’s not just application or server failures that you have to look out for. There’s networking, storage, dependancies on other systems. More often than not there will be things happening under the hood that you had no idea about. Things you really wish you knew ages ago. Things you could have sorted out then and not on a Sunday afternoon during your kid’s birthday.

If you have good control of the production environment and can manage the day-to-day activities without being worried about causing unplanned outages, then you’re in a strong position to tackle change events and expand the system.

If your capability in this area is weak, you’ll eventually be unable to deal with production issues promptly, and you’ll see a drift away from reliability that is accompanied by a lack of faith in the system as a whole and a general reluctance to extend the system.

How do you fair with the following questions?

Are you able to conduct most production changes without a business outage?
Are you confident that DR fail-over works?
Are you confident that backups can be restored?
Do you know what’s going on? Are all the systems monitored for faults: hardware, applications, network, etc.
Are the logs monitored for errors and warning?

Clearly you can extend this list. The intent here is to provide relatively simple sanity check on your current ability to grow your system over time and continue to provide business benefit.

Read part 1 - understanding

Read part 2 - information quality & sharing

Read part 3 - the delivery team

Read part 4 - functional testing

Read part 5 - integration testing

Read part 6 - non-functional testing

IAM Mortality 7: monitoring and manageability is a post from: Qubit Consulting Articles

IAM Mortality 4: functional testing

john.jones — Wed, 16 May 2012 07:18:38 +0000

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 4: functional testing is a post from: Qubit Consulting Articles

IAM Mortality 6: non-functional testing

john.jones — Mon, 16 Apr 2012 07:58:43 +0000

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?

And if you only have a small in-house system then this will NOT be a major determinant of your long-term success. Just a nice to have.

The final blog post will be on production manageability.

Read part 1 - understanding

Read part 2 - information quality & sharing

Read part 3 - the delivery team

Read part 4 - functional testing

Read part 5 - integration testing

IAM Mortality 6: non-functional testing is a post from: Qubit Consulting Articles

IAM Mortality 5: integration testing

john.jones — Thu, 08 Mar 2012 07:29:16 +0000

This blog post – the fifth of seven – focuses on integration testing of IAM systems.

Because of the integration nature of IAM deployments, integration testing plays a significant role in an organisation’s ability to push past more than a very small handful of target systems. Most organisations really struggle to get past about 4 systems fully integrated. This is staggeringly low number when you consider that a large corporation will often have a few hundred different applications that should at least be managed indirectly and many tens which should be managed directly. It’s likely that your business case simply woudn’t stack up if you said “we’re going to spend a million dollars to integrate AD and a couple of other things”.

Pushing past a small handful of systems absolutely requires good integration testing environments and people who know how to run them!
Do you have these in place?

An SIT environment that includes the complete application ‘ecosystem’?
A complete set of integration tests?
People who know how to test them?

If you do, you’re in good shape. If not, consider this a priority and start making it happen! As mentioned, IAM systems very rarely grow past a small number of connected systems without this.

In the next blog post: non-functional testing.

Read part 1 - understanding

Read part 2 - information quality & sharing

Read part 3 - the delivery team

Read part 4 - functional testing

IAM Mortality 5: integration testing is a post from: Qubit Consulting Articles

IAM Mortality 3: delivery team

qubit — Thu, 08 Mar 2012 00:26:55 +0000

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

Its focus is on the delivery team.

There’s no doubt that if your organisation has a clear ability to deliver IAM projects with confidence and certainty it will be well placed to extend the system over time.

If you struggle to deliver IAM projects with or without an SI, then the system’s growth is likely to be very limited indeed!

See if you can put names to the following roles and be honest about their abilities:

A person (architect?) who is able to design extensions to the system while maintaining the overall system integrity
A person who understands what functionality is available within your products and knows how best to use it
A developer (or developers) who has a good working knowledge of the current system and the products in use.

If you cannot honestly identify people who have these skills (internally or within a trusted SI) then you’re system is likely to stay frozen in time. And that’s if your lucky!

What should you do? Go find people you trust who can fulfil these roles. You will not progress without them.

In the next blog post: functional testing.

Read part 1 - understanding
Read part 2 - information quality & sharing

IAM Mortality 3: delivery team is a post from: Qubit Consulting Articles

IAM Mortality 2: Information Quality & Sharing

qubit — Tue, 07 Feb 2012 20:15:27 +0000

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

Its focus is information quality and sharing.

This is obvious but…. if your organisation has good quality high level documentation that is up-to-date, clear and transparent then you will be well placed to take on new staff, engage external parties for major work, move the system to new platforms, and extend the system in the future. It’s as simple as that!

If you don’t, your team will forever be in a state of darkness.

You’ll have people wondering around aimlessly wondering how to get things tested, wondering how to get things funded, wondering why this thing was built in the first place, wondering why they shouldn’t write it from scratch in a few days and save the time to learn these strange products.

The documentation I’m talking about here is not detailed technical documentation. That is good too, but typically represents the system’s implementation at a given point in time. The documentation that is more useful in the long term is high level documentation that tells people why on earth this system was built, what does it do, for whom, who owns it, how do we know if it’s doing it’s job?

This information is much less volatile and provides a much better picture of the system to a whole range of audiences over a much longer period of time. This information provides a mud-map for people to follow to find the people, process and technologies they need to understand the function and purpose, how to get engaged and know who to talk to . This is the stuff that is normally in people’s heads. This is the stuff that leaves when people leave. This is the stuff that is absolutely crucial to the long term success of the system.

This is essentially the difference between what you get in a Solution Architecture and what you would get if you followed an Enterprise Architecture methodology. It doesn’t need to be War and Peace but it should capture the contexts, concepts and logical structure. Use something like a simplified Zachman model if you want to get more technical. You probably have the physical high level and detail already.

To get an idea of how well you fare in this area, see if you can lay your hands on documents that describe the following:

A (business architecture) document that states what your IAM system is for, who owns it, describes the management structure and outlines a plan for the future
A (derived requirements) document that captures all the use-cases and the business processes
A document that describes the identity life-cycle for each type of identity, the approvals required, their default entitlements and any other basic information that described the life cycle of identities through the system
The information, technical and application architectures.

If you don’t have this but you have people who can tell you, you should get them to write it down!

If you don’t think this information is important, consider what needs to be done if you choose to move the system to a different product set. The team chosen to do this work will have to reverse engineer the current system from scratch before being in a position to provide a quote for an upgrade! This is a very bad position for you to be in. If you’re facing this prospect, there’s a good chance you’re considering startting your IAM initiative from scratch. That is, you will have considered your current system effectively End of Life.

We have a simple MindMap tool which you can use to draw out the most basic information quite quickly. Let us know if we can help – sometimes it’s easier to get someone else to come and ask the obvious questions.

In the next blog post: the delivery team.

Read part 1 – understanding

IAM Mortality 2: Information Quality & Sharing is a post from: Qubit Consulting Articles

IAM Mortality 1: Understanding

john.jones — Sun, 29 Jan 2012 18:48:29 +0000

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

Have you ever wondered why some organisations derive a long and useful life from their IAM systems while other start from scratch every three to four years?

The truth is, the useful life span of an IAM system is often determined by a few very simple things. We’ll examine these over the next few posts and provide some thought provoking self assessment questions.

A day in the life of an IAM system…

Firstly, your IAM system will grow, incorporate more systems and more identities.

It will need patching and product upgrades.

It will change through the extension of workflows and the addition of systems.

It may be migrated onto new hardware.

You may choose a different product and cross grade the system as a whole.

Each of these “change events” – large and small – is a challenge that your organisation has to deal with. Organisations that fail to rise to these challenges and deal with them effectively simply loose control and are eventually left with an expensive and ineffective system – a failure. Many failures are simply a case of neglect!

But these change events also represent an opportunity to gain strength and resilience, an opportunity for the system to grow and provide more value to the business. Like any living thing, dealing with these challenges is what drives strength, growth and resilience. If your system never gets a chance to grow, it will simply fade away in its infancy. To derive a return on your initial investment, growth and longevity are absolutely essential.

So, understanding these events and your ability to cope with them is crucial to the long-term success of your IAM system.

Cope with change events well and you’re likely to have a system that grows from strength to strength. Do these things badly and the chances are that you start from scratch every 3-4 years.

Capability: Understanding

One of the the most significant determinants of your system’s long term success will be your organisation’s collective understanding. This capability is essential in understanding and dealing with change events as they arrise. Without this capability, you have almost no hope.

Organisations commonly suffer key staff or partner loss that puts the organisation as a whole in a very poor position to tackle almost any change event that might arise thereafter.

How do you know if you have lost this capability? Maybe it went the moment the SI left. Maybe it left when the internal evangelists left to build a new system elsewhere?

Try this – get your team in a room and get them to:

Draw the system on a whiteboard and describe how it works
Describe the overall business process flow from start to finish, and the corresponding information architecture
Explain technical mechanisms such as load balancing and fail-over, replication, back up and restore
Create some simple scenarios such as a patch release and work-flow change, and see how quickly and easily they can determine what the effects will be, what changes need to be made, and how long these will take.

If your questions are met with stunned silence, panic! If you’re pleasantly surprised, then so far so good – check out the next post on information quality and sharing to see how you fare.

IAM Mortality 1: Understanding is a post from: Qubit Consulting Articles