All Posts in Technology

|In: Leadership|Last Updated:

The IT industry has not approached the subject of service and how to measure it with much subtlety. Quite the opposite — we simply established service level measurement as a sort of tradition, to be respected and adhered to whether or not it fits the situation very well.

Service levels originated in the telecommunications industry, where customers needed some way beyond “I hope the lines stay up” to define and manage vendor performance. From this modest beginning sprang more consulting fees than you can shake a stick at, if shaking sticks at consulting fees is your idea of time well spent.

Service levels never strayed far from their origin, though, which means the hidden assumption that providers are vendors and users are customers is not very well hidden. But as long-time readers of Keep the Joint Running know, when internal IT defines itself as a vendor to its internal customers, it stops delivering the advantages to be had from working with internal IT and replaces them with the disadvantages of working with a second-rate outsourcer (the first rate ones being, by definition, in actual for-profit business with multiple clients).

Service levels are, if you aren’t familiar with the concept, two-part measures. The first part defines the minimum acceptable level of performance. The second tracks how often a provider meets or exceeds that performance level. It’s the reason I’ve been skeptical of their usefulness when you aren’t a vendor providing contractual protections to customers: You should be trying to improve performance while reducing variability — goals measured by entirely different formulas (for more, read “Measuring service,” Keep the Joint Running, 2/16/2004).

Service levels do have their place within internal IT. They are, as it turns out, just the ticket for whatever isn’t important enough to continuously improve. More precisely, they’re the right measure for every parameter of a system that isn’t an optimization target.

You can’t optimize everything. The reason is well known: There comes a point in any optimization process where trying to further improve one system parameter — say, cycle time — can only come at the expense of another system parameter, such as defect rate (unless you change the game by instituting an entirely different methodology or process design that is — if you do, all bets are off).

That isn’t necessarily the wrong choice to make. It should, however, be an informed choice. That’s where service levels come in. First you choose the one or two system parameters that matter most — whose performance you’ll work to continue improving. Then you establish service levels for the rest to make sure you don’t kill them in the process.

An example, to illustrate: You institute a standard software quality assurance methodology. The goal of the process is, unsurprisingly, to reduce the number of software defects that make it into production (that is, the goal is to improve quality). That’s the most important optimization parameter. And, you decide, you want the process to have a short cycle time, to the extent you can do so without jeopardizing quality.

That leaves four process parameters unspecified — fixed cost, unit cost, throughput, and excellence (which in this case means adaptability). And since they’re unspecified they’re likely to get out of hand, because …

The easiest way to improve quality is to increase the number of test cases. That, however, increases cycle time. To avoid that outcome you’d have to add staff. But that increases unit cost. Is that acceptable or not?

The answer to the question is defined by a service level — in this case, the maximum acceptable level of spending per deployed module, or some similar measure.

Or, you decide to improve quality by implementing some testing software. That lets you explore more test cases, and to automate regression testing and stress testing, without adding staff.

The software isn’t cheap, though, so up goes your fixed cost. Is that okay? It depends on the service level associated with fixed costs, sometimes referred to as the capital budget.

In IT we face these trade-offs over and over again. Tune servers for performance and they fail more often. If performance is your goal you need a service level for reliability, or vice versa. Tune servers for performance while improving reliability by adding redundancy and up go your costs. That’s right — your budget is just another service level.

It’s really pretty simple. Decide what matters most and improve it. Set boundaries on everything else so it doesn’t get out of hand.

We sure do make a big fuss over it all, though, don’t we?

Comments

|In: Industry Commentary|Last Updated:

Accenture has plowed $450 million into services oriented architecture (SOA) technology. With that much in the game, couldn’t it have done better than a talking head in its downloadable video?

(Truth In Journalism department: I stopped watching after either five minutes or eternity had gone by — I’m not sure which. Maybe some graphics appeared after that. If so, it was way too late.)

Accenture divides SOA implementations into four levels. The first level is dabbling just enough that a few vendors can include you in their “The following companies use our products” logo page in their PowerPoint presentations. The fourth level has something to do with business process flexibility and becoming Fully Buzzword Compliant (FBC).

(Truth in Journalism department again: I’m working from memory. By the time the video got to this subject my eyeballs had glazed over so my recall on the details might not be perfect.)

I shouldn’t be so sarcastic, I suppose. Level Four sounds suspiciously like a position KJR adopted a long time ago: That your focus should always be on how projects will improve the business, not on implementing the technology.

There is one clear difference, though. Lots of companies follow the KJR approach. According to Accenture, no company, including Accenture, has achieved SOA level four.

But Accenture knows how to get you there and will be happy to help.

Here’s what I don’t get: SOA was supposed to make things easier.

Let’s review. First we had assembler, and assembler jockeys who could talk to business people, figure out what they needed, and churn out huge amounts of write-only code that still somehow let the business move forward.

Then Admiral Grace Hopper invented COBOL to make things easier. Which it did until someone invented structured programming to make it harder again by making sure COBOL jockeys weren’t allowed to talk to end-users anymore.

After that, Codd and Date invented the relational database management system (RDBMS) to make things easier. Once everyone got over the need for ideological purity and accepted indexing technology, RDBMSs did make things easier, too. After awhile, even relational design stopped being an interminable obstacle. Someone must have goofed here. The most likely mistake: Data designers actually talk to end-users. That’s my guess, at least.

Somewhere in here, Fran Tarkenton gave up running toward his own end-zone to avoid getting tackled and invented Computer Aided Software Engineering (CASE). CASE was supposed to make things easier, but it never actually worked, so the methodology that started to evolve around it — making sure developers never talked directly with end-users — never became important.

CASE never got fixed, probably because right about then someone invented object-oriented programming (OOP) to make things easier. OOP was supposed to be more natural than structured programming, because objects were business thingies which business people could understand more readily.

OOP would have made things easier too — if for no other reason than because unlike COBOL, OOP provided “encapsulation” which means the subroutines that were (ahem) routine to FORTRANers finally made their way into mainstream IT.

Fortunately, the methodologists came to the rescue again, giving us Object Oriented Analysis (OOA) to make things harder. Not to cast aspersions on a family of methodologies with many fine attributes, but OOA does have its drawbacks. One is that it generates enough paper to decimate the Amazon rainforest. A second is that its terminology and artifacts are impenetrable to the average string theorist, let alone merely bright business managers.

And of course, OOA makes sure developers don’t talk to end-users. OOPs.

There’s a pervasive myth that technical people can’t talk to non-technical people. In this mythic universe technical professionals only marry other technical professionals. They give birth to little newborn technical professionals, go to churches, synagogues, mosques and temples with congregations composed solely of technical professionals, and have backyard barbecues only technical professionals attend.

This must be true, because otherwise, the moment technical professionals leave the office they magically acquire the ability to speak to everyone else, only to become selectively aphasic once more when the next workday begins.

I know far too little about SOA to say what I’m about to say with such certainty: I’m willing to bet the methodologies that are starting to envelop SOA make sure developers don’t talk directly with end-users.

Otherwise, SOA would still be making things easier.

Comments