All Posts in Technology

|In: Architecture|Last Updated:

The Leaning Tower of Pisa, an otherwise unremarkable building, is famous for its bad foundation.

Some CIOs build their reputations on bad foundations, too. They insist on engineering shortcuts in the name of “business value” and “we don’t build technology for technology’s sake.” Some fail to understand that bad architecture creates a debt that will have to be paid off in the future, some do understand, and also understand that debt will be Someone Else’s Problem.

Others understand an important point about enterprise technical architecture management (ETAM) … one we’ll get to next week. But first …

The ETAM business case is that, as the first figure depicts, investing in engineering excellence and consistency now will pay dividends by reducing the cost of future projects.

It’s a perfectly reasonable premise.

If you’ve bought into the mirror-image concepts of federated architecture and buy-if-you-can/build-if-you-have-to application engineering, ETAM is a particularly big deal, because without it you won’t avoid the standard system interface progression — from “we need one,” to the familiar spiderweb, to the inevitable decent into the land of the hairball, where most of the effort in every applications-related project goes into making sure you don’t break anything.

“Federated architecture” sounds like an impressive solution. Sadly, though, while supporting technologies like EAI abound, no one has created an actual organized methodology for designing and managing system interfaces, with or without an EAI tool. If you’ve settled on a federated architecture, a large part of ETAM will be rolling your own.

The alternative to a federated architecture is building everything around a central software suite, usually ERP, that serves as the “source of truth.” Here, a lot of ETAM’s day-to-day impact will be making sure nobody touches the source code … that developers customize through either the configuration tools the ERP vendor has provided for that purpose, or through building satellite systems that hook into the core system through its defined APIs.

ETAM is like CapEx. Both are a matter of investing now to get a payoff in the future. In both cases what you invest in has to last long enough for its benefits to pay off the investment.

In the case of information technology, a lot of it does. “A lot,” though, is very different from “everything.”

Businesses don’t operate on a single timescale. In fact, they operate in four. As the second figure shows, they are:

  • Marketing time, where change in a slow-paced company might be on a scale of about a year, and in most companies ranges somewhere from a season to next month.
  • Product/service time: In many industries successful companies figure any product that’s been around more than three years is pointless; many operate as automobile manufacturers do, delivering new models every year.
  • Strategy time; which lasts as long as a reasonable business planning horizon. Unless you have a better crystal ball or operate in a more stable marketplace than most of us, three to five years is about it — beyond that there’s no real point in planning. Or even hoping.
  • Infrastructure time: Because most businesses have to invest significant amounts of capital in infrastructure … the physical plant, knowledge of the marketplace in which they operate, employee knowledge about how things really work (as opposed to managers’ knowledge about how they’re supposed to work), and its core information systems, their infrastructure has to last longer than their strategies. Much longer; ten years or more isn’t uncommon, as a look at your own legacy systems is likely to reveal.

Infrastructure creates an uncomfortable challenge for business planners. Those who create it have to make design decisions. These decisions will support some business strategies while placing significant constraints on others.

And because infrastructure lasts quite a lot longer than most business strategies, their design decisions cannot be “business-driven” in any serious way, no matter what platitudes business pundits like to utter about such matters.

Two more points about infrastructure and we’re done for the week. The first: Many additions to the infrastructure are unintentional.

Often, those who build these things expect them to be short-term improvisations intended to handle temporary situations. Then, temporary becomes business as usual, or they adapt and extend the improvisation for other, less temporary uses because that’s more expedient than the available alternatives.

The second: Even if you acquired every element of your infrastructure for free, that doesn’t make abandoning it for something else free, any more than moving out of a house someone gifted you to a better one is free.

Changing the infrastructure is always a costly proposition.

Comments

|In: Cloud|Last Updated:

Why go to the Cloud?

Don’t answer. It’s not a good question. The question to ask is whether you should go to the Cloud. And maybe where.

It might seem like a distinction without a difference. But it isn’t. Ask why and you assume the conclusion. It’s a dangerous habit, because once you do that, you gather information as ammunition, not to help you make a complicated decision.

I’ve been doing some pro bono work with a local non-profit — 25 wonderful, dedicated people, who work for far less than they could make anywhere else and run their information technology so long that if it were a car it would be an original VW Beetle, held together with duct tape and Bondo.

Their server is out of gas.

They have three different applications that have to keep track of contacts, with no integration except brute force, and no way to afford anything better. Beyond that, they’re pretty basic. MS Office. Outlook and hosted Exchange with bundled administration and support. InDesign. QuickBooks.

And a high-end networked copier/printer/scanner.

A perfect candidate to move to the Cloud.

Or so I thought until I scratched beneath the surface. It didn’t take much scratching, starting with two basics — identity management and printer queue management.

25 employees are enough to need Active Directory (or eDirectory, or LDAP, if they wanted to move to the Linux world). Right now these live inside the firewall no matter what else a company does with its architecture.

25 employees hitting a printer also means a server-mediated print queue.

Conclusion: They might not need a very big server, but they do need a server.

But surely they could do everything else in the Cloud, couldn’t they?

Sure they could, except that with a staff of 25, they just don’t need very much processing power. Storage, yes. Which, once they own a server, is cheap … dirt cheap. 2 terabytes of mirrored storage — enough to last them five years — would cost about four hundred bucks.

No, that doesn’t buy them the real-time collaboration they could get with hosted SharePoint or Google Apps. On the other hand, the most inexpensive hosted SharePoint they could get would cost them $10 per gigabyte per month.

As they’re a non-profit, they’d probably quality for Google’s free program for non-profits. Free, that is, other than what they’d have to spend to integrate it with Active Directory, recreate their current folder structure, migrate their data, and then pay for a higher-speed Internet pipe than what they currently need, because now every file retrieval is going to the Cloud and back. Estimated incremental cost: $600 per year — more than what they’d spend for 2 TB of on-site storage, once and done.

Which yes, they do need to back up. Add two backup drives, simple backup software (with encryption), and an employee willing to transport the backup drives back-and-forth and that’s taken care of for just about nothing, too.

Not fancy; more than good enough.

What to make of this?

They’re in the Cloud with hosted Exchange. The bottom line benefit doesn’t come from hardware and software savings, but from not having to employ a sysadmin to run and administer the sucker. Score one for the Cloud. Could they switch to gmail and Google Calendar? Sure, but then they’d have a migration to manage, after which they’d have to take on their own email administration and bring staff support in-house as well.

One of their three contact management applications is also in the cloud … a bulk emailing service. Same story.

So for an organization that should be an ideal target for Cloud computing, the Cloud turns out to be a case-by-case choice, not a strategic solution.

The more I look at the Cloud, the more concerned I am that its economic model is based on a seriously flawed assumption: That paying “by the drink” is more attractive than paying a lump sum and getting it over with.

No question about it — if you’re in a business where processing loads are unpredictable, varying from a low baseline level to very large short-term peaks, then the Cloud’s ability to provision resources dynamically is just the beverage you need.

I suspect, though, that most businesses will find, for most of the situations they face, what oenophiles have known forever: That when they pay by the drink, a glass of wine at a restaurant costs a whole lot more than paying by the bottle to enjoy a glass of the same fine wine at home.

That’s true even if they only drink half the bottle.

Comments