It looks like nothing was found at this location. Maybe try a search or browse one of our posts below.

Electric fish are fascinating critters (at least to me — regular readers will remember I spent years studying these suckers). One of their more remarkable features is their electric organ – the gadget they use to generate electricity. It started out as a muscle. Aeons of evolution eliminated its ability to contract while increasing the amount electricity its cells generate.
That’s how evolution works — it grabs whatever is convenient and adapts it for whatever use is called for.

We do a lot of this in IS as well, continually adapting and evolving our legacy systems, databases, and computing platforms to whatever new requirements pop up. And this is a good thing to do.

Eventually, though, we find ourselves in evolutionary dead-ends, where our adaptations, kludges, shortcuts, and patches turn into barriers that prevent further change. Mother Nature handles this situation through extinction. You’d probably prefer a different strategy.

The alternative to evolution is design, and design is what distinguishes architecture from gluing a bunch of stuff together wherever it happens to fit. In this, the final article in our series on technical architecture (hey, don’t cry!), we deal with design.

Architects, whether designing IS infrastructures or office buildings, have to be both technically and artistically inclined. So far we’ve talked about the analytical, technical aspects of architecture.

Good designs, though, are as much a matter of art — aesthetics — as of technical prowess. Aesthetics pays off, because ugly designs turn into unreliable, clunky, nasty implementations. It can’t be logically proven, but it’s so nonetheless.

Defining aesthetics is more or less impossible, though, because aesthetics is mostly a matter of taste. You still need to make consistent design decisions, though. To do so, develop a set of clear, consistent principles designers can use as a starting point. And to develop good design principles, you need to understand the important design issues.

A design issue is any technical problem you need to solve or computing function you need to deliver on a regular basis. For example, physical connectivity is a design issue. You have several design principles to choose from: One connection per end-user device with network gateways to resources as needed; multiple end-user connections (for example network, modem and desktop TAPI); or ad hoc decisions as seem appropriate for each situation.

I’m a big fan of a single connection to the desktop and doing everything through the network, but that may not be the right solution for you.

Take another design issue: How to handle data redundancy. You have several design principles to choose from. You can: modify your systems to eliminate redundancy; define master/slave relationships among your data stores and periodically resynchronize everything; build technology that propagates update transactions to all redundant data, keeping everything synchronized in real time; or live with the mess and not worry about the redundancy. Pick one and don’t lose your guts.

In fact, for each design issue the most important thing is to pick just one design principle and live with it — and also, make sure your design principles are consistent with each other.

Which brings us to standards. Many design principles establish the need for a standard. In fact, every standard you establish should stem from a design principle — otherwise you don’t need it. For example, you may establish a design principle that all data will be stored in a single mainframe RDBMS, accessed through standard ODBC calls. This principle calls for selection of a standard ODBC-compliant RDBMS.

Now the really hard part: Your design principles are important, but they aren’t religion. You’ll sometimes have to make pragmatic decisions that violate a design principle or standard. Figure a way to mitigate the impact, and do what’s right for the business.

Your company’s strategic, tactical, and infrastructural goals drive the applications, information, and ultimately the computing platforms you provide. These define the design issues you need to resolve, which in turn cause you to select a set of consistent design principles.

It’s these design principles that lead you to choose specific technical standards.

Otherwise, your standards are just red-tape.

There are simple sourcing strategies. There are effective sourcing strategies. But there are no simple, effective sourcing strategies.

This, at least, was the perspective offered by yours truly at Outsourcing Strategies 2004 the week before last. It is, it appears, the minority perspective. The popularity of the Core/Context Theory — “Keep what’s core to your business and outsource the rest” — appears to be undiminished by the complete lack of any evidence to support it.

Complete lack of evidence?

Yes. In fact, that’s being gentle about it. In the past few years, two research teams reported the results of extensive research on what characteristics and practices lead to enduring business performance. The better-known, reported in Jim Collins’ Good to Great, found seven features common to outstanding corporations: A “Level 5” leader — one focused on building a great organization, not on personal recognition (I’m oversimplifying: there’s a lot more to Level 5 leadership than this); a strong, focused, coherent leadership team; a willingness to face the “brutal facts of their current reality”; clear focus around an organizing business goal (the “hedgehog principle”); creation of a “culture of discipline” (as opposed to achieving disciplined execution through close supervision); the use of technology as an accelerator; and reliance on the “flywheel” effect (building momentum for success on ongoing, continual, accelerating change, not on one-time transformational breakthroughs).

The second research effort was called the Evergreen Project. Described by William Joyce, Nitin Nohria, and Bruce Roberson in What Really Works, the project found eight factors — four primary, four secondary — that separated winners from the pack. While the factors aren’t exactly the same as those articulated in Good to Great, it appears the differences are more a matter of how each research team chose to define its categories than major disagreements as to what’s important. Having a clearly stated, focused strategy as stated in What Really Works isn’t very different from the hedgehog principle. Two other primary characteristics, flawless operational execution and a performance-oriented culture, together look a lot like instituting a culture of discipline and using technology as an accelerator.

