Account Control, Stupid

The cat’s out of the bag. Rumor mills — encouraged by Oracle — centered on Oracle buying a Linux distribution, like Ubuntu. Instead, they’re co-opting it, offering “Unbreakable” support of Red Hat Linux. The tale of Ellison’s stab in Red Hat’s back has prompted some colorful reaction, of which we especially enjoyed Ingres CTO Dave Dargo’s no-BS BS take.

While Oracle’s means were a bit surprising, the end shouldn’t have been: Oracle wants complete account control of the enterprise back end. They’ve made little secret that they want to own the enterprise back end, and back in the spring, Ellison himself told the Financial Times that he’d like to have a complete stack.

You can chart the move up. From the database tier, Oracle began building and later acquiring its way to the application tier. And after aborted moves to place Java support inside the database, they’ve made a concerted effort to conquer the middle tier. That leaves the client — where Oracle made an anemic play in the late 90s — and the OS.

Oracle’s foray into Linux will likely end up a loss leader, but the impact will obviously be more modest than to Red Hat (witness yesterday’s 15% share price drop).

We don’t believe for a minute Oracle’s competitive positioning that “Unbreakable Linux” will be half the cost and more responsive than Red Hat’s. For enterprise licenses, likely the core of Oracle’s thrust, the difference is only $500, or 20% off Red Hat. And, while there’s little doubt Oracle can muster the resources, as eWeek Linux watcher Steven Vaughan-Nichols points out, Oracle doesn’t have a great track record when it comes to supporting its own database bug fixes.

In all likelihood, the brunt of the business will come from Oracle’s existing database or application customers who currently have or are considering Linux.

But the real target of all this isn’t Red Hat, it’s IBM. Until now, IBM has enjoyed a free ride. Sure, they’ve plowed hundreds of engineers into Linux-enabling their products and services — an investment dwarfing that of Red Hat et al. But they’ve profited nicely from an extensive Linux and open source ecosystem that repopulates mainframes, spurs blade sales, and provides opportunities for Global Services. They’re making much fatter margins off Linux than Red Hat or Novell.

At the end of the day, while Red Hat may wind up collateral damage, IBM may finally be prodded into assuming the loss leader business as well.

Adult Supervision

Our recent take on the out of control HP boardroom investigation was that this was a prime example of project management gone bad. While bad project management didn’t cause the crisis, it obviously exacerbated it.

VC Eric Risley put a fresh face on the issue by recalling some advice that his father, a retired GE executive and entrepreneur, passed him on the topic of corporate governance

Risley’s dad cast the issue in the context of the corporate lifecycle. While a company is in startup phase, it’s typically looking for “adult supervision” that’s focused, not necessarily on governance, but on tactical matters like getting an experienced hand on operations and budgets. Governance becomes an objective once the company matures and is thrust onto a wider stage after going public.

Rewind back to a year ago, and the sense of shock that occurred as allegations emerged over Mercury, a company that sold IT governance tools, was having governance issues of its own. A year later, the shock has turned to numbness with revelations of options questions snaring heavyweights like Apple, BEA, Microsoft, Verisign and many others. Evidently, options gaming was far more prevalent across Silicon Valley than we thought.

Given Risley’s dad’s advice, maybe the fact that more tech firms are being caught in a wider net shouldn’t be so surprising. Remember, this is a sector that values firms that preserve their entrepreneurial sprit. It’s a quality that connotes organizations that remain highly agile, are non-bureaucratic, and retain the energy and appetite of a startup.

Obviously, being hungry is preferable to being stalled by inertia. But has our value system indirectly given short shrift to the qualities of transparency that are expected in a post-Enron world?

Yet Another New Software Development Platform?

Among the highlights of Salesforce’s annual conference was the unveiling of Apex, a new language and platform for developing industrial-strength transactional apps that could run against the Salesforce.com multi-tenant platform.

Not counting browser scripting languages, which are typically platform- (but not always browser-) agnostic, most of the software development world has coalesced into two major camps: Java and .NET. It’s not necessarily because these two technology frameworks are better than everything else. Nope, it’s because in a world that’s increasingly interconnected, nobody can afford to maintain multiple, incompatible skills bases for developing apps that can’t talk to each other.

Given the ongoing consolidation in software development, does the world need yet another new software development platform? Put another way, why doesn’t Salesforce just use Java as its underlying development platform?

There are two answers to that question. On the technical side, .NET is obviously out because it only runs on one platform. And Java doesn’t fit for a couple reasons. First, it carries excess baggage, like rich media APIs that have nothing to do with meeting the rigors of execution in an environment that is shared with many other tenants. Secondly, as Adam Gross, who heads Salesforce’s developer marketing told us, Java lacks capabilities for managing resource in shared on-demand environments, such as Salesforce.

