Welcome

Photos of Larryblakeley
http://www.royblakeley.name/larry_blakeley/larryblakeley_photos_jpeg.htm

(Contact Info: larry at larryblakeley dot com)

Important Note: You will need to click this icon to download the free needed to view most of the images on this Web site - just a couple of clicks and you're "good to go."

I manage this Web site and the following Web sites: Leslie (Blakeley) Adkins - my oldest daughter

Lori Ann Blakeley (June 20, 1985 - May 4, 2005) - my middle daughter

Evan Blakeley- my youngest child

At Borland Software Corp., Microsoft Corp., his startup Crossgain and now as chief architect at BEA Systems Inc., Adam Bosworth has shepherded more than his share of XML and Internet standards. Now, with his WebLogic Workshop framework released as the open-source Beehive project, Bosworth is setting his sights on extending the browser via the Alchemy intelligent caching framework and conversation with the server. In an exclusive chat with eWEEK Senior Writer Darryl K. Taft and Contributing Editor Steve Gillmor at BEA's eWorld developer conference, Bosworth explored Alchemy's role in BEA's move to the next generation of service-oriented architecture and its implications in the development of new information routers.

What was the paper that you wrote that led to this whole Liquid Computing initiative?

What was the basic premise of it?

The paper that led to this whole … what was the highfalutin' term? Liquid Computing, right. The paper was called "Thinking Ahead." About every 10 years or so I tend to write a paper that is subversive. This was my latest one. The last time I wrote one was in 1995 at Microsoft. So it was called "Thinking Ahead." And I asked BEA at the time if I could publish it, but they seemed to think it was BEA's crown jewels. So we did not.

Now, what I did it wasn't rocket science. Fundamentally, I said, look, the problem our customers are having is there are fewer and fewer developers available to them, because they're outsourcing and they're off-shoring. They're being asked to keep the systems up more and more, which means that even if there were developers, it's harder and harder for them to make changes because they have to bring the systems down when they do it.

There are more and more changes being demanded of them more and more rapidly because they're under the pressure to respond more and more rapidly to business events. And they're unhappy. And if we're going to make them happy we're going to have to move away from thinking about the IDE [integrated development environment] as the center of the world and move toward what I call a business console as the center of the world, where more and more work gets done from a very smart business user at the console and less and less work gets done by a programmer writing code.

Now that I've just laid that out, what does that mean? What does it mean in terms of enterprise computing? There are different pieces to it. One thing I laid out was something called a message bus. This is what is involved in Project Quicksilver.

Quite honestly I don't think the memo was particularly insightful; it's just stating what I heard in the last year from customers and saying if we're going to add value … if you're BEA, in my book, you have to figure out how to add value where the other guys you're competing with don't. And last time that was building .Net for J2EE and figuring out how to bring 5 million developers into the fold—which we're still finishing. And we're thinking about how to bring 50 million developers into the fold, including business users. And that's a long-term agenda. And what I hear clearly from our customers is that's what they want.

So, for example, there's a company and they've got portal servers and they have portals in London, portals in New York, portals in Hong Kong, and the portals are different. They assume where you are you can buy real estate in Hong Kong; you can buy stocks in London; and other things in New York. But they're also different based on what age group and demographic and on what you say you want to do. And they want obviously to cross-sell as much of the stuff they've got as possible. And they want to constantly test this where they modify how the site reacts to who you are and what you've said and what you're doing. And then see how much more that effectively cross-sells or didn't cross-sell the product.

Well, they can't really do that right now because there's such a reduction. They want to be more like Excel. Some smart business guys come along and test some changes and see how it works, and test some more and see how it works and just iteratively hone in on the most effective Web site, and then over time that might change. And then to do that you have to change what it means to build a portal—something that's much, much more how the portal works.

We get the same issue with workflow. People love the demo we did today, but then they run into the case where they want to change the rules dynamically in more profound ways than that demo made comfortable. For example, you know they're discovering that there's a step not being covered in registering goods, or they now want to be able to handle for certain classes of customers if they're overseas or whatever. And they want to be able to dynamically commute and modify, but they don't want to bring the system down. Well, they can't do that today. Typically when you go in and modify code you bring the system down, even if it's just briefly. And what's more, it's code. And any change in the code you worry that you've broken the system. So there's a lot of testing that gets done.

