Your colleagues will lie to you: An enterprise architect's life

Enterprise Architects … well, among other things they design and build corporate infrastructures. It's very easy, though, for these highly technical masters of electronic wizardry to concentrate on making the technology work at the expense of the more tedious corporate governance stuff.

Here are my favourite five things that are often forgotten but which are essential to make sure that your infrastructure is as effective in a business sense as it is in a technical one.

Software licensing

You might think this a slightly odd one to start with, but it's easy to forget software licensing – particularly in an infrastructure sense. In all but the smallest companies one tends to use volume licence programmes for things like server operating system keys (you don't have 25 servers with 25 different WS2012 keys, do you …?), which can make it easy to bust your licence limit and get a nasty shock when the vendor comes and audits you. Similarly I've seen more than one company buy maintenance and upgrade protection for one switch, one router, one wireless access point, and so on so that they get access to new software versions, but then use those newer versions on the entire estate. So be rigorous about licensing.

Change Management

You can always tell an organisation that doesn't have proper change management. They start with an infrastructure that works really well, whose cabling and rack layout looks great, and where it's easy to trace faults.

Three months in and the cabling is starting to look a bit shabby, the monitoring system gets more and more yellow and red blobs in place of the previous green ones, and users start complaining. A year in and you're seeing more and more unplanned outages because any resilience you built in at install time has gone a bit wobbly, supposedly identical master/slave pairs have become inconsistent, and stuff just isn't reliable any more.

Although change management sounds like it is there to manage what changes happen to your systems, in practice that is its secondary function. For me, the main benefit is the scrutiny applied to your change requests makes you consider properly what you're doing: it gives checks and balances so you minimise the chance of forgetting something.

I wish, for example, that I had a fiver for every change request I've read that had an implementation plan and a rollback plan but no test plan. How can you know whether to roll back if you're not defining the test plan and hence the success criteria for the change?

Without exception, in my experience, the infrastructures of organisations that have change management work better than those in organisations that don't.

Authentication services

Centralise your authentication services. There are few things that irritate me more in an IT infrastructure than having a thousand and one different devices with a thousand and one individual user databases. I once inherited a world where one of the offices had over a dozen wireless access points – and to change the “guest” wireless password required a change on every single unit.

Before long they'd become thin access points – so there was a central controller cluster and hence a single place to change the password. Use TACACS+ as the authentication mechanism for the management interfaces of your network devices, and ensure that when it comes to user authentication you do as much as you can to authenticate them against your core directory service. It's normal to have one or two specialist systems that just can't use AD, LDAP or whatever your authentication server uses, but only allow things to remain stand-alone when you absolutely have to.

Configuration management/monitoring

Configuration management is all about having centralised systems in which you define the configuration of your systems and then propagate it. The Group Policy mechanism of the Windows Server family is an example of a configuration management system (even if you'd not thought of it as such): you define policies at various levels of granularity and then it's applied across the estate for you.

Likewise there are plenty of config management systems for network equipment, and in these days of Software Defined Networking – OpenStack and all that – config management for servers, storage and networking kit is gradually converging into a single entity.

Even if you don't have configuration management, spend a few quid on configuration monitoring – by which I mean have a mechanism for automatically downloading the configuration of every device you own (at least those whose config can be downloaded and represented in text form) and comparing them day by day. It gives you an automated way of keeping a comprehensive audit log of your systems' configuration changes. And it's a great way of knowing your colleagues are telling you porkies when they tell you nothing changed.

Formal conformance

Even if your company doesn't currently have any formal certifications (PCI-DSS, ISO9001, ISO27001, and so on), you may well do so one day. And even if you won't, all of the above can be used as a reference point for best-practice ideas. To pick an example, if you think PCI-DSS will become relevant at some point soon, you'll want to design the infrastructure so that the parts that process and transport payment card information are segmented from the main network; although such segmentation isn't a formal requirement of the PCI-DSS audit, if you don't segment then your entire network will be subject to audit rather than just the bit that handles the PCI-DSS-related items.

Design your infrastructure with formal standards in mind, and in the average case it'll be more robust and less liable to problems if you hadn't. ®