All Posts by Bob Lewis

|In: Industry Commentary|Last Updated:

Somehow, we printed, “The money saved the dwarfs that spent on remediation.”

I was explaining why we used two-byte year fields in the first place, and meant to point out that because storage cost so much when we wrote our legacy systems, the money saved was much greater than what we spent to fix the problem.

Instead, an extra “the” put me in Middle Earth, doing my Gandalf impression. (To be honest, I like the printed version better than the original, for reasons I can’t begin to explain.) My apologies if I accidentally offended any low-altitude readers.

A legacy system is like any other corporate asset. You invest in it, you maintain it, and you maximize the returns you get from it. With all the money you (and the dwarfs) spent remediating your legacy systems, you had better get some extra leverage from them, don’t you think?

One way to do this is web-to-host integration — products that take functionality from your legacy systems and make it available through a browser. Like so many other subjects in information technology, though, the obvious solutions are often short-sighted.

Go back to the basics — the need for IS to manage technical architecture. Technical architecture management is a core discipline for IS these days, as described in this space over a year ago (from 8/17/98 through 10/5/98). You’ll recall that your technical architecture consists of three layers: Application, Information, and Platform. Business value comes from the Application layer. Applications make use of Information (which includes both databases and unstructured data), and runs on the Platform layer (which includes, among other items, hardware, networks, operating software, and database management systems).

Let’s approach web-to-host integration from an architectural perspective — a process that begins by describing the application-layer functionality you need and then traces a path for its implementation that maintains as much simplicity and design elegance as possible in the lower layers of the architecture. What functionality are you looking for?

You may be looking for a less-costly way to deliver 3270 screens to your end-users, figuring you can simplify your platform layer by leveraging your intranet. If so, congratulations — you’re taking an architectural view.

On the other hand, you may be trying to export legacy functionality to your company’s web site — perhaps to encourage customer self-service, or as part of a supply-chain optimization effort.

If so … you’re about to make a big mess.

Your goal is to export mainframe functionality via the Web. Beyond any shadow of a doubt, though, you’ll also need to export that functionality through other channels as well — through the Web, for sure, but also through interactive voice response (IVR), your call center, possibly through tools customized for your direct sales force …

Get the idea? Once you start thinking you need a web-to-host integration solution, you’ll start thinking you need a separate host integration solution for every other category of application. That’s bad enough.

What happens next is worse. Since your Web site, call center, and IVR system will have separate host connections, they’ll also have their own, separate, possibly inconsistent host integration logic.

Host integration logic belongs in the mid-tier, where all applications … Web, call center, IVR, back-office … can use it. That’s what Enterprise Application Integration (EAI) systems are for. The case for EAI is compelling: The alternative is to create a spiderweb of separate interfaces between each legacy system and every front-end application. Do this and managing the impact of legacy system maintenance is a polynomial nightmare.

EAI isn’t simple. It is, in fact, a very difficult technology to implement well. In a first-class EAI implementation you have to figure out how to use host wrappers and integration tools to map your legacy systems into a well-designed object class hierarchy, both to present them and to “persist” any updates.

A good EAI implementation is very hard. The alternative, though, isn’t hard … it is, in the long run, completely unworkable.

Comments

|In: Career Management|Last Updated:

News flash!

In another case of psychologists proving what we’ve long suspected, Justin Kruger and David Dunning, publishing in the Journal of Personality and Social Psychology, demonstrated the inverse correlation between actual ability and self-assessment.

The better employees think they are, the worse they actually are and vice versa.

Armed with this little factoid, I expect battalions of mediocre programmers to immediately try to improve their ability to write good code by adding humility to their conversation. While the humility, however insincere, will be a welcome change, it will start a tiresome variant of the decrepit “You only thought I knew that you knew that I knew that you knew” gag.

But I digress.

I just read another version of the “CIOs need to know the business” article. I think there’s just one article on the subject, and when a writer is feeling tired he pulls it out, shuffles some paragraphs around, e-mails it in, and goes back to sleep. They’re all the same, really. They make the hoary point that businesses don’t want technology for technology’s sake — technology must serve a business need, and successful CIOs will embrace this concept.

Some insights are more startling than others, I guess. But before we go on, let’s all hold hands and chant together: “Yes, CIOs must know the business, and never propose technology for technology’s sake.” Maybe if we say it loud and proud a few times, everyone in earshot will understand that we’ve fully grasped this concept, and we can all move on to the next one.

The next one, made many times in this space, is that “knowing the business” doesn’t begin and end with abstract notions like strategies and business models. The most important part of knowing the business is knowing the interests, hot-buttons (and cold-buttons), pet programs and pet peeves of every important decision-maker in the company. At least half of an average CIO’s time is spent selling. It’s internal selling … to the board of directors, CEO, senior executives, middle managers … but selling nonetheless.

If you don’t like the idea of having to sell internally, find a different word that describes the process of persuading others to adopt your concepts, in the process adding money to your budget.

If it looks, waddles, and quacks like a duck, it’s a duck. If it looks, smells, and tastes like selling, it’s selling.

To sell effectively, you need to understand your prospects on an empathic level. You need to understand the business, formally, politically, and personally.

Why, oh why do so many seemingly sensible people jump from here to the ridiculous notion that the CIO can delegate the “understanding technology” part of running IS to subordinates? Would anyone reach a similar conclusion down the hall a few doors, and figure the CFO doesn’t need to understand accounting, just “the business”?

Of course not. Of course, they’d probably reach the right conclusion for the wrong reason, explaining that at the end of the day … or at least the fiscal year … the money is the business. Robert McNamara, overconfident of his ability (sound familiar?) due to his business resume, used a similar thought process in pursuit of victory in Vietnam, running a metrics-driven war in which relative body counts (profits) mattered more than the formulation and execution of strategy and tactics.

CFOs need to understand finance and accounting because they run that part of the business and they need to understand the discipline. CIOs need to understand information technology because that’s what they’re responsible for. This isn’t a complex concept, nor should it be controversial.

Go back to the idea that CIOs spend a lot of their time selling. What do really great sales people do? They paint a persuasive vision of how great your world will be once you’ve incorporated what they’re selling into it.

What’s the first step? Understand what you’re selling. In the case of a CIOs, that’s information technology. Without that knowledge, no matter how good you are at step two — understanding your prospects’ world — you’ll have no way of progressing to step three: Putting that knowledge and your product together.

Comments