March 9, 2006

Issues in privacy

My March Computerworld column is an exhortation to IT workers to get involved in IT-related public policy issues. Probably the most complex and serious ones are in the area of privacy. Options I posed include:

• Do nothing.
• Maintain sharp limits on government acquisition and retention of information.
• Mandate that the government keep its information in separate silos.
• Create strong rules about how governments can use information once acquired.
• Hamstring corporate acquisition, retention, or use of information. (Much of the government’s potential data comes through private channels.)
• Various mixes and matches of the above.

My own view, which I plan to lay out and defend in a series of posts, is a complex one. Historically, protections such as the Fifth Amendment to the US Constitution have focused on limiting the government’s access to information. And this has been wise. As was shown for example by the misuse of FBI information under J. Edgar Hoover and the misuse of IRS information in the Nixon Administration (which Nixon claimed he didn’t innovate), once information gets into government hands its use is hard to control.

I see no good alternative to preserving these safeguards as long as possible. Maybe the Bush Adminstration should have gotten legislative permission for its data mining adventures and maybe the permission should have been denied, but the fact that they pursued them while circumventing the legal safeguards is utterly deplorable. That few people have suffered from the violationof these safeguards, or the worrisome provisions of the Patriot Act, merely proves that our multiple layers of safeguards are strong. It does not justify chipping away at them illegally, and I’m not real thrilled about legally undermining them either.

On the other hand — many of those safeguards are eroding fast. The amount of information the government can or potentially could obtain legally from credit card records, electronic auto toll tracking, etc. is staggering. National ID cards and passports are going electronic. The US Constitution apparently doesn’t prevent sensitive devices snooping into your house from the outside. Web surfing behavior is being submitted as criminal evidence. The government WILL have access to a very complete dossier on your activities, rather soon. Legislation to mandate this data be maintained in independent silos, while worthy, is just a stopgap.

And so in the US (and other developed countries, I would think), it is not just enough to fight government information acquisition. That’s a losing battle, especially since the most absolute safeguards can not be maintained in the face of the terrorist threat. Thus, I think we also need some reaffirmation — in principle, at least, if not in actual law — that “thou shalt not be hassled.”

I’m not yet sure what form(s) I think that needs to take.

February 27, 2006

Typo of the week!

The Register offers an eye-opener:

The UK’s keenness to push through tough data prevention laws during its stint in charge of the European Union (EU) has won it the “Internet Villain Award” at this year’s net industry awards.

Either that’s the best typo of the week, or things are really dastardly over on the Sceptred Isle …

February 16, 2006

Whatever Oracle is up to, it should work moderately well

Speculation is rampant as to Oracle’s exact strategic goals in acquiring Innobase and Sleepycat, with more open source vendors rumored to be coming soon. Rather than try to add some nuances directly to the low-end/open-source/brand-extension/embrace-and-extend strategic discussion, I’d like to step back and say one thing:

Multi-DBMS product strategies work moderately well.

Admittedly, in the history of software there only have been a limited number of DBMS products that be regarded as huge successes, and only in one case has more than one of them belonged to the same company. But even so, history is fairly encouraging toward whatever it is that Oracle is trying to do.

IBM. IBM has had two hugely successful DBMS product lines – IMS and DB2. Since IMS and DL/1 were separate products, and there are also two significantly different versions of DB2, it’s even fair to say that IBM has had four different rather successful DBMS. And that’s not even counting acquisitions.

Informix. Shortly before it imploded, Informix got a little carried away with a multi-product strategy. It didn’t help that by claiming all the products were on a single code line, they were saying something that A. Wasn’t true and B. Nobody would have cared about if it were true. Still, the Progress-like Informix/SE was a fundamentally different product from Informix’s Oracle-competitive high-end products, and both were viable businesses. Unfortunately for Informix, when it moved successfully into the high end it defocused on the low end, and went from being a powerful #2 in the VAR market to a real also-ran.

Sybase. Sybase was once a leader with what is now called Adaptive Server Enterprise, and continues to muddle through as nontrivial also-ran. Meanwhile, Adaptive Server Anywhere is the leader in its niche. Like Informix, however, Sybase walked away from what had been a strength, which is the laptop/desktop/office OEM market, really focusing on the pervasive computing/nontraditional computer market at the expense of what was once a strong business position (e.g., as the initial big platform for Siebel’s original Sales Force Automation products).

Oracle itself. The acquisition of RDB from Digital was a major success for Oracle, in that the technology really helped the main Oracle product while the legacy RDB business tootled along to pay for itself. I think the smaller TimesTen will be a big success as well.

