Mike,
Like you, I also hope Paul Philp will respond to Thomas. I find it difficult to respond to Thomas because I am confident that he knows much more about software and the industry than I will ever hope to learn. Also, he articulates his perspectives briefly rather than presenting a connected argument. When he scatters his thoughts in brief bursts, they sort of glance off my wee brain, dazing me. Understanding is based on familiarity; I am unfamiliar with much that is commonplace in Thomas's everyday world of software in his business. So, I do not always understand his points and that probably reflects far more poorly on me than on him.
However, sometimes I do understand and agree with him, and sometimes I believe that I understand and do not agree. For example, in reference to this Reuter's story, "BEA, Intel in pact to offer WebLogic on new chips," Thomas said, "Too me this sounded like just an engineer or two tuning the software so that it would run better, not a major value chain addition." When I read this story, for better or worse, I drew a different conclusion.
To provide a context, let me cite some key statements in the article, "Intel has long dominated the world of microprocessors-the engine of personal computers-with its chips in more than half a billion PCs world-wide. But Intel wanted to move into the market for servers, the computers that are at the heart of the systems companies use to conduct business." And, "With the Itanium, Intel hopes to extend its dominance from the PC to the high-end server market, taking on Sun and other server makers." And, "For BEA the deal means its WebLogic products will operate very competitively on the Intel architecture as the chip giant moves into the mainstream business market and allow BEA to retain its lead in the application server market. And finally, "'The big deal about this is we both get to vastly expand out total available market,' Coleman said."
Now to me this story suggests that a gorilla, Intel, is partnering with an ostensible gorilla, BEA, because both provide foundational infrastructure. Their cooperation improves the likelihood that each will increase their markets. I view that as a valuable addition to the value chain that is more than a couple of engineers tuning the software. If Intel has entered into similar agreement with each of BEA's competitors then the significance for BEA would be far less, perhaps simply demonstrating Coleman's acumen in marketing. On the face of it, with plain reading and some knowledge of the GG, this is an addition to the value chain. It is not everyday that Intel moves from the MSFT operating system for PC toward the BEA platform for servers. If this development moves from planning to actuality, I believe many would call this a major development in a value chain.
Now let me turn to what I see as the heart of Thomas's skepticism, which is his contention that, "by definition, that there can't be a gorilla of Java appservers." If I understand him correctly, he believes than Java's "openness" in standards precludes BEA from having proprietary architecture with which to control its value chain. If so, my contention that BEA is playing a gorilla game is over.
I feel like David being sent out to battle Goliath, except mere words have to replace the stones in my slingshot. Now Mike had I really been coaching you, you would never make the mistake of asking me for detail (gg). So get ready, here comes ablizzard of words. To make my point, I believe I need to make a connected argument that examines these matters in some detail. I begin by including my version of some G&K criteria, acknowledging that I may be narcissistically in love with the sound of my own voice making my argument. If this degree of detail overwhelms and bores any readers, I apologize and ask them to skip ahead to the last page.
Vision and Strategy: If the network were the computer, then Coleman decided BEA would provide the platform for network computing. Given this vision of an enabling platform infrastructure and realizing that getting to market on time was essential to success, BEA made four strategic acquisitions: Tuxedo, for a transaction processing engine, WebLogic for a K2EE compliant application server, the Theory Center, for its know-how and 80+ EJB components, and Workflow Automation, for its process and workflow engine.
Using their unusual level of sophistication in integration technology, BEA integrated these four building blocks into a single, unified, virtual, e-business platform focused on solving specific business problems. Specifically, the platform enabled the development and deployment of e-business applications, the integration and management of disparate legacy and packaged business applications, the monitoring and improving of applications using visual tools to refine e-business processes in real-time, and the integration of multiple business partners to facilitate seamless collaborative commerce.
The complexity of integrating applications to ensure their interoperability functions like the inverse of Metcalfe's law, as applications increase arithmetically, chaotic complexity increases exponentially. Integrated complexity is good; non-integrated complexity is chaos. If you have 3 apps, it requires 6 connectors (N (3) squared = 9, minus N (3) = 6) for one-off point-to-point integration. If you have 50 apps, wiring 2,450 point-to-point connections requires too much time and money but still would not solve the problem. As business policies change, their business processes must be recoded in software and reconciled once again with other applications.
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.
Oriented toward solutions created by shared standards, BEA decided to standardize on all specifications of J2EE, and on all future W3C specifications developed to facilitate Internet and Web Services. Oriented toward solutions created by the power of abstraction, Coleman used a meta-strategy of abstracting and decoupling functions in layers of software that he called "divide and conquer." By abstracting small functional components of complex business processes and embedding the workflow into an Enterprise JavaBean (EJB) software code (for example, coding globally unique data into "entity beans" versus coding encapsulated business services into "session beans"), business processes embedded into software isolated and preserves their independent, but integrated, functioning, enabling Java-based software to "write once, and run anywhere."
The Internet raised the bar on business-critical systems by requiring dial-tone-quality service, always there without noticeable delay. Such QOS required high availability, scalability, and the superior performance of enterprise software. On the one hand, BEA achieved these enterprise features with standard Java software by using an innovative advanced software-only approach to clustering, which provided transparent replication, load balancing, and failover. On the other hand, their principal competitors introduced proprietary tags into Web content and proprietary logic into Java applications-locking customers into deploying on their server only and locking customers out of using business components developed for any other server.
Accordingly, BEA's sales strategy included contrasting their "openness and commitment to driving open standards" to the propriety lock-in created by rivals who had chosen to tie their application-server-software to proprietary hardware, databases, or software intended to achieve customer lock-in. Also, BEA's sales strategy emphasized "future-proofing:" how to integrate legacy applications and deploy build-to-integrate environment that enabled agile adaptation to the accelerating changes in the e-business environment, including how to become a virtual B2B organization for collaborative commerce.
Discontinuous Innovation: BEA's discontinuous innovation was the WebLogic E-Business Platform because its comprehensive infrastructure: (1) Is network-based rather than computer-based; (2) Uses n-tier rather than client-server computing architecture; (3) Meets the minimum e-business imperatives for a comprehensive platform; (4) Abstracts the Business Layer, which contains vertical business-logic applications, from the transparent Back-End Layer, which functions as horizontal-server-system-software that provides both QOS middleware to optimizes net-centric functioning and nested n-tier servers to integrate and optimize the performance of client-applications; (5) Simplifies and standardizes application development, deployment, and integration by replacing overnight batch downloading and point-to-point integration; and (6) Uses and drives open standards that increase productivity, portability, reusability, and interoperability without creating proprietary lock-in for vendors.
A network-centric platform for business applications focuses on optimizing connection and integration services rather than on optimizing scarce server processing resources typifying the fourth client-server wave. 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. Each server abstracts and organizes a different set of service functions. The n-tier servers are architecturally organized into functional units using the higher-level abstract principle of client-server-relationships. For example, a Business Process Management function may serve as a client that is hosted by either an Integration Server or a Collaborate Server, while a Security Server is simultaneously handling its own abstracted set of Internet security functions, as the QOS issues of operating the server farm continue to be handled transparently by appropriate middleware.
Proprietary Open Architecture: In June 2001, BEA raised the bar on E-Business Platforms by combining the #1 application server with Web Services, Integration, and Portal technologies into the BEA WebLogic E-Business Platform, which already included the #1 Tuxedo transaction processing engine. This comprehensive platform integrated Application, Transaction, Integration, Process and Workflow, Portal, and Web Services Servers into BEA WebLogic Server 6.1. In GG terms, this platform is in layer three: enabling systems software infrastructure.
The Application Server Architecture is composed of:
1. Container-the runtime environment in which deployed applications reside.
a. Presentation Layer-the face that allows users to interact with system.
(1) Java Servlets-perform presentation logic, like routing requests and require developer-level expertise.
(2) Java Server Pages (JPS)-render the presentation view and can be maintained by Web designers and extended by custom tag libraries.
b. Business Layer-the brain that encapsulates reusable business rules and data logic; also it provides advanced support beyond the EJB 2.0 specification, including advanced persistence services, performance optimization, and dynamic real-time deployment.
(1) Session Beans-business process objects, such as transferring funds.
(2) Entity Beans-data objects, such as bank accounts.
(3) Message-Driven Beans-messaging objects, such as a logging service.
c. Back-end Layer-used for application integration.
2. Administration Console-graphical console used to deploy, configure, and fine-tune applications that is accessible by Web Browser.
3. Command-line Tools-empower developers to enhance productivity by customizing to gain competitive advantage.
This architecture separates basic software system functions (reliability, fault-tolerance, load-balancing, security, and the like) into layers within the container that separate system services from application software. The presentation layer separates presentation logic, requiring Java-developer-level expertise, from the transparent Java Server Page's presentation view, requiring only a business analyst's skills to monitor and improve.
What is discontinuous and differentiating in this architecture is that it is simultaneously comprehensive, innovative, powerful, and integrated. One outstanding example of the superiority of this product is the architecture of the Business Process Management's Process Model. Either the B2B-Integration or B2B-Collaboration server can enlist the award-winning Business Process Engine as their client to design business logic for e-business processes. Whereas traditional one-off coding is hardwired into the application, the preferred Process Model uses the familiar flowchart paradigm as the basis for creating a design that the Process Engine automates and runs. According to Giga Information Group, "In general, companies can expect to accelerate their development/integration time by 50% to 150% using workflow instead of coding business logic into applications.
For instance, if you wanted to design software to encapsulate a specific business process, you would simplify the workflow by separating it into isolated sub-functions that comprised the elements in an end-to-end business process. Workflows have an interface, an input, an output, and events that it receives and generates. Using a graph to connect processes in sequence between start and end states, for example, elements, like "Start," "Task," "Event," "Decision," "Join," "Done" and the like, are specified. These processes can be encapsulated in Java software, providing flexibility and maneuverability by automating simpler business processes to be run and managed by the Process Engine. These elements of a workflow are abstractions of reusable business processes that were embedded into Java code in-house by IT staff or purchased as out-of-the-box EJB components written by BEA or independent developers.
Not only that, larger workflows can be composed of simpler workflows. By abstracting the business logic of the workflow from its embedding software, end-to-end business processes by can be designed using a GUI to drag-and-drop the visualized elements into place, without hand-recoding software. What is exciting about this build-components-then-integrate-model is its reusability, combinability, and modifiability of a set of basic business elements that can be used to model highly complex business processes.
The Business Process Manager uses the Process Engine to execute and dynamically manage the automated workflow process, persisting to update the current state of asynchronous interactions whether the business transactions flow over minutes or days. Thus, human skills are leveraged from project to project; the reusable components can be selected and integrated to form new solutions; and both skills and solutions are extensible into the future because the BEA platform only uses standard technologies.
The June release of WLS 6.1 confirms management's repeated statements that they intend to remain a platform company, not to become a vertical application company. For BEA, this platform-only focus serves two business purposes: (a) sales, because it provides the infrastructure for how business becomes e-business, and (b) market expansion, because it provides a platform of services and features that enable independent software vendors to develop EJBs, specific components embedding business process into application software, that grow the market for their platform.
Because it conforms and commits to open standards, this platform is open. However, simply because you use an open standard, this does not mean that any competitor can steal your intellectual property or that a rival necessarily has the insight, skill, or know-how required to duplicate or exceed its competitive advantages.
Because it is copyrighted, this platform is proprietary. By acquiring, developing and integrating the four best Java-based server-components into a comprehensive, innovative, powerful, and integrated platform, BEA created valuable and proprietary intellectual property. However, this proprietary competitive advantage is a strategic-block that is less strong than, say, judicially upheld patents. The blocking strategy must be sustained by continued innovation, a run-strategy that fully uses BEA's vision, know-how, and ability to execute, or by reaching critical mass in network effects. Nonetheless, it is important to recognize and remember that BEA's platform is not your everyday Web application server; BEA's platform is the award-winning market-share leader because it represents the leading edge in innovative features and sophisticated integration.
(Readers with short attention spans, rejoin us here (gg).)
Thomas, for me, you are not distinguishing between "openness" as a Java standard and The BEA WebLogic Platform for E-Business as a proprietary product. I believe "standards" and "products" are conceptually distinct. BEA uses the Java standard in making its proprietary product. This makes it open without making it non-proprietary.
Although I may well be wrong, I believe that its strategy and implementation are better than its competitors. I confess that I am taking that too much on faith in Coleman and BEA because I have not yet done enough due diligence to convince myself, much less you or anyone else, that my opinion is more that a partially informed opinion. However, I am more confident in the logic of my argument. It is possible to have J2EE architecture that is also proprietary. No definition in the gorilla game rules this out.
BEA began by purchasing what it considered to be the best J2EE components and integrated them. Coleman was the head of Sun Integration and before that he was in charge of Sun's operating systems division. The software guru Chuang was his technical officer at Sun. As a proxy for my lack of software expertise, I accept this background information and the fact that the Java professional world has awarded BEA 14 first-place awards in the last 18 months. That is, I assume that if the majority of the Fortune 500 and Global Fortune 500 companies did their due diligence and selected WebLogic that BEA knows what they are doing even if I do not have the competence to vet the technology personally..
BEA controls its value chain because its software code is proprietary and because it continues to integrate more and more servers with specialized functions into its platform. Moore would describe this process as commoditizing the whole product. This keeps all of BEA's competitors in the position of playing catch up. Also, it relieve its value chain of developers of some burdens in development by doing this heavy lifting for them. I believe that WebLogic 6.1 is the state of the art. I am particularly taken with its BPM and "divide and conquer" abstraction that may well be old hat to someone as sophisticated as you. I am prone to excited enthusiasm. Sometimes that has led me astray. Yet, all I can do is my best and remain open to learning from my errors.
If I am mistake, it will take someone of your abilities to show me the error of my ways. I know that you favor Sun's iPlanet, but you have not said why in enough detail for me to understand your perspective. Does your non-disclosure agreement prohibit that? You may well be right; I don't claim any expertise here. I just read, write it, and rush in where angels fear to tread. If so, share your knowledge with the board.
I hope that is responsive to your concerns Mike. I particularly hope that I added enough detail (g). Do you want to ask me about switching costs? I have that lecture written out and waiting.
I hope that this helps the board, because if it does not, then I just do not have the "right stuff." I would like to believe that we can all contribute in our own way, even if my way is that of the pedantic retired professor playing around outside the scope of his expertise.
Don |
