At my day job, we are nearing the ‘end of the beginning’ in terms of the merger that the agency recently went through.  The HR structure is mostly in-place, new business strategies are out (or coming out) and things are ticking along… but what about the technology?

I must admit this is the first major merger I have been close to, the volume of technology we have is certainly out there and we are starting to figure out what to do with it all, so I thought timely to provide some insights into the issues opportunities we face and perhaps give you a wee look at how being a government agency affects this.

The As-Is

There are basically two halves to the agency: the ex-Transit bit that looked after highways and major roading networks, and the ex-Land Transport (LTNZ) bit that looked after the motor and driver license registers.  That’s a massively simplified view of what the agencies did (and currently do in the new form), but it should be enough for this.

Transit was a Java shop, with lashings of IBM software running on a mix of Windows and Linux platforms; LTNZ was mostly Microsoft based, with the two big registers being LINC mainframes. On the web we have a variety of bespoke and COTS systems in Java, .Net and PHP.

Database platforms include the usual suspects you’d get in the above stacks as well as Oracle 10 and 11, and some Essbase cubes.

And we won’t mention, for now, any of the stuff we don’t know about that gets introduced under the radar.

Enter the Rag List

I must confess I hate this term, but I conversely love its value.  What’s a RAG list?  Well you won’t find it on Wikipedia; basically it’s a list of technologies and whether or not they are approved for use in the organisation.  Hardly a novel concept, and probably known to many of you under different names.

RAG comes from:

• Red: This technology or software must not be used.
• Amber: Either not sure about it until we take a look or we have used it and it's not recommended.
• Green: Can be used with abandon.

At the moment we are sometimes referring to it as a RAG-doll, I guess because it suggests that you might be able to use it as a voodoo doll, skewering it with software and puncturing it with platforms.  Oh, the things architects are driven to.

Where you get the value is in two places.  The second is easy to explain: it gives you a definitive and easily interpreted document you can use to steer people in the same direction.  The benefits of having a single technology stack should be obvious enough so I won’t go into that here.

But the first and arguably most valuable use of a RAG list is the discussion needed to produce it in the first place.

We are pretty blessed in that our architecture team is quite small, everyone gets on really well and there’s never any strife.  For the record we have two Solution Architects, a Data Architect, a Technical Architect and our manager who amongst other things looks at the high level direction.  We all currently do a bit of ‘pseudo’ Enterprise Architecture, which is fun and interesting (honest), whilst we wait for an Enterprise Architect to be appointed.

So we were fortunate that given our different backgrounds and positions’, coming up with an agreed list wasn’t that hard; but that doesn’t mean that it’s all a no-brainer and we’ll be in “technology-alignment heaven” by the end of the week.

I guess you want to see the list.  Unfortunately that’s not so easy right now – it’s still in ‘draft’ whilst we confirm it amongst ourselves (we know what we want, but have we made it clear? Have we missed anything?), and it’s a bit commercially sensitive, so I should really ask permission first, not forgetting of course that It’s generally a good idea to get buy-in from your relevant stake-holders before posting something on the net.

One aspect that is important is that it’s not a straight choice between Linux or Windows, SQL or Oracle and it’s not even a choice between a Microsoft based stack or a non-Microsoft based stack; the IT landscape we have inherited is diverse and the divisions aren’t always crystal clear.

For example, let’s look at adding a new website.  Depending on what’s needed will influence where it’s hosted and what technologies can be used.  Does it need to be externally available?  Do users need to login?  What back-end systems do you need to integrate with?

If it’s a bespoke system we’d probably be looking at a .Net solution, although major projects have recently been completed in Java, and PHP is an option for ‘light-weight’ sites.
Then you have situations where the business will find a commercial package that suits their needs but runs against (or not entirely in-line) with a prescribed architectural direction (out comes the voodoo RAG-doll and pins!).  If we take the line that IT is here to support the business then clearly the decision is a no-brainer – assuming of course that its introduction isn’t going to have massive costs and side-affects that defeat the business case for it.

Our solution to this is to define an overall list of ‘approved technologies’ and then a preferred stack and secondary stack.  We are still debating the final wording but the gist is this:

• The ‘main’ list of approved technologies shows all technologies that are available for use: which must/should really be used, which can be used (provided you get the ‘ok’ from us) and technologies that we currently have but want to phase out – so please don’t use these.  Anything not on the list needs to be ok’d with us too.  The idea is to give a single view of what’s available.
• The preferred stack is our first choice across the board, and represents a single cohesive direction. 
• The secondary Stack states our preferences when the preferred stack isn’t used.  Just because someone can’t (or won’t) use the preferred stack doesn’t mean we don’t have a preference; you can’t bring a degree of sensibility to the environment by focusing on a single stack and ignore anything that doesn’t fit into your neat and comfy ideal.

But wait, there’s more.  Before you choose a stack to enforce you need to go way back to the beginning – do we even have a stack?  Enter the cloud.

Choosing Stacks

Ok, cloud computing – bzzz! Buzz-word / hype alert.

Well you can paint it with that brush if you want but that’s like burying your head in the sand like an ostrich.  Let’s say MS Word was the corporate standard for word processing – what is there to prevent users using Google Docs?  Yes, we could police the proxies and ban access, but that’s just a variation on the ostrich.

Should we care? 

Firstly, as a government agency we can’t store government data off-shore.  Secondly, as a government agency we are bound by things like the official records act.  Does using Google Docs violate these?  The first yes, the second probably.

On top of that we have investments in Enterprise Information Management Software: basically documents are stored in a central repository where they can be controlled. Think source-safe for the business.

So while it’s unlikely we’ll be pushing Google Docs as the new corporate standard for word processing, the whole concept of having stuff in the cloud adds a new dimension to the idea of documenting approved technologies.  If reducing the number of database platforms used makes you more efficient (because you have less diversity to cope with) what about applying that argument to the whole concept of in-house IT staff?

Part of the issue here is that it’s still early days.  It’s too early (for us, anyway) to know what the right application of cloud-based systems is.

The current thinking is to treat the cloud like just another stack; granted there are important differences and variations, but that’s the subject of another post – and maybe not even mine.