Joined up thinking

When I phone up HM Revenue and Customs to sort out a tax issue relating to a tax return filed online, I have to give a separate reference number (the company reference) to the one I use on the website. Then if you phone your local accounts office, they need another one entirely (the accounts office reference). We actually spent a year using an account ref and a company ref that were not connected together, with very tedious consequences.

This is a result of separate systems being developed to be self contained, then attempting to glue them together. It never works well, but I'm constantly amazed at how many companies and organisations still try and do it.

There are essentially three ways to run software projects in large organisations which do lots of disparate things:

The One True System

Develop the One True System that satisfies all your requirements in one integrated project. One database, one infrastructure platform, one language - everything runs from the one single system. This is a bit like running a communist state - absolutely fantastic in theory, but the vision will never be realised because there will be too many stakeholders, and lots of people means lots of differing opinions. It is also a mammoth exercise in planning and logistics, will take ages, and what you end up with will satisfy no-one.

The Blinkered Systems

Rather than trying to solve all problems in one system, you could try and solve each problem with a separate system. So each one of these systems has it's own specific job to do, but also has it's own authentication system, infrastructure, database, interface design, and so on. If another project has already implemented an authentication system you don't use it, because, well... it's theirs. It won't be as good. And you don't like them anyway. They'd probably be difficult, and hold you up, and you don't have time to listen to them right now. This results in a system that might be great for doing it's thing, but is completely incompatible with anything else the company does.

The pluggable systems

The 'third way' is an approach that solves one problem at a time, but acknowledges the need for other systems to interact, and makes use of other systems that are already so enlightened. If the system needs to authenticate users, use an existing identity management system to do that. Need to charge a fee? That goes via an existing e-commerce platform. And then you think, well, we're using all this great stuff that other people in the company have produced, so we ought to give something back. So you add hooks into your system so that other people can make their system use yours for whatever it is that your system is good at doing. You do not consult every person who might want to integrate their system with yours, but you just provide as much integration potential as possible, and then let smart people figure out how they can use it.

Clearly I'm advocating number 3, and it's a bit of a no brainer really. A large organisation cannot hope to create a system that does everything, but it can easily set up and fund projects to do utility stuff like managing identity. If you want to show the return on investment in these systems, set up an internal market and have the customer-facing systems pay the utility systems a fee every time they use them.

Individual systems do not need to share the same platform, language, or architecture, and using a different one may well make sense, particularly if they're outsourced to a third party supplier and a different platform is appropriate to the task. But as far as the customer is concerned, all the common elements are the same, and that's what really matters.