he articulates his perspectives briefly rather than presenting a connected argument
This has something to do with knowing that there is a limit to the interest in the technical detail ... I am always open to being asked for more ... and wanting to avoid boring people with overly long presentations.
Their cooperation improves the likelihood that each will increase their markets.
The reason I find the announcement trivial is that neither company is doing anything substantial that they would not have done anyway. Intel is and has been moving into higher end servers so naturally they would like as many endorsements and as much support as they can get related to software associated with that arena. BEA wants to run on whatever the customer wants to run it on. So, instead of it being entirely up to BEA to tune performance on Intel platforms Intel is going to help them out ... which any hardware manufacturer in that realm would do, with or without any agreement. Someone just saw a good opportunity for a press release.
If the network were the computer, then Coleman decided BEA would provide the platform for network computing.
One really ought to be acknowledging McNealy in this, especially considering the Sun ancestry.
BEA integrated these four building blocks into a single, unified, virtual, e-business platform focused on solving specific business problems
For a somewhat more comprehensive solution, I suggest you check out iplanet.com , particularly the diagram on page 3 for a simple visual summary. For more extensive information, go to iplanet.com and follow down the tree for each layer to the products currently available in that layer.
Solving this problem of interoperability requires a platform that: (a) provides a complete integration solution-enabling the application server to develop and deploy new applications rapidly; (b) benefits from a common XML-based messaging protocol-permitting all applications, without customized point-to-point effort and expense, to communicate in the same language; (c) performs bi-directional integration-both calling existing applications and sending events to interested parties automatically; (d) transforms data between two systems easily-data mapping between two systems by using a standard protocol (XSLT) to transform XML documents from one schema to another; (e) coordinates transactions-spanning existing systems within the enterprise and across B2B partnerships by using the XA protocol to enable non-trivial collaborative business processes; (f) simplifies security and authentication-managing security contracts and sign-on; and (g) expands scalability-allowing many clients to use the system by pooling and reusing connections to external systems.
You have basically just written a lovely ad for iPlanet Integration Server, formerely known as Forté Fusion, except that you left out the part about the process logic engine and the security piece would be done with LDAP.
The Internet raised the bar on business-critical systems by requiring dial-tone-quality service
Again, credit where credit is due; McNealy is the big champion of "web tone".
BEA's discontinuous innovation was the WebLogic E-Business Platform because its comprehensive infrastructure:
Aggregation is not innovation and it is certainly not discontinuous. If it were, then the iPlanet product family I pointed you to above would be double discontinous or super-innovation by comparison. Besides, Websphere provides a comprehensive infrastructure too.
The fifth wave of n-tiered architecture moved intelligence away from both the database server and thin-client into a middleware tier, consisting of a variable number of software servers.
If anyone would like to read Paul Butterfield's classic paper on the issues in distributed architectures, drop me a PM with an email address and I will send you one. I can't find it on line right now.
But, as I have said previously, the all time walkaway champion of enterprise class, highly scalable, distributed applications is Forté and they still blow away anything that one can do in Java, if for no other reason than that Java doesn't have the standards to cover all the necessary services, e.g., distributed events. Some of these are covered in the standard now undergoing definition which is sometimes referred to as Java.next, but per Butterfield, who is not only the CTO responsible for the Forté product, but also responsible for the FFJEE product which is the closest Java equivalent, it will be the standard after Java.next before the Java standard fully encompasses all that the Forté TOOl environment does today.
I.e., whatever it is that BEA has, it is not unique in the Java world and it is not best of class if one relaxes the requirement that the product be in Java.
FWIW, Butterfield is also one of the principle proponents of the services orientation ... most of which has been an architectural feature in the Forté product since its inception.
What is discontinuous and differentiating in this architecture is that it is simultaneously comprehensive, innovative, powerful, and integrated.
Only it is far from innovative. If nothing else, this orientation and architecture have been taught as part of Forté 101 for years. It is not new; it is imitative and still catching up.
One outstanding example of the superiority of this product is the architecture of the Business Process Management's Process Model
Again, catching up on Forté's Conductor business process logic engine which is bundled with iIS (Fusion) (see iplanet.com.
. I believe "standards" and "products" are conceptually distinct.
Agreed, and are we not looking for a "proprietary open standard"?
It is possible to have J2EE architecture that is also proprietary.
In the same sense that Word or Excel are proprietary, of course. But, those are products built on top of the standard. Those particular products have themselves achieved such a dominant market position that their interfaces in turn define a standard, but the standard and the product are not the same thing. For BEA to have defined a proprietary open standard, they would have to have done something like get everyone else to agree that the interface to their business process logic engine is the one that should be universally used. It is comparable to LDAP as a directory standard, but again, that is not proprietary.
At the risk of making this post even longer, let me summarize.
1. All of the standards involved in the Java market for distributed applications that I can think of are open, but not proprietary.
2. This is a very standards-driven, anti-vendor-lock-in market that insists on key components adhering to standards and eschews proprietary vendor extensions which are not in the form of portable components or products which can be isolated and combined with products from other vendors.
3. BEA may well have a market share lead at this point, but this market is in its infancy and they can easily be swept to the side by another strong player.
4. BEA's product line, while it sounds good touted on its own, is far from unique either in completeness or in the strength of individual offerings.
I really think that one cannot meaningfully analyze BEA on its own. One must analyze their competition as well. I.e., one must really analyze the market and have BEA emerge from that analysis as the leader rather than picking BEA as the leader on the basis of short run market figures and then believing everything BEA says about why that is so.
By way of comparison, we cannot just look at Qualcomm and listen to what they have to say about how wonderful they are. We must also look at all of the competing technologies and vendors and we must look at the market and its forces, reasoning about what changes will occur and what this will mean for all of the competitors, including political and other factors independent of actual product quality. I think we have that kind of view of Qualcomm. I don't think we have that kind of view of BEA. |