The two studies don’t line up perfectly, which isn’t all that surprising. The Evergreen Project found that a flat, flexible organization was important to success. Collins was silent on this subject. And Evergreen’s list of secondary factors — retain and attract exceptional talent, creating industry-transforming innovations, growing through mergers and partnerships, and keeping leaders and directors committed to the business — have less overlap with Collins’ findings.

How to account for the discrepancies? When two study teams look at the same pile of raw data, there’s no particular reason to expect them to abstract the same generalities. The process of doing so isn’t purely analytical (Collins is direct on this point, describing lots of discussions and downright arguments over what a bunch of specifics might mean.) And since both pieces of research are correlative rather than experimental, this kind of disagreement is to be expected.

One point is clear: Keep the core and outsource the rest is nowhere to be found among either study’s recommended practices. Sounds to me like keeping the core and outsourcing the rest isn’t correlated with enduring business success.

(Keeping a wary eye on the ROI of individual projects or applying any other purely financial perspective on running a company is similarly absent, by the way, as is focusing on the maximization of shareholder value, two very popular points of emphasis among the current crop of business pundits … but that’s another column for another time.)

Adherence to the core/context theory isn’t among the factors driving outstanding business performance. It’s unsurprising when you look at how most large-scale outsourcing contracts are constructed. Much of their payoff comes from nothing more than the playing of financial games — a transfer of capital assets that front-end loads the benefits and back-end loads the costs. Gee, maybe that has something to do with why client satisfaction frequently runs out of steam just a few years into the average outsourcing relationship.

So why would a business theory that’s unsupported by the evidence retain such popularity?

Simple, easy-to-understand explanations are comforting — much more comforting than notions like the need for focus, disciplined execution and persistence. And given a choice between a comforting explanation and one that actually works, many people prefer comfort.

That’s one of the brutal facts of our current reality.

A popular outsourcing rationalization has it that companies should “keep the core and outsource the rest.”

I call it rationalization rather than rationale because:

  • It solves nothing: Outsource something you don’t know how to manage and you still don’t know how to manage it, only now, you’re badly managing a company that wants as much of your money as it can get.
  • It suffers from recursion failure.

KJR has already covered the first two points—click on the links or buy yourself a copy of Outsourcing Debunked (Bob Lewis, 2011). But what’s recursion failure? Glad you asked.

Outsourcing is like anything else in business—to succeed, you have to be good at it.

But as anything that isn’t core must be outsourced, and as the notion that managing outsourcers might be a core competency is absurd, the only logical conclusion is that companies that outsource must outsource outsourcing management to an outsourcing management outsourcer.

To succeed at that, the company must be good at outsourcing outsourcing management. And so on, ad infinitum—recursion at its finest.

Okay, I wouldn’t want to try that logic on a business executive weighing the pros and cons of outsourcing, but it was fun, wasn’t it?

What isn’t fun: Why an increasing number of American business managers are receptive to the even-more absurd arguments in favor of IT outsourcing, both the traditional kind and its current commodity end-point, cloud computing.

Look, even those unenlightened IT shops that thought they had internal customers usually involved themselves in the business processes and practices they were helping improve through automation to some extent. Few business analysts strictly limited their conversations to “what do you want the software to do?”

IT outsourcers, in contrast, deliver software that fulfills requirements and meets specifications. If they do that, all is good with the world, whether or not the software does anything useful.

Deep down inside, every business executive who ever endorsed an IT outsource understood this difference, and yet it didn’t matter. They considered overseeing IT to be an aggravation, and so they willingly “kept the core and outsourced the rest.”

Now we have the cloud, and software as a service (SaaS). The “new” question is, “Why should we spend lots of time with IT on a CRM implementation when we can call Salesforce and be up and running the next day?”

What’s sad is that they know the answer to this seemingly rhetorical question: If they do this they’ll be up and running with what we used to call, in more enlightened times, an island of automation.

Multiple islands, really — as many as they have sales representatives configuring Salesforce as they prefer. Add to that a database that’s completely unusable for reporting and analytics, as each sales rep stashes the data they want in whatever data fields appear convenient for that purpose.

Heck, IT could do that in a day, too, if it was amateurish enough to be satisfied with an implementation that banal. It could buy Act! licenses for a fraction of what SalesForce would cost, too, installing the software on individual sales rep laptops with no attempt to integrate them.

Nothing to it.

We in IT have failed in at least three respects, and we’d better fix all three soon, or we won’t be around to say “I told you so.”

The first is that we thought business executives long-ago absorbed the islands-of-automation argument, so we stopped making it. They had absorbed it, but ideas have a half-life, and because we stopped repeating it, this idea long ago lost its potency.

The second is that we argue rather than discuss. Faced with a sales executive who is thinking about Salesforce, too many CIOs say, “You can’t do that. Here’s why …” instead of, “We can do that … in at least three different ways, depending on what you want to accomplish and how much you’re willing to invest to get it.”

Then there’s the third — failing to focus everyone in IT, from the CIO on down to every help desk analyst—on the importance of managing relationships throughout the company. Without this, nobody will give the CIO or anyone else the time to have these discussions, or the patience to listen to the to-them complex engineering issues we need them to engage in.

So of course they outsource, and go to the cloud without involving us.

We’ve given them no reason not to.