So the memo was just about how could we do this better. How could we make it easier for a large group of people … and I don't think it puts us in competition with, say, Microsoft because Microsoft, and I speak from experience from when we built Access, looks at things in regard to a minimum acceptable number of customers as 50 to 100 million. And most of the Office products have a lot more. And they don't build the product for the business user. As far as they're concerned they want very, very large markets. So they want to get at the person I called the end user on that magic triangle I showed today. This is a subset, or what I call the smart business user, which is probably more like 20 or 30 million people. So it's too small; it's below their critical mass. And there's certain things I need to do and people at BEA know how to do, and customers need done; so there's an opportunity for BEA to differentiate.

On the other hand you mentioned a blog reader, for example. But in the larger macro view how you monitor user input and what users want to do in terms of routing information, that would certainly get the attention of Microsoft.

Look, Microsoft does everything. So anything you do in software gets their attention. The issue is where do they put their focus? And they tend to put their focus in platform and in large market. They're an economies-of-scale company, and every time they try not to be an economies-of-scale company they don't do very well. Every time they actually do focus on economies of scale they normally do fairly decent.

They've never done particularly well at what you just described—which is not to say they couldn't. For example, I run on Exchange and I have my calendar. And I am highly mobile. So wherever I am in the world, so are my people. I've got teams in India, in Europe, what have you. Just having a calendar and when you enter a time and you enter it in time relative to your location, so that no matter where I am I can see when it's occurring, is not doable. Because they're still more consumer than enterprise focused. And it drives me nuts, because what I end up doing is right now I think it is 2:11 p.m. [instead of 11:11 a.m.]. Why? Because I go and look at my calendar, which is on Outlook … and I'll be completely confused about when I'm supposed to meet with you.

So, yes, they may want to do that. But let me give you another example. I spec'd out what SQL Server, at the time, 2002 should look like in late 1999. And I spec'd in most of the features people should want in sort of an SOA [services-oriented architecture] world. And it was pretty clear we could build those things, when I was at Microsoft, in 2002. But it's now very clear that they will not ship at the earliest until late 2004 and probably later. Now what happened? It's not that the engineers are inept, it's that they went and dumped a huge amount of consumer features into the mix that they needed to support things like the Exchange convergence and what have you because that's where the mass market was. The enterprise just wasn't mass market enough for them. So they made SQL Server focus much more on consumer features. Look at what they're doing with WinFS and then Longhorn, the same thing.

So, yeah, Microsoft could do that. They could try and say, and they will say, intelligent things about what happens on the server. For anything you want to build they'll say we want to do that too, but the places where they put the A teams—and even Microsoft only has so many A teams—are the places that have the highest return on investment, and that's usually the large economies of scale.

And that's why Google exists. Google exists because they were able to focus far better on search than Microsoft, even though Microsoft has far more money than Google. Google thinks clearly and well about what they do. Microsoft never got an A team on search.

But Google harnesses what I call the Tom Sawyer effect, which is convincing the user that it's in their interest to give Google the data so that they can turn that into metadata and turn around and sell that back to the users.

Yes. I always liked that part of the Tom Sawyer story. I'm naturally lazy. I don't mind seeing other people whitewash that fence.

Exactly. So is that a new economic model for generating architecture in the real world?

Sure. And I think that it's a very profound economic model. What I'm doing is I'm building some enabling technology for it. I'm not building all the plumbing you need for that economic model. Why? That's not my business. I get paid by BEA. And right now BEA's business is enterprise computing. My focus is, and I've kept BEA& #133; it's been my experience that companies that try to change who they are run a very high risk. And I remember this company called Personal Software that later became Visicorp and then vanished many, many years ago. And they vanished because they forgot who they were. What they really were was a spreadsheet company first and foremost. Mitch Kapoor went out and built Lotus 1-2-3 and it just devastated them. If we forget about the enterprise I think BEA would be in trouble.

And so right now my focus is to make sure that the value I deliver to this company is targeted to what enterprise customers want. So while I absolutely agree with you that those are needs and demands, we won't always deliver them when it comes into what I call the consumer server space. In the enterprise server space it's more interesting. But even there I think it's going to be a slow process for a company like ours to change ourselves to a more service-oriented company.

Isn't the enterprise versus consumer and personal versus professional a distinction that's largely blurred by mobile devices?

