All Posts in Technology

|In: Industry Commentary|Last Updated:

Here are some simple rules of thumb to use when interpreting any published statistic:

  • If it appears in a refereed scientific journal, you can rely on the data collection and computation — the statistical significance.
  • If the results are confirmed and accepted by the scientific community you can also rely on the researcher’s interpretation — the importance.
  • If the statistic appears anywhere in the business press, you can apply the principle of cui bono to determine who paid for the study and decided in advance what the results should look like.

Business has become obsessed by metrics, which would be okay if most business managers (1) were good at mathematics; (2) had the time to think carefully; and (3) started with goals instead of starting with the desire to end up with a number. And so it came to pass that Computerworld published an article recently titled, “Proving SOA Worth Is a Big Challenge for IT: Tools emerging to manage, measure benefits of the complex architecture.”

Early on, the article says that managing SOA is more difficult than the equivalent client/server or Internet projects (the comparison with object-oriented techniques was, bafflingly, omitted). Does it strike anyone else as peculiar that anything built on a core technology called the “Simple Object Access Protocol” (SOAP) should be described as complex and difficult? Maybe the “Simple” in SOAP refers to the objects, not the protocol — SOAP, in this interpretation, would only be appropriate when accessing simple objects.

But I digress. About those tools for assessing the value of the technology: One anonymous technology executive cited in the article is planning to use technology from AmberPoint to “… prove the value of the 100-plus Web services it has in place today.”

I sure hope his bonus doesn’t depend on it, because it isn’t going to happen. You can deploy monitoring tools to tabulate the number of times a Web service is invoked, and workflow tools to detect and register them, but unless you equate activity and value, that’s as far as you’re going to get. And anyway, his description was more about increasing the level of service re-use than about proving value.

Good plan: Increase re-use first, report the value of re-use second.

You have to feel sorry for the guy. He explained his situation like this: “… only 20% of the services were being registered by the company’s 1,500 developers … At the same time, even fewer consumers were logging information about how they would be using the services.”

Maybe this all makes sense. Maybe it’s okay that developers don’t follow documentation standards, or that the documentation standards don’t require registration of Web services that go into production. Maybe it makes sense to try to increase service re-use through technology instead of methodology.

And maybe it really is tough to document SOA’s value.

Or maybe I’m about to save you a lot of pain and effort. Here’s how to go about it:

Step 1: Estimate the cost of the next ten projects in the queue using your current architecture.

Step 2: Estimate the cost of the same projects using SOA.

Step 3: Subtract the results of Step 2 from the results of Step 1.

Step 4: Compare to the up-front cost of implementing SOA.

Enough sarcasm, fun as it is. After all, the poor souls cited in this article were dealing with a tough political challenge — justifying investments in core technologies about which business executives neither know anything nor care to.

When it comes to IT, most business executives care about only four parameters: Cost, delivered value, successful project completion, and system uptime. If they’re really sophisticated, they’ll count system slowdowns against you when assessing uptime.

SOA won’t improve uptime. That leaves some combination of decreased cost, increased value, and improved successful project completion. If that’s what you promise, you’d better “encourage” your developers to register the services they program. Oh … and require use of methodologies that enforce service re-use.

Here’s advice that’s even more important: Don’t explain, under any circumstances, that SOA is more complex than the technologies it replaces. That might lead to a hard-to-answer question — how is it that a more-complex technology will let you deliver results more quickly.

I’m sure there’s an answer. You just won’t be allowed to provide it, because the question will be purely rhetorical.

Comments

|In: Leadership|Last Updated:

The word is schwerpunkt (and a round of applause to regular correspondent Sean Murphy for telling us about it). Add it to your vocabulary and impress your friends. It encapsulates the concept discussed in last week’s column — that the difference between a dent and a hole is focus.

This week’s work is schmear. It’s what cream cheese is on a bagel — spread out. Some things are better spread out. Schwerpunkt cream cheese would be hard to swallow.

If the schwerpunkt of last week’s column wasn’t clear, let me make it so now: It isn’t that you should concentrate all of your efforts on just a few high-profile initiatives. Far from it. Doing that will cause you to miss a whole lot of low-risk, high-benefit investments in business improvement.

Unless your company is so badly run that it has choked the creative thinking out of everyone, you have pent-up demand — ideas generated in workgroup after workgroup on how to run things better. Want to find them? Scan your network shares for Excel spreadsheets.

(Sidebar gripe #1: Over and over, I hear IT professionals complain about people in the business using Excel as a database. And, over and over again I also hear IT professionals explain how dangerous it is to deploy Microsoft Access to people in the business. Please, folks — one or the other, but not both.)

Excel is the general-purpose tool business users and managers use to keep track of task assignments, figure profitability, keep track of assets, forecast spending, keep track of work in progress, and otherwise automate — clumsily, perhaps, but still automate — a thousand bits and pieces of what they do.

(Sidebar gripe #2: Isn’t it pretty obvious by now that the world needs a good, general purpose, configurable tracking system development platform? I’m not talking about full-blown business process management (BPM) software. I’m talking about something inexpensive that lets a business manager lay out a series of steps, define what triggers the transition from one step to the next, track status within each step, and automatically maintain a history of each job that progresses through the steps.)

As I was saying, many of these bits and pieces are supposed to be temporary solutions, which persist until IT gets around to doing them the right way. At a rough guess, I’d estimate that something like 18,542,147 business managers have, by now, created 96,834,549 tracking systems in Excel, and every one has wished they had something better. And no, Bugzilla doesn’t really do the job either, although using it for this purpose is probably something less of a kludge than using Excel.

Which brings us to the IT schmear. That’s what you need to help people in the business. You need to reserve a certain amount of your total discretionary labor budget to help lots of people with their small needs.

And don’t try to get fancy with governance. Fancy governance is for big, risky requests. Too many companies try to force their one and two-week “project” requests through the same governance process they use when deciding whether to replace their legacy environment with SAP. All that does is bog things down: Investing 60 hours to decide whether to approve a 30-hour request is a great way to make sure nobody submits a 30-hour request.

(Sidebar gripe #3: I like agile methodologies. They have a lot going for them. But why haven’t any of their proponents explained what’s best about them — that they turn big projects into the equivalent of a big pile of 30-hour requests, virtually guaranteeing completion and at least semi-useful results.)

Where was I? Oh, yes, you want lots of people to submit 30-hour requests, because unlike big IT projects, the completion rate for 30-hour requests is something approximating all of them. Screen out the obvious duds, but don’t spend much time or effort on it. Enough will be good ideas that in the aggregate they’ll pay for themselves without much trouble.

Don’t try to measure the value either. It’s like trying to measure the value of changing the oil in your car — the value is there, but try proving it using modern accounting methods. Heck, try applying the typical, ROI-driven “best practices” IT governance to oil changes and see how far you get.

It’s about balance. When it comes to achieving large-scale, risky change, concentrate your forces. But when it comes to surviving until the future gets here, you need a different set of tactics.

Place your schwerpunkt on schmearing.

Comments