MARCH-APRIL 1998 (Vol. 2, No. 2) pp. 32-35
1089-7801/98/$31.00 © 1998 IEEE
Published by the IEEE Computer Society
Published by the IEEE Computer Society
Guest Editor's Introduction: Internet Architecture—Its Evolution from an Industry Perspective
|A Day in the Life of an Intranet Architect|
|Applying the Architecture|
|How to Design Without a Chief Designer|
PDFs Require Adobe Acrobat
The Internet is the largest engineering undertaking ever, and it is evolving without a grand design blueprint. Its architecture is the result of a large number of competing and collaborating companies and individuals. This special issue contains snapshots of the architecture from five companies: IBM , Microsoft , Netscape , Oracle , and Sun Microsystems . These five companies represent technology that we use now as well as technology that is "coming soon to a desktop or a server near you." In other words, technology supported by industrial-strength products.
Over the past year I have been describing an architecture of the Internet in my column, Architecture Perspective (see sidebar). I introduced an architecture with five parts and four dynamics in the first issue of the magazine (see Figure 1 ). In the next five issues, I delineated architectural details for the five parts shown in Figure 2 . For this special issue, I invited five major developers of Internet technology—all Boeing partners—to contribute an architecture-related "industry report" describing the landscape of the Internet from the vantage point of these five parts: a user interface perspective by Netscape, an applications perspective by Microsoft, a middleware perspective by IBM, data by Oracle, and delivery system by Sun Microsystems. The results of these contributions, representing the state of the art by major technology suppliers, are in your hands.
A Day in the Life of an Intranet Architect
This introduction itself is a sort of industry report, but from the technology user: I will highlight the technology in the five reports, but I also discuss the constant struggle an enterprise faces in trying to fit overlapping and competing technology designs into a coherent intranet.
Intranet architects and developers must meet the challenges of heterogeneous computing environments, the realities of an installed base, re-engineering of business processes, migration from legacy systems, and so on. Technology suppliers present conflicting claims about the products and their own architecture frameworks. Moreover, as the reports in this issue show, there is no standard terminology: Tier 1 may be the tier of mainframes for some and desktops for others.
Integration of the architectures and products is a giant jigsaw puzzle whose pieces, coming from different suppliers, have idiosyncratic shapes. Some are rounded, others have sharp corners, and yet others come with holes in them. (A specific example from this issue shows up in the different approaches Microsoft and Oracle take to data interfaces.) What you will do with the pieces depends, of course, on the specific situation. However, filing them to fit and filling the gaps between them is very labor intensive. A supplier-neutral and complete architecture (such as the architecture in Figure 1 ) is an indispensable tool for this integration, allowing you to compare apples to apples and ensure a global integration and coverage.
An architecture is a powerful device. The success of Microsoft is due in large measure to its "architecture franchise" (borrowing the apt term used by Eric Schmidt in his interview with this magazine). The success of an enterprise intranet depends on a comprehensive architectural framework. This framework needs to include strategies for handling the mind-boggling complexity (for example, when to choose a strategy of "best of breed with adequate integration" versus a strategy of "adequate breed and best integration."
These decisions depend on individual enterprises but the components of the Internet architecture in Figure 1 are pretty much independent of an enterprise.
Applying the Architecture
In general, an intranet architecture and its supporting products can be mapped to the overall architecture of Figure 1 . Each of the five parts was decomposed into components, as described in my Architecture Perspective columns (see the sidebar for a reference). The decomposition is shown schematically in Figure 2 . While there is still more detail that could be added to this schema, an intranet is pretty much determined by standard and product decisions on the 21 components delineated in Figure 2 .
You can test this idea by mapping the architectures and products of your suppliers. For each supplier, you can define an instance of the Internet architecture that will show which components are present, which are missing, which are incompatible duplicates, and where you will have to fill in the gaps.
Figure 2 specifically represents the result of applying this exercise to the industry reports in this issue. The black component shapes indicate the components discussed in the reports. It shows at a glance what is covered and what is left out. Only the Middleware part has complete coverage; and if the figure included shades of gray to indicate overlaps represented in the reports, the coverage would be even more apparent.
This is not surprising. The key message of my first column was that major Internet suppliers are following the chess strategy of controlling the center.
Two dynamics (the processes interacting with the parts of the Internet architecture in Figure 1 ) are part of this issue as well. The Netscape report discusses usability (part of the User Processes dynamics), and the JavaBeans programming model is an important element of the IBM and Oracle reports.
Now, for some highlights from the five reports as they relate to the five parts of the Internet architecture shown in Figure 1 .
User interface and the Netscape report
My first column discussed the concept of process-driven user interfaces, interfaces based on the "pull," not the "push," of information to users. The Netscape report (this issue) focuses on access to services rather than just information. In a service offering, the burden of finding data and information appliances is up to the service provider (which could be a software agent), not the user; it is another way of defining process-driven user interfaces. I find the concept of pushing services more palatable than pushing information: It is easier to decide if I can use a service than to figure out what I can do with information.
Applications and the Microsoft report
The Microsoft report (this issue) is on Windows DNA, an architecture for building Internet and client-server applications. The components of the architecture cover primarily the Application and Data Services components of middleware. Ease of integration is the design objective—Microsoft's strategy is "auto-everything." For those who fully subscribe to it, it provides an ever broader set of pieces that easily slide in. This is the Microsoft architecture franchise, the basis of its business model. It really works in a Microsoft homogeneous environment.
Middleware and the IBM report
There has been quite a bit of progress in the convergence of the "three ways of plumbing the Internet" that I discussed in the column on middleware. Probably the most significant was the announcement of the Iona agreement with Microsoft to develop a bridge between COM and CORBA.
This bridge will allow some interoperability between the COM model and the CORBA-based Component Broker, the subject of IBM's report (this issue). The Component Broker is rooted in distributed object computing and extended by IBM's insights into the realities of enterprise computing, which include objects that have life cycles that must be supported for years, sometimes decades. The concept of managed objects adds complexity to the CORBA model, but the real world is not always elegant.
Data and the Oracle report
The importance of the "page space" as an interface to structured data continues to grow. The Oracle report (this issue) emphasizes access to structured data. The point of departure is a CORBA-based distributed Java object programming model. The two basic interfaces that Oracle and its partners developed are both targeted to Java. JDBC defines representations of SQL interfaces for Java programs, and SQLJ specifies a syntax for writing SQL statements directly in Java. The report describes when to use which approach.
The report also discusses the Java Virtual Machine, which is used to support stored procedures for databases using either JDBC or SQLJ to access data. This is a wonderful concept because, as the authors point out, Java stored procedures can be safely executed in the same address space of the database server, yet Java is a general programming language unlike specialized languages for stored procedures.
Delivery systems and the Sun report
The report from Sun (this issue) concentrates on the architecture of the company's internal delivery system. It shows where the company that invented Java is in migrating to a Java-based enterprise information system. A key refinement in this migration has been a shift from a three-tier to a multi-tier architecture.
How to Design Without a Chief Designer
These, then, are some details of the Internet architecture components in Figure 2 . An intranet, however, is just one element in the broader context of an enterprise architecture, which is the context in which the intranet evolves. An intranet is the CPU and the system software for the Business Operating System (BOS) that manages, like an OS, the interaction of other resources in an enterprise context (people, process models, facilities, and so on). The BOS depends on the intranet to deliver information-processing services to end users—the source of competitive advantage. For example, a more efficient search service for electronic connectors will favor one supplier of connectors over another; designers will gravitate to where they can find connectors most easily.
End-user information services can be used to envision business processes that are several steps ahead of current technological capabilities. Technology developers will follow to help us realize these visions. Moving the design to the end user—the creator of all value—is what will allow us to guide the Internet evolution in the absence of a chief designer.
And when we start designing processes and end-user services on the Internet itself, we will have the genesis of a self-organizing system with the end user in the driver seat. This is important because, paraphrasing a well-known quotation, the Internet is much too serious to leave to the technology developers.
I would like to thank all contributors to this issue who juggled their priorities to give their evenings and weekends to these reports. I would also like to thank the Boeing executives and executives of the participating companies for their strong support.
Miroslav Benda is an enterprise architect in the Boeing Commercial Aircraft group responsible for the direction of information systems architecture, including interfaces internally with business process architecture and externally with customers and suppliers using the "public infrastructure," the Internet. Prior to joining Boeing, Benda spent a decade in academia as a mathematics faculty member at the University of California, Berkeley, and the University of Washington, Seattle. He received a PhD in mathematics from the University of Wisconsin.