All Posts in Technology

|In: Industry Commentary|Last Updated:

As programmers age, they face age discrimination — true or false?

On the surface this appears to be true, but when you accept superficial explanations you pay the price. In my experience, both forward and reverse age discrimination are prevalent, except what’s really going on is a mismatch between expectations and you. Managers expect employees to progress. If you’re 55 years old and still want to write code, that’s out of line with expectations. If you’re 23 years old and want to succeed at executive-suite strategic consulting, good luck — gray hair and exposed scalp is an unstated, but vital qualification.

When it comes to evaluating Web services, the latest next-big-thing in information technology, gray hair and exposed scalp helps. Assuming, of course, that history serves as guide to the future.

For example:

The vision of Web services is that you’ll assemble any application you like by stringing together publicly available components from multiple vendors. The use of standard interfaces and ubiquitous Internet protocols will make this fast, cheap and easy.

Don’t bet the farm. It could happen, I suppose, assuming:

  • Software vendors make a 180 degree shift in support policies. Right now, if you have just two vendors and one problem you solve it yourself, because your vendors expend all of their efforts pointing fingers at each other while telling you they don’t support your configuration.
  • Vendor and product selection becomes quick and simple. Right now the process of selecting a software package from a single vendor requires serious effort. With Web services you’re assembling your application from the work of dozens of vendors. In my experience, comparing multi-vendor solutions is more complicated than single-vendor solutions, not less.
  • Trustworthiness is omnipresent. At InfoWorld’s recent Next Generation Web Services conference, a security panelist made a telling point: Just because a component advertises its behavior through UDDI (Universal Description, Discovery and Integration) doesn’t mean it’s telling the truth. Even ignoring the likelihood of malfeasance, we’ve all encountered DLLs that don’t behave as advertised. Why should publicly available components be any different? Hmmm?

Web services is a promising architecture. Many of us expect it to be important in the not-too-distant future. The tricky thing about the future, though, is that it hasn’t happened yet.

The best guide we have is history. So far, the Web services hype factory has ignored its lessons.

Comments

|In: Industry Commentary|Last Updated:

Long before ManagementSpeak graced these pages, Mad Magazine had mastered the art of translation. My favorite:

What they say: It isn’t the money. It’s the principle of the thing.

What they mean: It’s the money.

To run IT, you need both money and principles, of course. Among the core principles for running a typical IT organization:

  • Buy when you can, build when you have to.
  • Minimize data redundancy.
  • Maximize software re-use.

Pick two.

If you buy when you can and build when you have to, you’ll use applications from more than one software vendor, your databases will be tied to your applications, and you’ll have redundant data. On the other hand, most vendors now write to an n-tier software architecture, which means you can get at the underlying logic, so you achieve software re-use.

Want to minimize data redundancy or maximize software re-use? Build everything yourself, or at least everything you can’t get from your primary ERP vendor. You’ll have full control over your code, too which gives you a fighting chance at re-use. Too bad you can’t afford either the budget or time to choose this option.

Web services promises to eliminate these trade-offs. The use of components instead of full-blown objects means logic is easily accessible while data is still defined separately, and the use of HTTP and XML means vendors can write general-purpose components and make money by renting them out. That means (blare of trumpets!) you’ll easily assemble enterprise applications out of commercially available components from all over the world.

It won’t happen — not because of technological obstacles, but because an enterprise application is more than a collection of general-purpose utility routines.

Software is an opinion about how a business should run. It’s expressed in code rather than English, but its an opinion nonetheless, so when you buy software from multiple vendors you’re buying differing opinions. Interfaces are where they clash. To state the obvious: Technology can’t resolve a difference of opinion.

Imagine you’re a retailer. Web services can solve some irritating problems for you, like managing the sales tax logic in multiple states, so as CTO you decide to adopt the architecture to run your whole business.

That’s when you discover: The different vendors from whom you’re going to rent components disagree on some very fundamental issues, such as how to define “customer.” One considers “customer” to be an individual. For a second it’s a household. A third, oriented toward hardware stores, perhaps, remembers that building contractors buy a lot of stuff and use a definition that includes companies and everyone in the company authorized to make a purchase.

Think you’ll just ship customer data into and out of components from all three vendors with impunity?

Think again.

The grand vision of Web services is that easy integration of independently engineered components will happen by just connecting them together like Tinkertoys. The reality: Integration is hard, even when designed into an application.

It won’t happen by accident, grand visions notwithstanding.

Comments