Instead Salesforce designed a combined language and deployment platform that looks a lot like Java (actually, so did Microsoft when it invented C# and the .NET Framework) to handle the unique requirements of deploying to an on-demand environment.

Which brings us back to the question of whether the world needs yet another new platform requiring its own unique skillsets.

There are always technical workarounds. But the real answer is from the business side.

What Salesforce really wants to do is own the new enterprise applications desktop. When you examine how Salesforce has promoted App Exchange, they’re not just talking about a third party alliance program. They’re talking about a new self-contained ecosystem, which is their on demand platform for business apps. Bottom line: Salesforce isn’t simply competing against Oracle or SAP. At the end of the day, they’re going head to head with Microsoft.

With that goal, it’s not surprising that Salesforce opted for a whole new platform. It looks enough like Java to draw in Java developers. But it’s unique enough so Salesforce can optimize what goes on in the back end.

Given the obvious demand among small-midsize businesses (SMBs) for affordable platforms that they don’t have to maintain, Salesforce’s quest to establish the next enterprise desktop is credible. But of course that requires an ecosystem, because SMBs need more than just a CRM or sales force automation system.

But as colleague Josh Greenbaum reminded us today, Salesforce’s plans to become your next enterprise desktop remain very much a work in progress.

Eyes Off the Prize

At first glance, there’s something about the HP board saga that doesn’t ring true. On one side, you have a chairwoman who was a student of governance, suffering a lapse of judgment that could find her (and others) in legal jeopardy. Meanwhile, a dissident board member whose success was frequently built by throwing away the rules proved the one who blew the whistle.

What’s wrong with this picture?

An article in yesterday’s Wall Street Journal documenting the dissension and politics on the HP board provided good insights on a culture that allowed the situation to careen out of control.

You could spin the saga in any number of ways: the outsider battling against entrenched interests, the innocent being set up, the woman of the year battling to be taken seriously in a highly macho boardroom culture, or the need to vet board nominees more thoroughly.

But reality is hardly black and white. Although the smoking gun has yet to be uncovered, it’s clear that the pretexting occurred because project leadership lost sight of the big picture.

To recap, the investigation began in the wake of boardroom leaks during debates over former CEO Carly Fiorina’s future. Based on a solid premise that boardroom leaks compromised corporate governance, at some point, the investigation veered off course once somebody cleared the use of legally questionable tactics to flesh out phone records of suspect board members.

Consequently, a project conceived with the goal of sound governance ultimately compromised it. Governance broke down when somebody at the top authorized the pretexting, or failed to adequately manage subordinates to keep the process on hard ground.

While the consequences of the HP case may prove far more severe than a blown budget or project schedule, the scenario should still look rather familiar to any seasoned IT professional. Put another way, how often do project teams get so wrapped up in the details that they lose sight of the overall goals?

Consider the case of a major global investment bank’s compliance project. In this case, one of the bank’s compliance strategies is building systems that adequately separate and document risk. And, as part of the development cycle, IT is documenting the business requirements so that the system delivers the right performance, supports the necessary scalability, maintains appropriate security levels, and contains the right functionality.

Unfortunately, in the quest to document requirements, the team has found itself being evaluated on its progress in feeding those requirements to a tool that manages them. Yet, there are either no metrics in place, and nobody taking ownership for vetting the accuracy, reliability, or quality of the requirements. Ultimately, if the system is built on faulty requirements, compliance will prove problematical.

The consequences of project tunnel vision could become exacerbated as IT organizations get serious about adopting best practices frameworks such as COBIT for governance; ITIL for service management; or ISO 17999 for IT security. The goals may be admirable, but as the HP board learned the hard way, the devil is when the details block the big picture.

Guilty Till Proven Innocent

Want to get that IT project approved? Forget strategic vision. Over the past 5 – 6 years, conventional wisdom has been that only tactical, incremental projects promising targeted ROI are getting green lighted.

Yet, as we were listening to an IBM conference call yesterday about their latest SOA offerings, they trotted out a customer who described SOA investments as “a journey, not a one-year investment choice.” Were we imagining things? Or did this signify that it’s OK to get strategic again?

Until now SOA has been promoted as a sort of third way. Unlike 1990s-style reengineering, SOA doesn’t require you to rip things out. By wrapping the legacy in a standard container that exposes functionality as a WSDL service, you can isolate change to the new services layer, letting sleeping dogs lie.

At first blush, it sounds almost like immaculate conception. No matter what you do at the services level, nothing happens to those complex, legacy assets that took generations to build, and are frankly rather mysterious to decipher. And by relying on a standards-based integration model, heck, the new code theoretically should become easier and more transparent to maintain and repurpose.

You’re probably thinking this is sounding too good to be true.

Admittedly, if you stick to building just a few badly needed services on a one-shot basis, you can get away without worrying about building yet another new legacy. But as you know all too well, priorities change, systems change. Stuff happens. You won’t be able to stop with just a couple services.

And so at some point, you’ve got to bite the bullet and define a new architecture that sits atop the old.

Otherwise you’ll wind up with a new generation of spaghetti, one that’s a bit more standards friendly, self-documenting, and an enabler of what’s at best ad hoc reuse. As for policy, you’ll be improvising from one service to the next.

So your next challenge is selling top management on the need for yet another new architecture. Yup, you can promote agility, but that only works if the business is ready, and anyway, how are you going to quantify the benefits? When you get desperate, you’ll probably wind up cost justifying the new architecture, not as a totality, but through reuse, one service at a time.

The customer in the IBM call cited three categories of reuse, ranging from enterprise, which consisted of a select few universal building blocks, like customer management. Then there is reuse at the department or business unit level, where you have to greater potential for reuse because of a shared context. And finally there will be some services that are so unique that they probably won’t be shared. But you want them managed under the same policies and infrastructure. The customer claimed that one of the ”enterprise services” saved up to 20% of the cost of the SOA architecture and new infrastructure.

The bad news is that it’s hard to promote architecture as anything but strategic. And even when you hit reuse, if your CEO has a long memory, they might recall that your predecessors made the same promises when they were selling CASE, client/server RAD (rapid application development), component-based development, or just about any other major enterprise software investment.

SOA could be different. But when pitching it, you’ll remain guilty till proven innocent.