Two notes
1. I've recently been promoted - my new title at Elastra is "Chief Software Architect", and I'm now reporting to the CEO, Kirill Sheynkman. I am responsible for Elastra's technology direction across its product lines.
2. Elastra is hiring! If you want to change the world of enterprise service management and provisioning, can contribute to a world-class team, and are located in (or want to relocate to) the San Francisco Bay Area -- send me an email.
This ode is bittersweet.
I've worked for a number of companies over the past 11 years, but I didn't love a company the way I loved BEA. Perhaps it was the Orfali , Harkey & Edwards Blue Book, which convinced me to abandon data management & become a programmer back in 1997 (Jeri Edwards was a VP at BEA at the time), or it was the talk about unifying OLTP with CORBA, or the acquisition of WebLogic, I *wanted* to work for that company since I got out of college. There was something about the lure of middleware that I liked -- the idea of integrating, communicating, and enabling people to work faster. My best friend, Greg Peres (now a lead software presales architect at Sun Microsystems in Canada) took a photo of myself outside of BEA's new HQ when I first moved to the SF Bay Area, back in 1998 ... which I will post here if I could find it in my boxes of stuff!
In 2004, I got the chance to work for BEA in Toronto, Canada, as part of their Strategic Consulting Services practice, then under Fabrice Lebégue (now at Boston Consulting Group). Mark Janzen, one of their top consulting architects, (now at IBM) brought me in while we worked together at Rogers. The idea was to bring executive-level consulting to the software pre & post sales process, which was deemed necessary for SOA initiatives. The group would try its best to do work independent of BEA products, though obviously the goal was to drive demand for BEA software through developing relationships. For a variety of reasons, the group was disbanded in 2005, and I wound up as something of a one-man department in Canada, the "technical lead" for the region - something of a hybrid SE, Consultant, and PR Representative, and continued in that capacity through 2007. It was a great ride. I learned a tremendous amount about the software business, consulting business, and vendor politics. I helped many organizations in Canada and forged great relationships across many sectors, and got to visit all of Canada's five time zones.
But, by late-2006 I felt BEA was losing its way. The initial AquaLogic push was good, but it spread our engineering resources thin. BEA's SOA vision, which started well, became something of an empty marketing slogan, like how '.NET' was destroyed within Microsoft. I tried to make changes from within, and joined Cliff Booth's Worldwide Enterprise Architecture group, setting consulting and SOA policy for the global consulting organization. We worked quite a bit on a modeling approach for service architectures. While I learned a lot about modeling, and architecture, the kind of work and style of long-distance collaboration was just not suited to me. I was the Data Management & REST advocate on the team, and often felt I had to spend an inordinate amount of energy to get my points across. Oracle's acquisition attempt in October didn't help matters. I was emotionally and mentally drained early into the job and found it difficult to stay motivated or productive, since I couldn't see how our efforts would save this company that I once loved.
It also didn't help that I had stopped believing that SOA would make anyone's life any easier, and reading some of the ITIL v2 material that was guiding our efforts also really just seemed to reinforce that we were following in the grand tradition of "smart people building skyscrapers to nowhere". I don't begrudge the team -- Cliff, Stephen Bennett, Wayne Boland, Mark Wilkins, Dave Chappelle, Bob Hensle, are some of the brightest guys I've had the pleasure of working and arguing with. Cliff is one of the best executives I've seen at fostering a creative, but accountable, environment. I'm sad to have let them down. But our team was just a microcosm of the larger problem with BEA: while we were doing many things right, we just weren't doing the right things, in my opinion. I announced my departure in early February, for the end of the month.
One could see Oracle's acquisition as the culmination of BEA's failure to emerge from the dot-com bubble burst. I don't entirely buy it -- Alfred managed to grow the company to $1.5b from $950m in 2001 when Coleman, then CEO, left. That's quite an accomplishment, if short of expectations. BEA was still performing, people were still buying its products, and a lot of the b.s. about JBoss or other competitors eating its lunch are rather exaggerated, in my opinion. I claim no real insider information, and am speaking for myself when I say, there is one primary, clear, reason for BEA's failure, in my opinion, and anyone "on the ground" in the company would likely agree with it: after the early-2000's recession, finance & legal -- the bean counters -- became the kings of the company. In other words, I believe BEA's wounds were self-inflicted.
Once the goal ceased being innovation & great software, it was about a pristine balance sheet, milking the support organization, and onerous following of extremely conservative accounting guidelines. There were still leaders -- Alfred Chuang still had fire in him, some product executives like Guy Churchward were bright spots, Paul Patrick in the architecture organization was also a great source of ideas (but given power far too late). Many in the sales organization knew how to make customers feel valued, and were rewarded righly. But all of them were beholden to the bean counters. Oh yeah, and there was an options scandal that one hoped would shake the power of the finance department. (It didn't.)
BEA has some great products that decayed under the product executive leadership over the past 2+ years. I don't know the complete reasons for this, I just know the results. WebLogic Server continues to be, in my opinion, the gold standard of J2EE application servers (and I've used most of them). Yet it's maddening that something as important as their management console -- arguably the defining feature of the product vs. open source alternatives! -- became dog slow. WebLogic Workshop was productive for specific products but made the transition to Eclipse years later than it should have. AquaLogic Service Bus was a visionary product, and has some great understated features for validating the dependencies amount service artifacts. But it's lack of support for RESTful services is also maddening, considering how little work would need to be done (for starters, just enable PUT and DELETE, folks!). AquaLogic DSP was another visionary product, but way too programmer-centric in a world where programmers don't give a crap about data. They needed to target the DBA or the RESTful crowd, but the small & dedicated team was too busy trying to improve the core engine with the resources they had. BEA WebLogic Integration v8.1 SP2+ was the swiss army knife of integration tools, and probably the best game in town circa 2003-2006. WLI could smoke Oracle BPEL on performance, usability, and complex transformations. But v9 was disastrous. WebLogic Portal had one of the most ambitious set of goals, and an extraordinarily bright team. But they too were plagued with quality issues, arguably due to a lack of bandwidth, and a need to compete with Plumtree internally. The Plumtree team got off to a great start with the PEP products, but I doubt if we'll ever see the fruition of that idea.
As of today, May 9, 2008, the BEA I loved is dead. A surprising number of people I knew there in Canada, and in San Jose, have either left over the past 2 months, or were sacked this week, as part of the transition. Some great products will be put out to pasture. In Oracle's defense, many of the "leaders" who oversaw the decay of this once great company were also a part of this culling. The field organization and deal support teams in particular were in dire need of a shakeup (expect Oracle to reap great benefits by -- finally! -- cutting BEA's cost of sales to reasonable levels!)
One could say that it's "the day that middleware died". Perhaps that's a good thing, in the long run. In many respects, we have a new approach to middleware that surrounds us, if only we'd take advantage of it.
I leave you with this photo stream, of some memories, and of my last operations meeting at BEA, held at Great Cooks in downtown Toronto, where we made our last meal together....
I recall since the Napster days that the effective way to monetize music production (and maybe software production) in the future will be a capital market, where the dividends are "more software or music from this artist". This eliminates the need to monetize every single copy, something nearly impossible given how prevalent digital copying is (and should be).
Now, Radiohead is saying the price of their new album, digital or disc box, "is up to you"
Of course, this is only for the next few months, before traditional distribution kicks in. But it is telling.
What will be interesting here is how the whole free rider issue plays out. There's the traditional free riders, those who copy off of Torrents, Newsgroups, or a P2P network. The question is whether a new class of free riders will emerge to pay very little for a legitimate copy.
What's missing here, I think, are market indicators -- how much are other people paying? What's the bid spread? Prices will tend to converge, then.
From Vinnie Mirchandani's blog on the side of the enterprise software industry that many in the technology trenches don't see: "rules" that need to be broken, such as the revenue recongition noose, or the spending model of SG&A vs. R&D (which, while needing reform, is often exagerrated by the larger open source companies who seem to be following a similar model).
Anyhow, lots of insight to read there.
The culture of sales organizations and salespeople is a fascinating thing. I started getting into sales around 10 years ago (the I Hate Selling book was useful to me), but only recently have I witnessed sales management culture, the relentless pressure, and the personalities.
Sales people have such a unique role and set of responsibilities that few can handle. Examples include:
Some wonder if sales is even necessary -- if marketing can make products "sell themselves", or if the world will become dispassionate logical evaluators of purchases, or that legal & financial negotiations will become manageable by small companies. Somehow, I doubt it.
Apple is charging $1.99 to activate the 802.11n support in select products, a feature that was left dormant to date.
I've been seeing lots of confusion about how the generally accepted accounting principles led Apple to charge for this, so I thought I'd give a few words on this matter. I'm not an accountant or a lawyer, but based my experience working for a software vendor, it's absolutely true.
Here's my layman's explanation.
Firstly, when a company sets accounting rules in place, it's mostly about setting up money buckets that are broken out for reporting to management and investors. Examples of buckets at Apple include: Macintosh, iPod, Peripherals, Software, etc. One has to be consistent in counting these sales, or else a company can slush money from one bucket to another if a product line isn't doing very well.
Secondly, because of the blurred lines between what is a software product and a service, and plenty of accounting shenanigans over the years blurring the two, there are very strict rules about when a public software company can "recognize" product revenue.. In the past, if a company that sold hardware, services, and software, was having a bad quarter, they'd sometimes sell a combination of services and software and be very liberal in its accounting (for example, discounting services to $0 and allocating the sale to license revenue). Or, alternatively, they'd discount software to $0 and accrue the balance to hardware sales.
Now, vendors are required to document "Vendor Specific Objective Evidence" (VSOE) for products that have multiple deliverables, which basically is a puffy term for "standardized prices". This way, if a software company like Microsoft, BEA, or Oracle were to also sell professional services, they must sell those services at or above the VSOE hourly rate (subject to variations).
Here's what may have happened: Mac OS X has many bundled features, and their accountants broke out the features by VSOE. And, it seems that device drivers have a deemed value of $1.99. Apple can't give it away the 802.11n enabler for free because they can't recognize the revenue on their hardware until all the pieces are delivered! They have to break out the 802.11n into a separate product that's not tied to the original product, and sell it at its VSOE-documented fair value to demonstrate this wasn't really just a hidden software discount intended to inflate hardware revenues.
The above may all be false, and again, I'm not an accountant, nor do I have inside Apple information. If you're interested, the standards are SAB 104 and SOP 97-2, which Apple claims it conforms to in its SEC filings.
Update 2/13/2007: A colleague at BEA, Tim Joransen, suggests that Apple likely picked $1.99 for just this case and it has nothing to do with VSOE, it's just a case of avoiding deferred revenue & a restatement.
"The equivalent for would be to try and recognize revenue for a product feature that isn't yet shipping. Say we are selling Product X. We are shipping 2.6, but the customer really wants a feature that we plan for 3.0. If we in any way promise the feature for 3.0 and tie it to the deal, then we cannot recognize the revenue until 3.0 ships.If Apple had not monetized it some way, then someone may have made a case that the product wasn't done and the revenue should have been deferred...leading to a huge restatement."
This originally was a comment on TechDirt. I've edited it and provided more context.
The Apple iPhone is causing a lot of buzz and seems to also have garnered the world record for "quickest digerati backlash" in recent history, perhaps ever. On Tuesday, the tech gadget world was wrapped in a collective orgasm: Steve buzz-jammed CES, the iPhone was everything one hoped for and more, the iPhone appears on the front page of several national dailies.
Then, the harsh reality sets in by week-end: it's a controlled platform, it's on Cingular, there's no tactile keyboard, "where's my 3G?", and Apple is going to be fighting the first of many intellectual property battles -- currently with Cisco, on trademarks, eventually on its large portfolio of patents it has amassed to protect the iPhone from poachers.
One concern is the issue of the closed nature of the iPhone platform, particularly its patents. Should Apple rely on these, or should it avoid patents & protection and just "innovate its way" through the competition?
This goes beyond Apple, and really is a classic problem and it's one posed in various guises by the Free Software Foundation and open source advocates, etc.: Should you restrict a one's freedom of use with your product? I think it's becoming clearer that the answer is "partially and temporarily".
So I'm going to use the iPhone hype to talk about the economics of openness when dealing with knowledge-intensive products -- like new gadgets, software, music, etc.
Continuous innovation is absolutely necessary in a growing economy, but it isn't sufficient. One requires a functioning marketplace in order to cover the costs of innovation today & tomorrow (through entrepreneurial profit). Schumpeter was one of the first that came up with a model of economic growth driven by entrepreneurship and innovation, one that implied that markets really weren't ones of "equilibrium", they were constantly changing in a disequilibrium of what we would now call "monopolistic competition".
There's a whole body of theory emerging from economic New Growth Theory, starting with Paul Romer around 1990, with his paper Endogenous Technological Change" about how innovation that involves new applied knowledge leads to growth.
According to Romer, "growth is driven fundamentally by the accumulation of a partially excludable, nonrival input". Non-rival goods are goods where more than one person can posses it, e.g. an idea, a copy of a MP3, software, etc. Goods that are partially excludable imply the creator of the good can prevent people from using it or re-producing it to a certain degree. This isn't just about law, by the way, it's about the theoretical ability for something to be excluded (whether through physical, technological, legal, or other means).
Knowledge -- one of several inputs into successful innovation -- is non-rival and at best partially excludable (it will eventually leak out). Intellectual property law is one way to enact this exclusion, though it's got problems (it doesn't typically stop copyright violation, for example.) DRM is another means of exclusion (which also has debatable effectiveness).
A fully non-rival, non-excludable good is a "public good", and exchange of such goods really isn't governable by a marketplace. Excludability is the death knell of market dynamics: If I can't prevent someone from using or reproducing something, I can't really exchange it in a market as there's no demand incentive. That means I can't cover my costs of today, and I can't cover my costs of tomorrow through profit, leading to no supply incentive. This dilemma is also known as the "free rider" problem.
The environment, for example, could be considered a public good. Any restrictions on the use of the environment can't really be settled well through a market, they have to be through legal means. One can invest in the environment but there's no market-oriented way to monetize the benefits, as others will 'free ride' on your investment.
So, the point is this -- if we feel that human capital & knowledge capital is valuable & scarce, or perhaps that we feel that time is scarce and time is a big factor in how much knowledge is generated in a new technology, we have two choices:
Solution #1 has the benefit of working when the investment is directed at something that can create new customers, new markets and avenues for growth. Examples include the TCP/IP protocol suite and many open source projects. The big problem is that results are hard to measure. This approach has the potential of squandering tremendous resources because it's not directly subject to market demand. At an extreme, one can look to a government industrial monopoly. As a smaller example, witness the explosion of duplicate open source projects out there that all "scratch that itch" just a bit differently...
Solution #2 works too, is often more efficient at allocating resources at opportunities in demand, but by nature will lead to onerous temporary restrictions on freedom of use.
My view: I caution people from having delusions of one system being clearly superior to the other. In a market system, the trick is to find the balance between utility and restriction. Which shouldn't be surprising -- it's the same advice Hal Varian & Carl Shapiro give in their wonderful book Information Rules
There's a lot of innovation happening on the copyright front with software. Redhat, for example, absolutely takes advantage of partial excludability in its products: it offers limited avenues for accessing the software, it requires a paid subscription service for the most accessible channel, it has incentives to pay for complementary services (support, certification, etc.), all of which add up to a balancing act between choice #1 and #2. Not too many have pulled this off successfully at scale, and it's great that they're profitable doing so, to serve as a model to others.
Back to Apple and the iPhone. It strikes me the reason so many get angry with Apple is that we feel helpless -- the market has failed in generating enough suppliers that truly care about synthesizing a balance of features for broad appeal, while focusing on usability and aesthetics. So we almost feel dependent on Apple's monopoly on "cool, fun and usable".
Apple's major advantage and contribution to economic growth is in its ability to keep finding the right combination of new knowledge and integrating it into a mainstream digital consumer product. In that light, patents make sense to me. There's way too much opportunity for a free rider problem. The industry is littered with "me too" products, or products that are so specialized in their appeal that they don't garner much widespread interest. If too many take Apple's R&D and create a "me too" product, that undermines what makes Apple so valuable to the economy.
Similarly, if the iPhone is "too open" from day one to 3rd party developers, it may also suffer the death from a thousand cuts where quality and consistency suffers due to early release bugs. This too undermines Apple's speciality of delivering an integrated synthesis & balance of features. As a comparison, the Java platform was undermined at first, with a proliferation of varying quality implementations (e.g. Sun vs IBM vs Microsoft vs Netscape's) that doomed its potential on the desktop. It was through Sun's careful control over licensing that Java flourished on the server. Some may debate this and claim that open sourcing Java would have enabled a better outcome -- and they may be right, as it would have been one codebase at least. But the point is that some partial, temporary excludability is often very useful.
Does the patent system need reform to get rid of trivial or obvious patents? Yes. Does it make sense to reduce the number of years a patent is valid? Yes -- innovation cycles are quicker, markets respond faster, etc.
Should Apple avoid patents and let the innovation in the iPhone become more of a 'public good'? Probably not in the short run. It's not in the interests of their employees, shareholders, or customers, who want Apple to continue to invest in technological change as a way of increasing its capacity for creating wealth.
Sometimes it's better for all to 'spread the wealth' rather than keep it localized, but to me, it's not clear that this is such a case.
Microsoft is amassing a patent portfolio, and while they haven't used it yet, they most definitely will at some point.
I've seen concern in two areas here:
a) they will trounce on web services competitors
b) they will trounce on Linux
While it's certainly possible, I think are a lot of problems with these scenarios. This entry was adapted from a Slashdot post ... read on for more...
Once again, Nicholas Carr is trying to make a living out of doomsaying. The IT industry's glory days are over, software is stabilizing, costs are going down, there's little left to innovate.
Microsoft's move to dividends + their accumulating cash hoard staying rather stagnant could be seen as a sign of the decline of IT. I actually look at it another way: it indicates that capital is no longer the primary factor of production. Knowledge is.
Software today is expensive and solves "old" problems -- problems we've had for 20 to 30 years. We're getting pretty good at nailing them down, though we still have a way to go. What's interesting is that we haven't really tackled the "new" problems. What are the "new" problems? For a glimpse, take a look back in recent history at big fringe ideas that were ahead of their time...
I firmly believe the next empires of IT will take advantage of knowledge as the central resource of an economy. And will catch the rest of the world by surprise.
The Economist has a decent article to supplement my last blog entry.
Most of the drop in prices for PCs, mainframes and so on was caused by the relentless advance of technology; but she still thinks that trade and globalised production—all those Dell Computer factories in China, for instance—was responsible for 10-30% of the fall in hardware prices. These lower prices led to higher American productivity growth and added $230 billion of extra GDP between 1995 and 2002, equivalent to an extra 0.3 percentage points of growth a year.
The "she" in the above quote is a reference to Catherine Mann's recent paper that shows drastically reduced PC hardware prices during the 1990's are in part due to offshoring. Note that Mann's article is referring to productivity growth due to increased use of IT: this is still growth beneath the knowledge worker productivity "plateau" I was describing in my prior entry. This plateau also should be seen as a "slow growth" plateau, not an immovable object. It also is purely a qualitative theory, intended for provoking discussion.
This productivity "plateau" also is why I think you're seeing the Does IT Matter? controversy bubbling up: IT can only bring so many advantages, we need new human techniques to increase productivity. It just so happens, however, that I think such techniques may just come out of the IT world, whose fringe has a lot of experience with high performance teams.
Unfortunately, the Economist does include a sour raspberry:
As for the Indian threat, “offshoring” is certainly having an effect on some white-collar jobs that have hitherto been safe from foreign competition. But how big is it, really? The best-known report, by Forrester Research, a consultancy, guesses that 3.3m American service-industry jobs will have gone overseas by 2015—barely noticeable when you think about the 7m-8m lost every quarter through job-churning. And the bulk of these exports will not be the high-flying jobs of IT consultants, but the mind-numbing functions of code-writing.
To think that code-writing is mind numbing shows a complete lack of respect and understanding of what goes into such knowledge work. The analogy between a coder and a factory worker is a common one, but is a perfect example about why the mainstream collectively has zero clue about how to raise knowledge worker productivity: they're still stuck in scientific management's old methods.
One cannot set up a development shop in terms of tiers of archtects, designers, and coders, with coders being nothing more than "skilled labour", and expect to get the productivity advantages of the best teams. Nor can you expect coders to be in a completely different time zone. The communication overhead is tremendous in such a team, and agility (for changing requirements) necessitates decentralized decision making. This is a major constraint on offshoring IT software development jobs: for projects that have stable, well-known requirements, it can work. Otherwise, you'll want something as co-located as possible. Requirements change, priorities are re-ordered, understanding evolves. Software developers are organized around ambiguity, whereas traditional production is organized around physical constraints.
Alas, we may be quite a ways off from getting the mainstream to understand this.