I think Software AG is doing OK with a multi-DBMS strategy too, but I’m a bit foggy on the details. Progress has a few very impressive references and not much else from its recent DBMS-like product acquisitions, but I’m cautiously optimistic there. That leaves Microsoft pretty much as the only single-DBMS vendor around, and I’m sure there are folks in Redmond who, because of Analysis Services or Access or something, would even dispute that.

If Oracle pursues some kind of parallel product line open source DBMS strategy, there’s every reason to think they can pull it with only moderate conflict and anti-synergy. At least, that’s what industry history seems to suggest.

And I have some thoughts as to why this is true. In no particular order, they are:

1. Developing DBMS is a hard skill – and one that’s transferable from project to project.
2. The same goes for a grab-bag of specific experience, tricks, algorithms, and so on.
3. Positioning of multiple DBMS products need not be in serious conflict. (Actually, companies do tend to screw that up a lot, which is why almost all the successes I outlined above are only partial. Maybe I’d better save a detailed discussion of that point for future postings.)

February 16, 2006

MySQL vs. the big guys

Marten Mickos, CEO of MySQL, is a quotable man this week. Oracle saw to that by acquiring Sleepycat, on the heels of its prior acquisition of Innobase. Basically, his message is rah-rah open source, he really truly can compete with Oracle on functionality, but of course as a practical matter Oracle probably is locking in its application customers to its DBMS, including customers from the Siebel and Peoplesoft acquisitions. That makes sense. It’s consistent with what I’ve been hearing from SAP. I now think that the quotes elsewhere suggesting he wasn’t serious about powering ERP software at all were misunderstandings. He just recognizes that the ERP software MySQL will power will largely be SAP’s.

As I’ve previously noted, the expectation is that MySQL will wind up getting share in SAP’s customer base. At least, the expectation is that their technology will be good enough to do so. The business reasons for SAP to favor this outcome are of course pretty obvious. Almost the only remaining question is whether SAP will back MySQL with great force, or whether it will divide its love between MySQL and its own inhouse DBMS product MaxDB.

February 16, 2006

Dave Duffield back in the saddle

Good article on Dave Duffield and his new startup. Dave is quoted emphatically saying that he did not come back to Peoplesoft to sell it, but rather to try to keep it independent.

