12.19.05

The Dirty Dozen and Other Management Tales

Posted in Outsourcing at 2:51 am by Tony Baer

About three years ago, we moderated an outsourcing debate pitting a software vendor CTO vs. a representative from a leading Indian offshore firm. While some of the discussion was predictable, what surprised us was an admission that the offshore firm rep volunteered out of the blue.

Recalling the metaphor of two cultures divided by a common language, he admitted that certain expressions or idioms didn’t always translate well.

The prime example? Interpreting the routine request, “It would be nice if you could finish the job by tomorrow.” To our ears, such a question means, “You’d better finish the job by tomorrow or else.” To Indians, it was seen as a polite request that, if you fulfilled it, would be rewarded with brownie points. Evidently, Indians just didn’t comprehend our sense of urgency.

What if we were to reconvene the same discussion today? That was in the back of our mind as we spoke with Marc Hebert, executive VP with the offshore firm Sierra Atlantic, who described his firm’s management training program.

Sierra’s program borrowed role models primarily from western pop culture. As part of the course, management trainees are shown the film The Dirty Dozen, where a group of convicts are drafted and shaped into a lean, mean fighting machine to overrun a major Nazi compound.

Of course, the program featured other examples, such as The Bridge Over the River Kwai and various Bollywood productions. But what drew our attention was the notion that the untouchables of American society had anything of value to teach India’s emerging elite. According to Hebert, films like the Dirty Dozen illustrate how to perform under pressure. In today’s consolidating IT market, we’d concede he’s got a point.

But our sense is that today, Indians – and anybody else that wishes to play in the global economy – have an even more important lesson to learn. It’s about avoiding complacency.

Right now, the spotlight is ready to shift towards China, where BEA’s Alfred Chuang recently delivered a triumphal speech about local prospects.

Admittedly, today Indian IT services are sitting pretty. They’ve profited from their ability to perform faster, cheaper, better – just as the Japanese did with the US auto industry a generation ago.

When it comes to raw numbers, China is the one place that could give India a run for its money. Nonetheless, China also faces hurdles of its own ranging from lack of legal infrastructure to an authoritarian Confusion tradition, heavy-handed government that doesn’t know when to let go, plus the fact that English remains a second language.

Some of China’s hurdles remind us of Japan’s ill-fated Fifth Generation artificial intelligence computing project back in the 1980s. Following their triumphs in manufacturing, conventional wisdom held that it was just a matter of time before they would be defining the future of computing as well.

Turns out, the future came and went, and the Japanese lacked the individualism gene to make it happen.

The punch line? Neither China or India has it made. Furthermore, there’s no such thing as permanent competitive advantage.

12.05.05

Filling the Donut

Posted in Application Development, SOA & Web Services, Standards Development at 2:49 am by Tony Baer

Web services were supposed to simplify the exposing and integration of functionality locked within the silos of software applications. And they were supposed to be the bridge by which Java and .NET logic could coexist.

But the devil’s been in the details. Fulfilling this promise requires too much expertise in low-level plumbing, like chaining together a string of SOAP requests to various service definitions to execute a composite service. Or it required specialized knowledge of middleware and the structures of underlying data sources.

Last week, IBM, BEA, Oracle, SAP and others unveiled proposals for what they call Service Component Assemblies (SCA) and Service Data Objects (SDO). In effect, SCA and SDO apply many of the component design and assembly principles long taken for granted in the Java and .NET worlds to the composition of web services.

The announcement wasn’t absent the usual round of hype. One vendor evangelist termed the proposals a deployment descriptor on steroids. Well, we won’t go that far, but nonetheless, this could still become a potentially significant development.

Until now, there was a standards gap when it came to assembling compound web services. If you’re a developer, you had to rely on the proprietary technology of your middleware, understand the data structure of the information related to the service, understand the content of multiple web services, then use BPEL (a standard for orchestrating multiple web services) to assemble what is in effect, a component.

BPEL is fine if the composition of a service is to vary by scenario. But what if you wanted to piece together a compound service component? Until now, you would have hit the donut hole, because there was nothing between the low-level “wire level” protocols for creating web services, and the sophisticated processes for conditionally orchestrating them.

As noted, the Java and .NET worlds solved this problem long ago with component architectures providing de facto standard APIs. You could readily compose services as long as they came from pure Java or Microsoft environments. SCA and SDO fill this gap by applying standard APIs to the platform-neutral web services domain.

The result will impact software developers rather than business analysts (who deal with processes, not components). If these proposals become standards, web services development will now fall inside the mainstream of modern software design principles, which are based on component architectures and object-oriented design. And for middleware, development, or process tools vendors, it provides a standard component architecture to make the logic and data underlying services more portable.

Of course this is all a big “if.” The proposals originate from the usual Java suspects, although ironically, SCA and SDO have nothing to do with Java. And being preliminary, they have yet to find a standards body. The biggest question? Lacking Microsoft’s imprimatur, the proposal will add rather than eliminate complexity.