Financial-architecture and enterprise-architecture

“There’s no way we can do it”, he said with a sigh, brushing back his thinning hair and then resting his hand against his cheek, shaking his head in frustration. “We can’t make the business-case work: there’s no way round that damn great hole in the company-accounts. We’re screwed…”

It had seemed like a straightforward no-brainer of an EA task: discover, determine and decommission a whole bunch of long-outdated and known-to-be-redundant IT-systems, and save a huge heap of otherwise utterly-wasted money on unused licence-fees and the like. We’d been given the funds to find out what was really going on in the organisation’s IT-estate, and hence what we could safely cull. For the next stage, though, we were told we’d need to build a ‘proper business-case’: we’d need to be able to prove that what we’d save by switching things off would be significantly more than the cost of doing it. And that was where things came unstuck…

In fact, the business-case was obvious – or at least, obvious to anyone who’d actually looked at what we’d done. The potential savings in licence-fees alone ran into many millions of dollars a year – let alone the more subtle savings from re-using idle servers or freeing-up unneeded real-estate. By comparison, the costs were tiny: in some cases not much more than a few hours of paperwork, and overall perhaps a few staff-FTE for a few months at most.

But the sting in the tail was that requirement for proof, in terms of the organisation’s standard company-accounts. What we discovered, to our horror, was that the accounts themselves prevented us from doing so: the way those accounts were structured actually made it impossible to make almost any business-case at all for ever shutting anything down.

For the whole IT-estate, in essence the accounts-structure was this:

• six large systems listed as line-items, at tens to hundreds of millions of dollars each
• one line-item, labelled ‘Other’, for everything else, as an aggregate total of several hundred million dollars

That was it: no detailed-breakdown, no disaggregation, just that one line-item of ‘Other’.

Our work had shown that there was not much we could do with the big-six systems – the ones that had warranted their own line-item each. (Actually, there was, but we weren’t willing to risk it until we’d built enough trust on the smaller change-projects to get the executive to let us do it.) All of the savings that we’d identified and advised were in amongst the hundreds of ‘smaller’ applications and systems under the ‘Other’ category.

It took us a while to realise the extent to which we were trapped. Whatever we did, the costs of doing the work would show up in the accounts: every change-project had its own private line-item. But because there was no detailed breakdown for those ‘smaller’ systems, all of the savings would vanish into that all-consuming ‘Other’. The result: whichever way we framed it, we always ended up with what looked like a negative business-case – visible costs, invisible savings.

So yeah, we were screwed: no proof, so no further project.

But the blunt fact is that it wasn’t just us: the company was screwed. Screwed itself, more accurately: blocked itself out not just from one-off savings of many millions of dollars, but also from savings of millions of dollars every year from foregone software-licence and system-maintenance fees. That was almost a decade ago now, yet as far as I know, they’re still paying out those millions every year – for software and systems they don’t use, and some cases don’t even have any more.

No wonder their IT was so expensive, and no wonder the big IT-vendors so much loved the place: every time anything was added, it pretty much stayed that way forever, with huge ongoing costs, whether it was needed or not.

Screwed. Seriously screwed. Everyone. Because the financial-architecture was unable to support the enterprise-architecture.

Could we have done anything about it? Not really. Not in those circumstances. Which was kinda sad – and frustrating as hell, too…

And the reason why we couldn’t do anything about it was because of that darn stupid notion that enterprise-architecture was ‘just an IT-thing’. Courtesy of that delusion, our whole change-project reported to a junior IT-executive who reported to someone else who eventually reported to the CIO – in other words, way way too far down the pecking-order for the actual need. To get the necessary changes to happen to either the organisation’s business-case processes or, preferably, the accounts-structures as well, we would have had to have the ear of the entire executive – which is the level at which enterprise-architecture actually belongs, and why it belongs there, too.

Instead, we had the whole board complaining – from a far-off distance – that everything cost too much to run, and we should cut costs wherever we could. And then actively prevented us from doing just that, via a really stupid bit of financial-architecture design and implementation.

Sigh…

That wasn’t just a one-off, by the way: once we break our enterprise-architectures out of the IT-centric box, these financial-architecture problems can be seen popping up all over the place.

One of my favourite (if that’s the right word?) examples is actually a naming-problem, with rather strong echoes of the problems that arise from the disastrous mis-labelling of qualitative requirements as ‘non-functional‘ – creating the potentially-lethal delusion that those requirements don’t really have any function, and therefore don’t matter. In this case, it’s the partitioning of business-units into profit-centres and cost-centres – creating a similar delusion that so-called ‘cost-centres’ don’t contribute in any way to business-profits, and therefore should be considered as prime targets for any cost-cutting exercise. As Larry Myler put it, in an article in Forbes Magazine:

If you work in a “cost center” within an organization you might be feeling a little like an ugly stepchild, metaphorically speaking. You’ve probably heard your department referred to as a drain on profits, a burden to the P&L or, simply, as overhead.

Yet it’s a really dangerous delusion, because, as Larry Myles explains:

Actually, this thinking is somewhat absurd, because if you were to eliminate any one cost center from any given organization, that company would cease to make a profit.

The distinction between ‘profit-centre’ and ‘cost-centre’ only appears in and as a result of linear-thinking. The only difference between them is that a profit-centre has a direct connection to business-revenues (and hence nominal business-profit), whereas a ‘cost-centre’ has only an indirect connection to revenue – and to linear-thinking, indirect-connections are all-but-invisible, so much so that often deemed not even to exist. Yet the moment we use systems-thinking approaches – a whole-of-system view – then that distinction all but disappears: exactly as Myles observes above, all of the business-units are needed if revenue is to be obtained and profit to be achieved. Hence whenever enterprise-architecture needs to be involved in any cost-cutting exercise, we need to beware of this neat little booby-trap placed in our path by badly-designed financial-architectures, and instead remember to review costs from a systemic perspective, not simply in terms of linear distance from revenue-streams.

Best stop there, I guess – but something to think about, I hope? Comments, anyone?