That jibes with my view of him. He once told me that what he most valued about his success as a CEO was the corporate culture he’d created. (#2 on the list was getting rich and giving lots of money to charity, specifically to animal-related causes.) I thought at the time* and now think again that he was sincere when he said this. He’s also pretty much the only CEO who’s ever said something like that to me. There certainly have been others who cared about their employees (John Cullinane was particularly proud of how many people he’d help make into millionaires), but Dave is one of the very few I’ve known who could talk about a “corporate culture” of the kind/gentle sort and not sound insincere, ineffective, or just plain delusional.

*I must confess, however, that I never knew Dave as well as I knew a lot of other CEOs. Somehow, I never managed to even meet him until Peoplesoft was on its IPO tour. We made up for lost time later, up to a point, but he’s not one of the guys like Larry Ellison or Bill Gates, with whom I’ve had multiple multihour conversations.

February 13, 2006

Everybody gets paid — or would like to

The disclosures in this post have been updated in June, 2008.

I’m sometimes amazed at the breathless pseudo-naivete about pundits (analysts, bloggers, whatever) and compensation. The latest round was kicked off by a WSJ article about bloggers promoting FON. A couple of years ago, Computerworld editor Maryfran Johnson was viewed as a heroine for pointing out analyst firm conflicts of interest.

Personally, I’ve been an analyst for almost 30 years; I have a strong reputation for being independent and critical; and I get most of my revenue from vendors. So perhaps I’m in a good position to clarify some of the issues.

1. Good vendor relationships are an important factor in an analyst’s success. It’s not just revenue; you also need access to information. This is true whether you’re a stock analyst or an industry analyst.

Now, if you’re a good analyst, you can work around access problems. You can talk with customers, competitors, ex-employees, and other industry players. You may have relationships that transcend the company’s communication controls. (For example, it’s a firing offense at Oracle to have unsanctioned conversations with an analyst. And Oracle isn’t sanctioning a whole lot of conversations with me these days. But for a number of reasons, such as longstanding relationships with “untouchable” higher-ups, my information flow from inside the company is still pretty good.) Still, having access is better than not having access, and companies use that as a lever.

2. Analysts typically have more confidence in the companies that are their paying clients. I honestly call ’em as I see ’em, no matter who is or isn’t paying me. But some of my calls have to do with confidence. And who will I be more confident in? Company A, which has disclosed almost all their current activities and intermediate-term plans to me, and has given serious consideration to expensive advice they’ve paid me for (and hopefully done something with the advice)? Or Company B, with whom my relationship is largely being fed marketing pabulum, with only the occasional renegade getting off the reservation and telling me what’s really going on? Obviously, it’s often Company A.

Gartner Group is no different from me in that regard.

3. There’s a reinforcement cycle that confuses questions of bias. Companies give money and attention to analysts who are positively inclined towards them. They buy consulting services from analysts whose worldviews are compatible with theirs. The resulting relationship, if it goes well, reinforces everybody’s positive opinions of each other.

Meanwhile, companies give cold shoulders to analysts who don’t like them. And that just reinforces analysts’ opinions too.

4. Experience teaches that the companies that most manipulate or hide from analysts have the most to hide. If a company feels good about its strategy, and is eager to listen and learn how to make it even better, it’s often pretty engaged with analysts. If there are some product weaknesses it would prefer not to have discovered, it may be more inclined to concentrate its efforts on only the big firms it must talk to, and cold-shoulder the others. There are exceptions, of course, based on factors such as marketing budgets or the cluefulness of the analyst relations staff. But a good analyst’s gut feel about who is or isn’t being forthright is often a pretty good indicator of how a company’s technology is doing. Indeed, I have had some famous successes in this regard over the decades (e.g., the Cullinet and Sybase stories, which I really need to write up at some point over on the Software Memories blog). And it’s not just me. David Ferris of Ferris Research led the way when he and I had a success of that kind together with respect to Critical Path, shortly before the management team was discovered to be criminally dishonest.

5. Being on advisory boards almost always involves compensation or the expectation of compensation. Anybody who asserts otherwise is dishonest or naive. But then, the only folks I’ve ever seen assert otherwise are Fabian Pascal and (sort of) Chris Date.

So here is some of my disclosure.

February 8, 2006

End of an era — Borland exiting IDE business

Borland is exiting the IDE business. Wow. On the one hand, I long ago figured out that IDEs weren’t a real business. On the other hand, this is Borland we’re talking about — the last holdout.

Three factors killed the IDE business, and a fourth drove a stake through its heart. None of these, IMO, is the rise of Eclipse; that’s a symptom of the problems, not a cause. Rather, I think the key factors are:

A. Vendors are paid well for run-time products, not development-time. Most categories of “platform software” actually have a major programmer-productivity aspect to their pitch. Microsoft Windows makes device connectivity easy. Application servers make Web connectivity, data integration, load-balancing, and/or failover easy (the reason for buying them has changed frequently). Database management systems are ultimately just big SQL interpreters. Similar stories could be told about other categories, including almost everything in analytics.

And those product categories are often big businesses, because vendor revenue depends on the number of end-users, not the number of developers. Thus, it’s often obvious that value far exceeds expense. By way of contrast, getting the same revenue from developer-based pricing might require tens of thousands of dollars per developer seat, and rightly or wrongly that kind of pricing is very hard to enforce.

There was a period in industry history when technology made it natural to officially have run-time versions of developer tools. This was the “fourth-generation language” period, which arguably lasted from the early 1980s until the mid-1990s or so. But once Java came along, everybody wanted compiled code instead of proprietary interpreters. And that was that.

B. Price competition was brutal. Server-based development tools may have been expensive, but PC-based language products were very cheap. Microsoft’s first product ever was a Basic interpreter; I don’t know the price for sure, but I’m guessing it was a few hundred bucks. Way back in the early/mid-1980s, Borland started out by selling a $49 developer tool, namely a Turbo Pascal compiler. When Microsoft and Borland duked it out in the C++ market in the early/mind-1990s, huge amounts of software documentation showed up for what were rather low-priced products.

But the real killer was Visual Basic. VB conflated the IDE and “language” markets, and imposed language pricing on the development tools market. And that was that. What’s more, a significant fraction of the development tools market was held by the independent DBMS vendors (Oracle, Informix, et al. — and the same had been true in the prerelational era). They wanted account control, with lots of applications built on their DBMS to create lock-in and more server sales. And that was a higher priority for their tools businesses than making a profit. So when it became hard to hold the line against Microsoft tools pricing, Oracle et al. weren’t all that depressed about caving in.

C. Products are obsolete before they were mature. Contributing strongly to the economic problems of the IDE business is that the products usually don’t do that good a job. Oh, in many ways they’re great, and programmers swear by them. But programmers also swear at them, because they commonly do only part of what is necessary. Generally, a new tool will be developed to help with a new need, such as relational DBMS access or GUI client/server interactions or three-tier processing or whatever. But these tools will often be weak at what came before; e.g., Powerbuilder and Visual Basic weren’t very good at industrial-strength scalability. By the time the shiny new tools mature to do a good job at the older requirements, some other platform shift comes along, with yet newer and shinier tools to handle the latest twists.

D. It’s all about collaboration. The latest requirements shift is from supporting individual developers to supporting teams. That makes almost everything about IDEs irrelevant, or at least a commodity. Borland, which has been telegraphing today’s shift for a while, may have made the point most clearly. But you hear similar things from Microsoft and Oracle.

So there you have it. I was perhaps earlier than most in figuring this out, having gotten a very painful education in the point by the commercial failure of my critically acclaimed application development tools opus in the mid-1990s. (It survived as an essential reference for the trade press for years. But not many users ever actually bought it; instead, they just bought Visual Basic and didn’t even consider the more sophisticated products I wrote the guide about.) But I think the whole IT world sees it now.

February 2, 2006

SAP On-Demand — some key points

Here are some of my quick thoughts on SAP’s CRM On-Demand announcement:

1. One of the biggest barriers to SaaS (Software as a Service) growth in my opinion has been the question of data integration. Some of my data is at a service provider. Some is inhouse. How do I integrate it? How do I analyze it? SAP has provided a very good but still partial answer to those concerns by ensuring that its hosted and onsite versions of an app have the same APIs.

2. I say “partial” only because I’m having trouble envisioning many scenarios in which a customer would really want to have some of its data inhouse, some outsourced. It seems like the main benefit would almost always be as a transition strategy.

3. That said, sales automation can be one of the exceptions. The distributed computing problem for serving sales offices around the world may be much greater than that for the rest of one’s apps, so outsourcing that aspect of network management is not totally ridiculous.

4. Anyhow, this was obviously the way the software industry was headed. Indeed, it’s the way a lot of the industry did business until the first half of the 1980s. There were timeshared and onsite versions of the same products, in many cases. That strategy only died out completely when DBMS replaced file managers as the standard underpinnings to packaged apps, and that didn’t happen until the rise of relational DBMS in the second half of the 1980s.

5. I’m sure there will be issues with functionality, pricing, service responsiveness, and similar aspects of nimbleness. There’s no guarantee that SAP will establish and commit to a viable sales model for this service; it may always remain an afterthought. Even so, it could be enough to slow the penetration of Salesforce.com et al. into large enterprises.

6. To succeed in a big way, SAP has to establish a separate sales force, with a separate marketing budget. It also has to cross-commission between packaged product and SaaS sales. Those sound like slightly contradictory strategies, so there’s no assurance they’ll do both. Mark Benioff doesn’t have to panic quite yet.

7. The other non-trivial organizational problem SAP needs to solve is having one product development organization serve two sales force/marketing group masters. The closest thing they’ve done in the past to that is with NetWeaver, which is both a key technology for other SAP products and an important product in its own right. Their answer has been impressive fundamental engineering, but perhaps less “sizzle” on the surface of the product than it needs for maximum success. E.g., the BI products are significantly held back by their UIs, and serious attempts to fix that in my opinion just started last year — no offense intended to those hard-working people who might suspect I’m implicitly calling them “unserious” with that judgment.

Bottom line: Like most cases in which a huge and hugely successful company invades the core market of a rival, this effort will need to be judged several years and releases down the road. And the most important deciding factor will be whether or not there’s ongoing commitment to succeed in this new market, on a level comparable to the commitment with which the company pursues its much large core businesses. SAP has already shown such a commitment once this century, in NetWeaver. It’s too early to tell whether they’ll do so a second time, in SaaS.

January 20, 2006

The Power of Portals

I did a webinar last week on portal technology. On that webinar, I promised to post a link here to my whitepaper on third-generation analytic business processes. Done. (Scroll down to the bottom of the page.)

The webinar was pretty fast-moving, so I’d encourage you to replay it if you have a bit of time. But if you want to know just the tippy-topmost key points, the list is something like this:

January 19, 2006

When bloggers get silly

I generally find blonde jokes to be stupid, demeaning, and above all incorrect (I’ve known plenty of very smart blondes). So in the face of very limited competition, I am inclined to agree that this is probably the best blonde joke ever.

Apropos nothing, I don’t think I’ve yet shared with blog readers my favorite glossary entry either, originally from the documentation to Inference Corporation’s expert system tool ART and gleefully plagiarized in my Application Development Tools from A to Z:

Recursion: See recursion.

← Previous PageNext Page →

Feed including blog about enterprise technology strategy and public policy Subscribe to the Monash Research feed via RSS or email:

Login

Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.