Why?

Because right now I'm getting an e-mail from my wife, but in a few minutes I'm going to get an IM from my editor.

You are, but let me take the reverse … my wife gets e-mails from me and she sends e-mails to me, but my wife is strictly a consumer. And she would use, as a consumer, quite a lot of the architecture I showed today. A travel company intercepted me as I was walking downstairs who wants to do travel stuff using this architecture. My wife would be happy to use that because she plans the trips, and she would be very happy to do that on a mobile device without having to be at a PC and learn about a cancellation or what have you. But the thing that you're talking about that goes with this, the sort of smart learning from users, the inference, the thing that made Amazon recommendations interesting … you know, we're going to go slow on that. It doesn't mean that it can't be done.

It could be big business. But there are a lot of big businesses we could do. And those companies that are not as rich as Microsoft and try to take on every big business end up not doing any of them well. And so twice in my life at BEA I've been asked should we go and take on really new businesses, and twice I said we should not because we haven't finished what we are doing yet. We have our hands full in the place we're in.

What benefit do you get from open-sourcing the Alchemy technology?

We get a whole bunch of benefits. The same reason that a lot of partners that we have who are hardware vendors get benefits. None of us makes money from client-side software. We all make money from server-side software or hardware. Well, if you don't make money on client-side software and we don't have a model for it. ... Our salespeople go out and sell direct and sell things that people spend $1 million a year for. That is not a client-side sell. Given that we don't make money, we're much, much more interested in the razor/razor blade thing and having ubiquity. If you want ubiquity, make it easy, make everyone do it, don't try to control it.

From our point of view we want to open-source it so people can plug into this back-end server architecture in as many ways as they see fit, including enabling Mozilla to extend the browser. They've got the ability to extend the browser; other people can write rich clients that plug straight in. Other people can write custom apps that plug straight in. And then for all of that customers are much happier when there's an open-source consortium or standard and they can see it and they can debug it. We're not even proposing to rewrite the browser. We use the browser.

That was the whole point of the demo, because at no point have we written a single line of UI [user interface] code, meaning anything that puts bits on the screen. IE [Internet Explorer] was putting all the bits on the screen, and it was telling us what the user did when they clicked. All we were doing was reacting, telling IE what to put on the screen and then figuring out what to do when the user hits it. So we act as this middleman on the client. And that's the code we're open-sourcing. The code we're open-sourcing is the sort of smart middleman on the client, which is smart data caching between client and server, the smart template rendering that pushes out to the browser, and the smart script engine that talks to the cache and the browser.

For example, in the demo Alex [Bosworth, Adam's son] did, when the Web service completed, a little thing showed up on the screen saying your order has been confirmed. The way that works is synchronization occurred between the client and the server. A callback occurred on the client in a script. The client promptly set a value and a working space that was being referenced by the page. The smart code we had said, oh, a script has just run—notice it was triggered by an event coming into the server. And it's time to refresh the page. And we refresh the page so that we now show that the order had been confirmed. That kind of thing is very powerful. It means now you can be listening at what happens elsewhere. And so that's the plumbing we want to make widely available and open-source and standard.

So what are you making money on? Volume?

The server. We've been talking to a lot of customers about what they'd pay for this. And the numbers are actually really big because what they're spending right now is horrendous. And virtually all of them say if you can give me a server. … And we're not building this yet; I'm not making a product announcement. But if you had a server that was not only a way to build Web sites but to build mobile Web sites as well, and also to be an adapter for the form factor for good behavior, and we could build these apps as easily as you're describing, and they work as well as you describe … they will pay us a fairly large amount of money per year for those servers. Money interesting even to us. It could become a very lucrative part of the BEA revenue stream.

Does that mean that there's not a market for a big service to do this too? Of course not. I'm looking at big service partners that we would license this to on much cheaper terms than the server, so they could deal on a much larger scale. We're designing this thing to be highly scalable. But our core competency isn't service and software, it's software. Our core competency isn't client, it's server. And so I'm focusing on what can we either sell to the enterprise or license to services as a product.

Sounds like HailStorm?

There are points of similarity. Except that HailStorm was also going to be a service, as I recall—at least originally. And, like I said, we're not Microsoft. We don't have $10 billion in positive cash flow to play around with. So we pick our battles.