Be a Leader: Embrace DCE Today By John Dohm, Senior Consultant and Scott Kandel, Senior Manager Deloitte & Touche LLP

Lloyd Bitzer, a noted psychologist, long ago established the concept of an "exigence." At the core of the concept is finding the driver(s) behind a set of actions. Although Bitzer knew nothing of DCE, he clearly understood that behavior is often based upon criteria not apparent to the audience. In the case of the Open Software Foundation's (OSF) Distributed Computing Environment (DCE), business decision-makers must take a good look to see why businesses need DCE, why vendors and suppliers are doing whatever it is they are doing, and how their respective "exigencies" adversely affect customer success in working with distributed systems. Before looking at the DCE marketplace, however, let's establish the case for DCE.

The Facts Of Life

Organizations have spent billions purchasing and maintaining computer systems and software since the dawn of client/server computing. Yet, with all that spending, few organizations can concretely identify benefits, other than gains achieved in personal productivity and, to some extent, ease of use. Moreover, business software development, the kind intended to help a company develop a new service or control costs, seems to be somewhat less effective than desired. Consider the following statistics recently published in Computer Economics:

• 1 percent of software projects are on time, within budget, and meet specifications
• 20 percent of software projects over 60,000 lines of code are never completed
• 15 percent of software projects never deliver anything
• Only 5 percent of all money spent results in systems that are actually installed and used as delivered
• 19 percent of all money is spent on software that is either extensively reworked or abandoned after delivery
• 29 percent of all money is spent on developing software that is never delivered
• 47 percent of all money spent on software development goes toward software that is never used

What do all these numbers mean? We're not sure, but we'll hazard a few guesses. First guess: Many organizations have a hard time identifying requirements and translating them into business systems. All right, nothing new here. Second guess: Firms' requirements often change during the development process, leading to systems that simply don't meet business needs. Again, nothing new. Third guess: Software development is just plain difficult and few people really understand enough to develop good solutions for business.

Hmmmm... Okay, now we have our three guesses, each of which could generate hours of exciting conversation. Shortcutting the discussion, however, is an underlying enthemyme (another Bitzer term meaning something similar to a "hidden message") that businesses don't always know where things are going, and systems developers have a difficult time anticipating business change. Gadzooks! That's it. Hey there, you might interrupt. If these observations are correct, you'd argue, then the battle is utterly hopeless. Ordinarily, we might readily agree. Then again, we'd prefer to be more constructive and suggest that building a computing infrastructure is a pivotal step to resolving the systems development problem. We see DCE as a critical component of this infrastructure because DCE provides necessary core services for distributed applications. Security, naming, timing services, robust communication and global file sharing are all part of the fundamental software building blocks. Better yet, these services are designed to be scalable and to be implemented across multiple computing platforms.

A Stagnant Status Quo

Since we've already hazarded a few guesses as to why business systems development seem to teeter with problems, let's consider what would happen if organizations continue to implement point solutions, either purchased or internally developed, without solid infrastructure software such as DCE.

Scenario No.1: All vendors will suddenly begin to cooperate and things will work together flawlessly. We can rule this one out, of course, because, as our friend Bitzer would see it, vendors would be driven by their desire to lock customers into proprietary solutions, and integration does not move a vendor closer to that end.

Scenario No. 2: Vendors will continue to support their self-interests, and, as long as customers continue to buy proprietary solutions, this problem will grow worse. This one seems perfectly plausible, if not downright likely.

Scenario No. 3: Customers, weary and frustrated in dealing with the management and maintenance of multiple systems and infrastructures, dictate that vendors support a common architecture for core services, such as security, access control, and directory services. If you believe that this scenario makes the most sense, we agree. What's more, by promoting the benefits of selecting a strategy that includes important infrastructural components like DCE, you would likely win the hearts and minds of developers, managers, and operations personnel in your organization. The first two scenarios paint a different picture, however.

Consider this: A firm chooses not to implement a solid infrastructure. Take the example of security services, specifically sign-on (identification and authentication) and access control (authorization). The need to log in and be provided access to relevant functions within an application exists with or without DCE. Having no framework for such services, business application providers take the logical course of designing and developing such mechanisms. Assuming that each application contains its own set of user IDs, passwords, and access privileges, an organization would have ( N * (the number of applications) ) security environments to manage and support. Moreover, the firm would need to develop management tools for these environments because no vendor could write the management interfaces necessary to support myriad security implementations of different software products. Worse, the variety of tools and strategies used to develop the business and vendor software limits the ability to integrate the security mechanisms under one management umbrella. This is not a pretty picture, and we are only talking about security.

Greater Understanding

The good news is that many of our clients are beginning to understand and identify the issues involved in developing, managing, and deploying distributed systems. Our customers are generally familiar with the issues involved, and when the specific benefits of DCE are identified, our clients tend to see that DCE is a positive step forward. The bad news is that software vendors face a long journey toward integrating DCE services into their products. And some vendors are trying to develop competing infrastructure (or "middleware") products instead of adding services on top of DCE. Two competing technologies are Object Request Brokers (ORBs) and Messaging.

The Object Management Group (OMG) recently released version 2.0 of the Common Object Request Broker Architecture (CORBA) specification. Although the specification describes in detail the programming interfaces between objects and ORBs, the actual mechanics surrounding the security, naming and communications between objects and ORBs are not completely addressed. CORBA mandates a TCP/IP-based communication protocol, with the option of using DCE/RPC as an additional communications transport. The CORBA specification is conspicuously vague on the security requirements for distributed object-based systems. For example, CORBA does not define how one object conveys the identity of the requester (who wants a service) and access privileges (services that are allowed) to another object. This is just a sample issue that has already been resolved by DCE.

At the heart of the Messaging vs. Remote Procedure Call (RPC) debate is the misconception that DCE provides only a synchronous (call, wait, return) communication model as opposed to messaging, which offers an asynchronous (send, continue) model. What is overlooked is that building a messaging environment with DCE RPCs is quite simple. RPC applications exhibiting messaging behavior are not only possible, but are also available in production products including the Recoverable Queuing Service (RQS) in Transarc's Encina and Open Environment's Entera product.

Of course, if you're a vendor with a proprietary product, promoting the differences outlined can be highly advantageous. Several vendors, however, convey an inconsistent story because they are developing proprietary software to compete with DCE services while they suggest that ORB technology will allow significant code reuse. One might ask why the vendors are not reusing DCE code. Bitzer would have a field day, if not a full couch, with what these folks are really doing behind the scenes.

Common Sense

Readers of this magazine assuredly understand that software development is difficult, demanding work, and good systems must be designed to adapt to business and organizational change. To make software with the flexibility required, logic dictates that common services be available across heterogeneous platforms. DCE clearly provides a springboard to this higher level of thinking. What may not be so clear is how firms will respond to the rate of change anticipated over the next decade.

The use of computers is obviously expanding to the consumer marketplace, leading to more innovative use of technology by business, even traditionally conservative businesses. Of late, Tom Peters has urged organizations to encourage chaos, ostensibly turning everything upside down and seeing what sticks. Imagine the impact this approach would have on information systems in your enterprise. Our advice? Prepare now and be the hero in your firm. Clearly, the "exigence" of the authors in this supplement is apparent. Each of us would like to see DCE take hold and flourish. We trust the articles presented here make the compelling case for DCE since its success is absolutely critical to the development of open systems.

John Dohm and Scott Kandel were featured at the OSF DCE Users & Developers Conference.