Part 2: The four hallmarks of an effective CIO: Architecture

Last week here on Planet Mainframe I introduced the idea that a CIO must excel in 4 areas: Alignment, Architecture, Agility and Ability, and we looked closely at Alignment. This week we have a closer look at what Architecture in IT is all about.

2. Architecture

Architecture in IT refers to a coherent, consistent set of high-level, slowly changing design principles that guide the design and construction of IT solutions. An IT Architecture should be—but often isn’t—a set of written documents, analogous to the blueprints used when designing a skyscraper. While written plans are good, it’s even more important that a set of overarching, widely understood, design principles are followed when designing and building IT Infrastructure and Applications. Along with coordinated Infrastructure and Application Architectures, IT should have an “Operational Architecture” that defines how the infrastructure and applications are operated, maintained, monitored and modified. And there should also be an “IT Governance Architecture” that defines how things get done in IT: budgets, project approvals, change requests, etc.

It’s not my intent to bore you with the details of these architectures, which can get quite complex and arcane. Rather, I’ll explain the benefits of architectures and provide insight into the signs of good architectures.

To quote the late Yogi Berra, “When you come to a fork in the road, take it.” Without guiding principles, one must stop at every fork and carefully consider the implications of each possible choice. An Architecture helps speed routine decisions by providing guidance. For example, ‘We’re a Microsoft Windows Server shop’ means IT has chosen the suite of Microsoft products to be the default choice when adding a server. How IT arrived at that guiding decision varies: perhaps a consultant was engaged; perhaps someone realized most of our servers were Windows servers; perhaps we bought a company that successfully used Microsoft Windows servers. I contend that the primary value derives less from WHAT was chosen, and more from the fact that a choice was made and documented/ communicated. (This assumes that the choice was made rationally. I once worked for an Asian multinational whose architecture was made up of hardware that wasn’t sold or serviced in the US. I actually had to fight for a US standard rather than accept that my spare parts AND trained technicians would be in London).

Why is an IT Architecture important?
Several reasons:

• Reduced complexity – A typical IT solution is composed of many pieces of hardware and software. Every component has to work with its neighbors (e.g., running the Macintosh operating system on a PC designed for Windows might be possible but it won’t be pretty). Establishing standard pieces of hardware and software, and standard models/versions of each, means we can pre-test and often pre-assemble parts into a smoothly-working whole. Another, and not insignificant complexity comes from working with multiple vendors. Having the vendors in place and having good working relationships with each vendor simplifies problem diagnosis and release (version) upgrade management.
• Reduced cost – Unless your organization spends a large fortune on IT, having a scattershot approach to IT purchasing reduces procurement leverage and thus increases cost. Having a standard set of approved components means you stock fewer spares, send techs to fewer classes, and write fewer user manuals.
• Reduced training – User training is a huge—often overlooked—part of every technology deployment budget. The more standardization, the fewer different training classes users need to take.

It is important to note that having an Architecture DOES NOT mean absolute conformity no matter how foolish. It just means that absent a compelling reason for deviation, the standard parts will be used. The best definition of “compelling” I’ve found is cost-based: if a business unit wants to violate the architecture, are they willing to bear the fully-loaded increased cost of that violation? If Marketing wants Macs instead of PCs (and they often do), let Marketing pay the increased cost of buying, configuring and supporting Macs. Note the phrase “fully loaded”: if a business unit wants to use a different G/L than everyone else, it’s not just writing a check for different software. It’s paying for the increased accounting cost, data warehouse integrations, internal and external audit costs, and so on. If the architecture violation makes business sense on that basis, why not allow it (and report “violation surcharges” clearly, so the ongoing cost can be reviewed periodically).

Architectures aren’t an exercise that’s done once and left to gather dust on a shelf. A useful architecture needs to evolve (according to an architected process, of course) as technology advances and as vendors come and go. An architecture also evolves with the organization: if we buy a company that has something different, its architecture must be integrated within our own. If there’s good reason for supporting two different “allowed” architectures for a while, that’s acceptable (but the architectural evolution process should allow for a “go-forward” architecture that provides clarity for changes as old hardware and software is replaced).

Architecture is good, because it frees you up from many routine decisions. But organizations too focused on architecture for its own sake can become bureaucratic and slow-moving.

Which is why the counterbalancing force to Architecture is Agility, which we’ll examine next week on Planet Mainframe.

Last week’s post: Part I: The four hallmarks of an effective CIO