07.27.06
Posted in Technology Market Trends at 10:20 am by Tony Baer
Ever since the emergence of lean manufacturing, management gurus have been preaching the virtues of multifunction teams. Rather than throw an idea over the wall, getting a cross-function team that includes stakeholders and all the players necessary for developing and delivering the product or service raises the odds that it will be successful.
We’ve railed on in the past about the fact that, if you take services-oriented architectures seriously, you must ensure that the IT infrastructure can handle the service level commitments. The challenge is that there have always been functional silos in customer organizations separating the business side from software development and IT operations. But that’s only half the battle.
This week’s announcement that HP was buying Mercury reminded us that vendors may face a reengineering challenge that’s as tough or tougher as that for their customers.
The central problem is that, if you’re a sales rep, you would rather sell into a market that is familiar to you. The same is true for marketing, which must craft the message. The problem emerges when you have a product, or make an acquisition, that suddenly exposes you to a new entry point at the customer. The emergence of SOAs, which blur the boundaries between business processes, software functionality, and IT infrastructure capability, are hastening the need to master selling in unfamiliar territory.
All too often, product developers – and even top management – are frequently making acquisitions or developing cross-functional products for which their sales, marketing, and product support and delivery groups are ill prepared.
For instance, Microsoft’s recently introduced the Database Professional edition of Visual Studio Team System. It provides an innovative approach for database developers (who usually come from the software development organization) to examine the impact of changes to data structure on database operations (which are typically managed by the database administrator, or DBA). So how do you sell a tool that bridges both silos? Similarly, when BMC bought Identify, it gained a tool that could help data center administrators diagnose if a server outage was due to a faulty thread in the application.
The problem is, data center operators have typically thrown such problems back over the wall to application development organization. For BMC, which sells to the data center, the challenge is how to retrain a sales force experience with IT operations to (1) conduct a missionary sale to the people they normally call on, and (2) speak the language of the software development folks comprising the current market for the tool.
Likewise with HP and Mercury, Mercury’s governance and QA tools have traditionally sold to software development, and in some cases, business analyst groups. Meanwhile HP’s OpenView products have sold to the data center folks. HP software has a poor track record understanding the needs of the software development organization, witness their botched Bluestone acquisition.
Yet, if HP is to realize any gain from this week’s $4.5 purchase, they are going to have to do more than simply cross-train a few sales and marketing honchos. In essence, it dictates a rethinking of the soft and hard sides of IT management.
In an ideal world, we would listen to folks like Amazon CTO Werner Vogels. In his organization, there are service developers, not software developers. And they are responsible for the full life cycle of the service, from development to ensuring that it runs on the hardware and network. Vendors wouldn’t have any problems cross-selling there.
But most organizations aren’t Amazon. Consequently, to sell the solutions that will truly align SOA and IT infrastructure to the business, the brunt of reengineering may fall on the vendor.
Best of luck.
Permalink
07.26.06
Posted in IT Governance, ITIL, Technology Market Trends at 10:19 am by Tony Baer
It’s pretty hard to keep secrets these days. After months of speculation, HP put Mercury out of its misery, announcing it would acquire the scandal-rocked firm for roughly a 25% premium on its most recent closing price. It wasn’t a bad deal for Mercury shareholders, as HP’s offer amounted to roughly double the street value of the firm after it announced the firing of its three top executives over allegations of stock option gaming last fall.
On one level, the acquisition of Mercury adds a sad footnote to a company whose reputation wasn’t brought down by performance, but by allegations of executive greed.
On another level, it adds another feather in the cap for HP, whose OpenView business has recently been on a roll (its Q1 numbers were 34% higher than those of a year ago).
It’s easy in hindsight to realize that Mercury’s governance strategy ultimately had to play on a wider field that included IT operations. Increasingly, the company was finding itself competing, not with the Compuwares of the world, but the BMCs, CAs, and IBMs.
Having begun life as a software testing vendor that played heavily in the application development space, Mercury shifted gears roughly three years ago when it bought project portfolio management provider Kintana. The shift higher up the totem pole to IT governance made sense in that it widened Mercury’s horizons from software QA to IT QA.
Even had Mercury’s corporate governance scandal never occurred, it would have found its IT governance hitting the wall sooner or later. Take service desk. Just over a month ago, it acquired a small firm that provided a service desk (what used to be called help desk) tool that it billed as being driven by ITIL (IT Infrastructure Libraries).
To clarify, ITIL is becoming a more popular term among CIOs because it provides a framework of best practices for delivering and managing IT service. ITIL has grown in importance, not only because IT organizations need to document their quality of service, but also because many of the ITIL processes, such as change management, have compliance ramifications.
While Mercury’s ITIL-based service desk approach was a natural extension to its IT governance offerings, it proved an incomplete solution. By contrast, most service desk offerings are linked to IT operations systems such as BMC Patrol, CA Unicenter, HP OpenView, or IBM Tivoli. But Mercury’s was linked to a change management system, an approach that it claimed was more business-focused. Yet, offering a service desk lacking provision for automatic generation of trouble tickets when an IT operations system reports an outage does little for meeting service level agreements.
Consequently, it wasn’t surprising that HP was the rumored suitor for Mercury. While HP – like its IT operations rivals – has promoted the business aspects of systems management, it lacked the IT governance dashboards, product portfolio management, and analytics of CA and IBM. Mercury therefore makes a good fit.
But we have one quibble with published analyst comments that HP’s acquisition of Mercury adds SOA management. Aside from the acquisition of web services registry provider Systinet that was completed earlier this year, Mercury had not yet developed solutions or strategies for run time governance of SOA environments. Ironically, that’s something that the HP acquisition could solve. HP’s SOA Manager, which provides the run time governance, has until now been somewhat of an orphan in the HP software group. Paired with Mercury’s Systinet, HP might finally get the chance to plug the gap.
Permalink
07.24.06
Posted in Technology Market Trends, Web 2.0 Apps at 10:18 am by Tony Baer
Among the technologies or approaches most associated with Web 2.0 are Mashups and Wikis. While one provides the opportunity for synthesizing web apps from multiple sources on the fly, the other provides an open source-like approach to building community wisdom.
The draw of Wikis is that they theoretically deliver the benefits of knowledge management without the overhead. You might recall the knowledge management projects of the 90s. They were typically top-down affairs that degenerated into meal tickets for consultants. By contrast, Wikis appear to be low-cost solutions that real people actually use. As distributed, bottom-up, lightweight technology, Wikis appear nicely suited for organizations priding agility.
So what happens when enterprises get serious about Wikis?
We were reminded of that point as JotSpot, a 2-year old startup, introduced version 2.0 of a product that lets you develop Wikis as if you were working in Microsoft Office. By contrast, current Wiki technology restricts you to working with plain vanilla HTML text documents with provision for embedding forms, graphs, or pictures here or there. But JotSpot’s Wiki 2.0 tool embraces the Web 2.0 rich client, enabling you to design the document as text, spreadsheet, picture, or calendar — just like using Office.
This kind of capability borders on what Microsoft is promising with SharePoint Services in Office 12.
Nonetheless, these are only the first steps towards elevating Wikis to the enterprise mainstream. Tooling and best practices remain works in progress.
The flexibility of Wikis, which empower any community member to contribute knowledge, can also become one of its prime drawbacks. People being people, there’s plenty of room for mistakes, not to mention abuse. For instance, Wikipedia recently had to rope off a number of sensitive topics, adding a layer of management restricting updates to qualified members of the community.
The lightweight nature of Wikis proves yet another strength and weakness. Once Wikis proliferate, you’ll inevitably wind up with multiple versions of the truth — some of which might be dated or plain out wrong. So how do you navigate through all the overlap and vet what’s there?
At best, today’s Wiki technologies allow you to link to the web pages of content management systems or other resources. That’s akin to going to the library and finding a book that tells you its Dewey Decimal Number after the fact. Nice to know if you want to peruse other books with the same classification, but not terribly efficient as a research tool.
Ultimately, enterprise Wikis will require a dose of management. On the technical side, they will require dynamic, two-way links with web content management to provide navigation and versioning; Web 2.0-style syndication to ensure that the right people remain in the loop; and services-oriented architectures for blending objective data and processes residing in back end systems. But the hardest part will be the best practices for ensuring that the domain or process experts who theoretically “own” the knowledge don’t stifle it.
Permalink
07.10.06
Posted in Open Source, Technology Market Trends at 10:17 am by Tony Baer
Why do customers embrace open source software? While mythology says it’s all about getting access to source code, reality is a little different. Most enterprise IT organizations have little time to mess with somebody else’s code, not to mention their own.
So when you pop the question, the answer you’ll usually get is “price.” But is open source actually cheaper?
The first answer is that open source vendors have a different pricing model: unlike proprietary software, you don’t buy a perpetual license up front because you can download the software for free. But if you want support or upgrades, you pay with annual subscriptions.
That’s a nice proposition for customers who can eliminate the need to ante up comparatively huge sums up front for so-called “perpetual” licenses. In many case, they can expense rather than capitalize the software.
But for any vendor with more than 5 years in the business, the notion of shifting from licensing to annual subscriptions makes cash flow dicey.
That’s because, when customers pay as they go for annual subscriptions, they can theoretically pull the plug at any time. Conversely, for vendors, eliminating upfront license sales places in question how to finance product development. Although software development never stops (look at the rate by which most vendors issue patches), the bulk of development cost should occur up front.
Nonetheless, because customers are increasingly demanding subscriptions, subscriptions they will get.
Yet, are subscriptions necessarily cheaper? Over the long haul, they shouldn’t be.
Otherwise the software industry couldn’t afford to stay in business. Vendors need to earn a profit, while customers require affordable software. In other words, the laws of supply and demand should produce a price that the market will bear.
Are subscriptions anything new? Not necessarily. When you peer under the hood, subscriptions start looking a lot more familiar.
1. By imposing annual fees with no obligation for renewal, subscriptions look a lot like paying for software by utilization. If you don’t use it, yank the subscription.
2. The annual fees clearly resemble the 15 – 20% annual “maintenance” charges that always accompanied perpetually licensed software.
3. Most open source licenses under which code is downloaded do not convey ownership. So when open source support is offered by subscription, it starts looking a lot like the software leases of yesteryear ? a model that SAS still uses to this day.
4. Subscriptions are becoming common for non-open source products, like Salesforce.com.
Nonetheless, it’s hard to escape the fact that pricing of JBoss, MySQL, or Red Hat subscriptions are typically lower than licenses for WebSphere or WebLogic, Oracle, or Windows, respectively.
It’s not that open source subscriptions are necessarily cheaper, but that customers consider products like middleware, entry-level databases, and operating systems as commodities. If they’re going to invest serious bucks, it will be in technologies that provide competitive edge. And that has little to do with whether the software itself is open source or offered by subscription.
As we’ve mentioned previously, there are many open source strategies. But they all have one thing in common — they are decisions by communities or vendors on how they will go to market. The reality of open source veers sharply from the myth.
Permalink