• Other methods
  

In the complex and sometimes confusing world of groupware, the simplicity of electronic Calendaring and Scheduling is appealing: it automates specific processes with which everyone is familiar and it does not require arcane vocabulary to describe its workings or benefits. So, from a pragmatic viewpoint, scheduling is a straightforward groupware investment with a fairly predictable return—and it's available, right out of the box.

Although e-mail and Calendaring and Scheduling are very complementary products, attempts to simplify the groupware market by lumping Calendaring and Scheduling products in with e-mail systems as "communication" tools, is not a useful exercise. Calendaring and Scheduling provides a unique perspective to the desktop the e-mail does not— a sense of time. This time domain aspect affects the entire technical design from the user interface down to the underlying architecture. The newer standalone (those independent of integrated suites) applications, have optimized their server engines to manage those unique issues associated with synchronous, real-time coordination as well as to support other time-relevant, but asynchronous, collaboration processes. Calendaring and Scheduling products built on top of more generalized platforms such as e-mail or other file-based designs typically don't completely address these basic time management paradigms. Further, these architectures are not readily adapted to the Web's client/server paradigm.

AN OVERVIEW OF CALENDARING AND SCHEDULING PRODUCT CLASSES

The terms "Calendaring" and "Scheduling" are not synonymous. Calendaring involves the placement and manipulation of data on a calendar, while Scheduling involves the communication and negotiation between calendars for such data placement. The Calendaring and Scheduling products available today can be classified by their architecture and platform support, which in large part is determined by their emphasis upon Calendaring vs. Scheduling (see Figure 1).

The products that serve the Workgroup Calendaring and Scheduling market include network-aware Personal Information Managers, "PIMs." The calendaring-oriented feature set in products of this category is much richer in depth and variety than those of departmental and enterprise solutions. The majority of these features, however, are not solely concerned with time management per se. Instead, they offer a variety of personal productivity tools from databases to contact management. Their feature sets are focused on personal rather than group productivity and this generally comes at the expense of networking or other information sharing performance.

This focus on personal productivity is an acceptable trade-off for environments where people work independently, need to manage unique sets of data and only occasionally wish to share information. Another advantage of products in this category is that they require significantly less administration resources than larger-scale scheduling products. However, although some workgroup products are being deployed at sites with more than 100 users, latency and scalability have not been adequately addressed in this class of scheduling product. So, if you are in a quickly growing group or plan to deploy the product across a larger organization, these products may not be a suitable long-term solution.

Characteristics of Workgroup Calendaring and Scheduling Products:

• Excellent personal productivity features
• Simple Administration
• Limited scalability
• Latency issues

The products that serve the Departmental Calendaring and Scheduling market include those using e-mail or store-and-forward architecture. This category includes many of the popular scheduling tools that helped develop the Calendaring and Scheduling market as we know it. These products were initially designed to serve LAN-based workgroups. Many of these products have since been retrofitted to address larger user populations. These products typically have a solid feature set oriented towards group productivity, good-to-excellent user interfaces, and reasonable network throughput for up to 500 users and above (depending upon the product and configuration).

While they have been enjoying the marketshare advantages of established players, they are now in the unenviable "middle market" position. New scheduling users in the smaller LAN workgroups are finding the Web-enabled PIM products very appealing, but existing users in larger workgroups are often frustrated in their attempts to deploy these tools at the enterprise level. Some vendors are now in the process of re-architecting their products to a client/server design to address this situation and to stave off competition from higher-end products.

Characteristics of Departmental Calendaring and Scheduling Products:

• Some scalability (varies by vendor)
• LAN Administration resources required for large sites
• Latency issues

The principal design effort in Enterprise-wide Calendaring and Scheduling products is focused on the architecture required to support scalable, real-time information sharing for thousands of users across local and wide area networks. Although the goal of real-time information sharing may not be a requirement for other types of groupware applications, it is essential for effective group and enterprise coordination. This is especially true for the larger scale implementations.

The feature set in this class of Calendaring and Scheduling products tends to be more focused on time services and is very group-oriented at the expense of the variety of personal productivity features that can be found in a PIM. Older products in this class employ a host-based design (e.g., mainframe), while newer applications are client/server based. Newer enterprise scheduling architectures support transparent scaling across the enterprise which is a significant benefit for large or quickly growing organizations. The disadvantage of this class of scheduling application is that it requires system administration resources for all sites. For large sites, the administration resources required per user are quite low, but with a small number of users, it is just not as cost-effective.

Characteristics of Enterprise Calendaring and Scheduling Products:

• Excellent Scalability
• Real-time
• More limited personal productivity features
• System Administration resources typically required for all sites

For many organizations, the Calendaring and Scheduling component is a cornerstone of their groupware solution. As such, the selection of the product that best meets the unique business and cultural needs of the organization requires careful consideration.

In the late 80's PC-based Calendaring and Scheduling vendors developed their products for LAN environments. Many of these Calendaring and Scheduling products used e-mail as a transport mechanism, while others simply accessed calendar files directly over the network, usually within NetWare NOS (Novell's proprietary Networking Operating System) environments.

Despite the fact that tens of thousands of users at single sites were served by mainframe e-mail and scheduling applications, the general feeling in the PC world was that Calendaring and Scheduling was a peripheral application and usage would most likely be limited to workgroup, or at most, departmental levels. By the mid-90's the popularity and subsequent adoption of group scheduling products began to outstrip the scalability potential of the PC-based Calendaring and Scheduling products. This caused a significant technical shift by these PC-based vendors, towards the adoption of a client/server model. The vendors unable to make this transition have been squeezed between the overcrowded, low-margin PIM market and the enterprise client/server market.

According to many industry pundits, the Web isn't a successor to client/server computing-it is an example of client/server computing "done right." Since it took time for PC's to be effectively networked together, non-PC based (e.g., UNIX and VMS) Calendaring and Scheduling tools tended to have client/server scheduling capabilities before PC-based tools. For example, CrossWind Technologies introduced the first client/server based Calendaring and Scheduling product in 1992. This first implementation was on UNIX. By 1994/1995, when the ability to scale became paramount and NT became viable, most vendors of Calendaring and Scheduling tools announced or implemented plans for client/server based architectures.

In light of the explosive growth of the Internet, the move to client/server and support for TCP/IP was a critical move for those vendors. The ability to operate within a client/server, TCP/IP environment provides the foundation for Internet/Intranet capable products.

Web-based

Now many vendors are announcing limited read-only and read/write versions of their products that make Calendaring and Scheduling information accessible via the Internet using technologies such as CGI. These Web products are only stop-gap offerings from most vendors until more advanced development environments, such as Java and ActiveX, become available. Vendors are also waiting for a meaningful market to develop for applications using these technologies. But regardless of what advanced technology is driving your browser-based client, you need to look at how the back-end technology is going to make it all work for you.

The notion that Calendaring and Scheduling only works when "everyone is using it" or when everyone is using the same system, is apparently not true. In fact, there are very few Fortune 500 firms that have successfully implemented a comprehensive, homogeneous Calendaring and Scheduling system for every desktop in their organization, yet the Calendaring and Scheduling market has flourished for years.

One hundred percent organization-wide adoption is not necessary to reap benefits from a Calendaring and Scheduling system. With respect to scheduling alone, the addition of each user to a group Calendaring and Scheduling system potentially decreases the complexity of the manual coordination process correspondingly. However, to get the full benefit of scheduling and sharing of time-relevant information across the enterprise, user compliance and interoperability are certainly important. Total participation in any groupware roll-out is an ideal, but for the sake of those brave souls directly responsible for implementing it, we should acknowledge that the very strong user preferences (as evidenced by maverick departmental IS decisions, PIM diehards and pocket calendar loyalists) have and will continue to outmaneuver this ideal.

To make a corporate Calendaring and Scheduling system work well, it is important that scheduling information be somehow shared across the enterprise. The obvious solution would be to have a single, homogeneous solution--if this is a viable option for your organization, by all means do it. However, as noted above, this is not always a likely scenario, particularly with the plethora of legacy applications found in larger enterprises. By the time most large enterprises had made the decision to select and implement a corporate-wide scheduling solution, they already had a significant installed base of disparate calendaring and scheduling solutions.

The selection process of a single, enterprise-wide scheduling solution is a very politically intense and protracted process (this process took six years by committee for one Fortune 500 high tech company, resulting in the selection of not one, but two Calendaring and Scheduling products as "standards"). One benefit of this lengthy process is that it gave the deliberating companies the opportunity to see which of their legacy applications could actually scale to meet their needs and which could not. The downside of this of course is that these burgeoning installed bases were getting more and more entrenched users.

So, for the enterprise-wide Calendaring and Scheduling system here some options:

1. The first choice is a single-vendor solution that meets the needs of your entire organization and that your organization will adopt a very tall order!
2. The second choice is a dominant-vendor solution that meets the majority of the IS and user requirements and with a small, manageable number of alternative solutions for the most vocal user groups. The idea here is that eventually, through attrition, the dominant solution will be the only solution.
3. The third choice is the laissez faire approach that allows users and departments to chose whatever solution best meets their needs.

This last option, has historically been the most popular approach in practice, but is falling out of favor (in principle at least) because of the increased complexity and cost associated with this model in terms of support and opportunity loss associated with the limited information sharing potential.

The number of users that can usefully share information and coordinate activities decreases with each option. Since the second and third options comprise the majority of the corporate market, the ability to share information between different Calendaring and Scheduling products has become a serious IS issue at most large organizations and has given rise to serious Calendaring and Scheduling standards efforts on the part of the vendor community.

Currently there is no de facto Calendaring and Scheduling standard that allows scheduling information to be usefully exchanged between third-party Calendaring and Scheduling products. However, a recent spate of activity by the Calendaring and Scheduling vendor community may change that. The combination of heightened industry demand and the past experience of failed standards attempts have inspired both a sense of urgency and openness that will help fuel the new standards effort, currently underway.

As mentioned earlier, the terms "Calendaring" and "Scheduling" are not synonymous. Calendaring involves the placement and manipulation of data on a calendar, while Scheduling involves the communication and negotiation between calendars for such data placement. This distinction takes on special meaning in the area of standards. The main focus of the current Calendaring and Scheduling standards effort will be upon the representation and transfer of calendar objects across the Net. The set of information to be exchanged will be, by necessity, limited to the basics. This means that the richness and variety of scheduling-related information exchanged within a multi-vendor Calendaring and Scheduling environment will likely be limited to what is covered in the standards specifications.

Calendaring and Scheduling vendors have made several unsuccessful attempts toward the goal of creating a standard that would enable different products to dynamically share information. The difficulty in such an undertaking lies in the heterogeneous architectures and feature sets of the different Calendaring and Scheduling products involved. Using the democratic process adopted by most consortia, vendors try to negotiate the inclusion of the technologies that form the substance of their product implementation. With many vendors involved in this process, the resultant specification may be too unwieldy for any of the individual participants to adopt--much less the non-participant vendors who didn't have the opportunity to share their unique views on product architecture.

The XAPIA Calendaring and Scheduling API (CSA), was the latest example of this approach. The XAPIA Association (X.400 Application Program Interface Association), formed in 1989, was created initially to provide assistance to developers of applications running on X.400 networks. The XAPIA charter had been expanded to include guidance in API development for mail systems as well as mail-enabled applications (which includes a subset of the Calendaring and Scheduling products on the market).

In late 1994, the proposed XAPIA CSA was made generally available to all scheduling vendors and was adopted by very few. In hindsight, this may have been the result of an overly ambitious technical scope, or perhaps Calendaring and Scheduling vendors just weren't ready to "bite the bullet." Some of the specifications from the XAPIA CSA, however, are being brought forward within the vCalendar proposal from the Versit Consortium for review within the current standards creation effort.

A group of Calendaring and Scheduling vendors along with other interested parties met in July 1996 with the intent of creating a new standards effort through a process very different from past standards efforts—the creation of an IETF (Internet Engineering Task Force) Working Group for Calendaring and Scheduling. The decision to develop a standards specification via the IETF Working Group process may prove to be instrumental in the resultant specification's market success.

There are many key differences between the standardization efforts via the IETF vs. the traditional consortium process, as noted below:
IETF Working Group process:

• narrow technical focus
• addresses only near-term goals
• meetings held electronically
• membership is informal

• general design approach
• addresses long-term goals
• meetings held face-to-face
• formal membership

For more information on the IETF standards process, read "Making Standards the IETF Way" by Dave Crocker at http://www.brandenburg.com. Besides providing information on a standards process, the IETF overview presents a very successful model of open, electronic collaboration.

The IETF Working Group's development time is usually much faster than standards development via consortium. One reason for this is that the process doesn't wait for face-to-face meetings—collaboration continues literally around the clock and around the globe. To reduce barriers to participation and to maintain a level playing field, decisions can only be made electronically via the Working Group's E-mail list. This is how the typical IETF process manages to move from formation of a Working Group to submission of the specification as a Proposed Standard within nine to eighteen months. The success rates for industry adoption of standards created via the IETF process are quite good.

The goal of the initial face-to-face Calendaring and Scheduling meeting in July 1996 was to achieve consensus that an IETF Calendaring and Scheduling Working Group be formed. That done, the next step is that a charter be written and approved. The charter, essentially a statement of work, describes the focus and scope of the Working Group. The scope of this particular effort will be narrowed to perhaps two to three of the most elemental specifications concerning the representation and transfer of calendar objects across the Net. This IETF effort will not attempt to model the attributes of the actual calendar on the other end of such a transfer—a pitfall of past standards efforts.

Assuming all goes according to plan, the specifications should reach "Proposed Standard" status after the Fall IETF Meeting in October 1997.

Vendors participating in the July 1996 IETF meeting included:

• Amplitude Software Corp.
• Automatrix, Inc.
• Banyan Systems, Inc.
• Clear Blue Network Systems, Inc.
• CrossWind Technologies, Inc.
• Corporate Software & Technology
• Goldmine Software
• Hewlett-Packard
• IBM Corporation
• IET Intelligent Electronics
• Lotus Development Corp.
• Microsoft Corp.
• Microsystems Software, Inc.
• NetManage, Inc.
• Netmosphere, Inc
• Netscape Communications Corp.
• Nokia
• Novell
• Now Software
• ON Technology Corp.
• OnTime Software, a division of FTP Software, Inc.
• Phase2 Software Corp.
• Puma Technology
• Sarrus Software
• Software.Com, Inc.
• Starfish Software, Inc.
• TeamWare
• Versit Project Office

Of these participants, several presented individually developed technical drafts:

• Internet Calendar Access Protocol (ICAP) presented by Clear Blue Network Systems and Lotus
• MIME-based Application/Properties profile presented by Microsoft Corporation
• Calendaring and Scheduling Interoperability Protocol (CSIP) presented by OnTime/FTP Software
• Simple Scheduling Transport Protocol (SSTP) presented by On Technology,
• Scheduling Wide-area Transport Protocol (SWTP) presented by Phase2 Software
• vCalendar presented by the Versit Consortium

The multiple technical drafts were representative of the diverse architectures and technical philosophies within the Calendaring and Scheduling products currently on the market. The Versit Consortium, a consortium working to propose personal data interchange standards for interoperable Electronic Business Cards (vCard) and personal calendaring objects (vCalendar), contributed its vCalendar specification as a proposal. The vCalendar specification includes X/Open-based calendar semantics from the XAPIA effort.

While no scheduling specific standards currently exist, a number of other more generalized standards will assist in the information sharing and communications direction of Calendaring and Scheduling products. Most scheduling vendors support TCP/IP (Transport Control Protocol/Internet Protocol) as their communications protocol, which provides a level of commonality between scheduling vendors that didn't exist two years ago. Other important standards are HTML (HyperText Markup Language) and HTTP (HyperText Transfer Protocol) which establish standard formats for data presentation and transfer.

The emergence of the World Wide Web, HTTP and HTML have created an environment where information sharing is happening (and happening very quickly) on a scale never before possible. This revolution was originally limited to static HTML pages. It is now quickly gaining the capability to generate information specific to the needs of the requester. Calendaring information (especially group calendaring information) tends not to be static and certainly is specific to the requester of that information. As a result, calendaring systems need to utilize the more dynamic capabilities that the Web offers in order to be useful within such an environment. That is, the information typically needs to be extracted from a calendaring database, and then mapped "on the fly" into a format that can be delivered to the user. It is also important to keep in mind that some kind of database mechanism needs to lie behind any Web-based approach to Calendaring and Scheduling. No matter how easily implemented and accessible Web solutions may be, such solutions applied to Calendaring and Scheduling need to provide real-time information in order to adequately serve this part of a useful Web solution.

Information needs to be extracted from a calendar database of some sort, which necessitates that a well-designed engine be behind such efforts. There are also performance issues involved with the front-end data delivery. The three main methods for delivering such information to the user are currently the following:

1. CGI (Common Gateway Interface)
2. Java
3. ActiveX

CGI typically offers the easiest mechanism for enabling access to scheduling information over the Web. Through the CGI mechanism, Web servers can be instructed to execute external programs (CGI scripts) that can do the type of formatting necessary to display calendar information to the user. From a development viewpoint, it is fairly simple to generate a monthly calendar using the TABLE construct of HTML. Given an HTML reference that stipulates the month and year, the CGI script can be instructed to generate an HTML page that constructs a calendar for that month and year. This HTML page is then transferred by the Web server back to the user’s browser.

There are a number of advantages of the CGI approach to calendaring on the Web. The first, and most important point about the CGI approach is that CGI is available and it works. Other technologies, as of this writing, are being feverishly developed, and as such, are currently not "ready for prime time." Another advantage of CGI is the relative ease with which a developer can generate HTML code, either within the CGI script, or within an agent with which the CGI script communicates. As a result, one can create a CGI-based calendaring solution fairly quickly. Finally, if the developer is judicious about the HTML constructs utilized, one can use just about any browser to access calendaring information provided through CGI scripting.

Given these advantages a CGI-based approach to calendaring may be a good decision, for the near-term at least, if time is of the essence in implementing a Web-based calendaring solution. However, there are a number of disadvantages with using CGI. The most important of these is the relatively static nature of CGI and HTML. While it is easy to generate HTML code to display a calendar, for example, any minor change to that calendar necessitates that an entirely new HTML page be downloaded to the browser and re-drawn (see Figure 3). In addition, the number of GUI objects supported by HTML is very limited, and not nearly as visually appealing as those supported by Java or ActiveX. These constraints tend to enforce the development of Web-based applications that are not as visually appealing or as fully-functioned as their more traditional client counterparts. As a result, vendors are moving, over time, to other approaches which will require a much more significant R&D investment, but which promise much better results than CGI.

Currently, the most popular of these technologies are Java from JavaSoft, a division of Sun Microsystems, and ActiveX from Microsoft.

Java

Java is a programming language that was originally developed by Sun Microsystems to control set-top boxes on televisions. As such, it was designed to be portable and work in embedded environments. With the advent of the Web, Sun repositioned (and redesigned) Java so that it could be used to "bring life" to the rather static world of HTML. Because it is a programming language, Java allows the developer to control everything that is drawn within the browser frame allocated to the application. As a result, the output can be visually appealing, changes to the output can be limited to only those portions that need to be re-drawn (with the accompanying improvements in performance), and network bandwidth can be used for data only, as opposed to data and code, as in the case of CGI scripts.

Perhaps the greatest advantage of Java is the platform independence it would bring to Calendaring and Scheduling. Java compiles to "byte-codes," machine independent instructions that are interpreted by a Java Virtual Machine that resides within a browser. Since it is highly desirable that all user populations participate equally in corporate time management and coordination, availability of these tools across the three major platforms (Windows, Macintosh and UNIX) has become extremely important at many large corporations. A Java-based Calendaring and Scheduling tool would bring the cross-platform benefits of such portability to users.

There are, of course, disadvantages to a Java approach. The current Java development environments are not as well developed as more traditional ones (e.g., the Microsoft Foundation Classes, MFC). In addition, the interpretive nature of Java makes for slower performance, although this problem is being addressed with the emergence of just-in-time compilation techniques. As a result, the emergence of full-featured Java applications has been slower than expected. Over time, this will change, but there are other choices available.

ActiveX

Microsoft has modified their networked OLE technology to provide Web-enabling capability for Windows-based applications. The result, called ActiveX, is a component framework that allows developers to use their Windows expertise and current Windows applications to create applications that can utilize the Web. The advantages of this approach are appealing: the vast body of Windows capability and technology can be leveraged to be used with a Web framework. Speed is not an issue, since the code is not interpreted. However, the tradeoff is that portability is not possible with the current technology, since the ActiveX components are compiled for a particular machine architecture (almost always the x86 architecture). As a result, the important minority segments of the market (Macintosh and UNIX), are not served by an ActiveX solution. While progress is being made by vendors to deal with these portability issues, the simple solution that Java brings to the portability problem is not readily available with ActiveX at this time. If a choice is to be made between Java and ActiveX, then Java is the better choice when portability is paramount, while ActiveX should be chosen if one wants to utilize current Windows technologies.

Other candidates besides CGI, Java and ActiveX are being used for Web development by innovative developers who cannot wait for Java and ActiveX. For example, TCL (Tool Command Language) is an integral part of a development environment being provided by a Web development tool vendor. Since it is a scripting language, TCL provides for rapid development and is an ideal candidate for work in the fast-paced Web world. This product uses the Netscape plug-in API with TCL to render dynamic views in a browser window that would not be possible with CGI, and which may be easier than Java or ActiveX.

Netscape plug-in techniques, in general, have been used very successfully by developers such as Macromedia, publishers of Shockwave. However, these plug-ins are transient in that, when the URL reference goes away, the plug-in goes away also; this is all due to HTML’s statelessness. Re-loading calendar clients and restoring the user’s state each time one wants to check one’s schedule may be too slow to make plug-ins viable (as they are currently implemented).

Given the ever evolving state of development technologies for the Web, there is no clear cut answer to the question of what technology to use for Calendaring and Scheduling integration with the Web. In general, if an immediate solution is required, CGI is the best approach. If portability is necessary and the solution can wait, Java wins the race. If leveraging a Windows code base and Windows expertise is important, then ActiveX should be the choice. In general, however, things are changing so rapidly that one needs to pay close attention to on-going developments. The correct decision for today may not be the correct decision for tomorrow, and both developers and users need to keep that in mind.

Scalability/Performance

It is quite a challenge to find a corporate Calendaring and Scheduling solution that meets current needs and that has the potential to address future needs as an organization grows and changes. As user demand for Calendaring and Scheduling capabilities has increased, many system administrators are discovering that their legacy solutions will not scale to address their current needs. For companies with an entrenched user population, the task of switching to a more capable Calendaring and Scheduling tool can represent a significant cultural challenge. Because of the difficulties in switching a user population and the long time frame between initial investment and the return on that investment, the pressure to select the "right" solution, the first time, is very real. To ensure that the investment will be in a long-term solution, the underlying architecture of candidate products must be considered—it is essential that the solution is truly cross-platform and has the ability to transparently scale across the enterprise.

What is a "framework?" Current framework products ostensibly provide a generalizable infrastructure for data sharing and management. Another way to look at framework offerings is as integrated product suites that have the ability to extend the platform to include other products. The upside of this approach is that the data sharing and data management within the core product suite is usually excellent. The downside is that the framework platform was optimized for its core products, and as users extend it to support other types of applications, like real-time scheduling, performance and flexibility may become issues. Although one-stop-shopping is appealing from an implementation viewpoint, the resultant solution may not provide the competitive edge expected from the IS investment. The three major "framework" platforms in the groupware arena are Lotus Notes, Microsoft Exchange and Novell’s GroupWise. All have Calendaring and Scheduling capabilities of differing performance and technical emphasis.

One of the attractions of implementing a corporate Intranet is the option not to be tied to any one proprietary "framework" platform, and the ability, or at least the promise, to select the best-of-breed applications to meet specific business and cultural requirements. This approach is not necessarily instead of framework products; many companies are finding that implementing a corporate Intranet allows them to tune their framework solutions to meet specific corporate needs.

In a recent example of this hybrid approach, a company divided the functionality of their Calendaring and Scheduling requirements between an Intranet-based scheduling product and their current messaging-based framework product, based upon the relative strengths of each. The end result was that the framework product (which has a Calendaring and Scheduling component) was selected to communicate the company events calendar and business forms, and the Intranet-based scheduling product was selected as the medium for group Calendaring and Scheduling for the user base. (see Figure 4).

One of the performance issues in a situation like this is the ability to schedule in real-time. Although messaging implementations are providing "near" real-time performance, this is not sufficient for scheduling time and resources with large groups of users. Near real-time scheduling is about as useful as near real-time telephone service in a fast-paced corporate environment.

There are two contexts within which users will be seeing traditional Calendaring and Scheduling appearing on the corporate Intranet. The first of these will be fairly straightforward "ports" of those applications to the Web, while the second will be characterized by a higher level of integration of Calendaring and Scheduling tools with other, relevant Web-based applications.

Standalone Calendaring and Scheduling applications running within Web are beginning to appear, mostly based upon CGI, with Java or ActiveX implementations to follow. The basic server architecture will be the same, but will sport a new Web front-end, allowing access from any machine within an Intranet, or even access from the Internet, assuming that security issues are worked out. The speed with which these applications can be delivered will depend, on large part, on the strength of the "engines" behind them. If access to those engines is simple and well defined and the engines provide good performance, then providing standalone Web-based Calendaring and Scheduling solutions will be a straight-forward task for vendors.

A second, more interesting type of application of Calendaring and Scheduling technology to the Web will manifest itself in the integration of that technology to other Web-based applications. There are a large number of applications that have a very high degree of time awareness, including work-flow tools, project managers, contact managers, etc. As they move to the Web, integration of Calendaring and Scheduling capability will become a given over time.

The older framework technologies in use today (Notes, Exchange, GroupWise) were necessary in order to provide "backbones" over which applications written to those frameworks can communicate. However, integration of tools within those frameworks has proved to be a fair amount of work for customers and third-party vendors alike.

With the advent of the Web, a number of advantages over the more traditional approach present themselves. First, the point-and-click connectivity provided by browsers lends itself very well to easy and seamless integration of independent front-ends. Secondly, the standard methods of CGI and HTML lend themselves to a simple communication mechanism that can be utilized by those independent front-ends and independent back-ends to complete the integration of the whole, without much of the pain involved in such efforts when using older frameworks.

One of the reasons for the explosive growth of the Web has been its foundation upon open, and in some cases simple, standards like TCP/IP, HTML and HTTP. Such simplicity and openness helped allow a wide variety of distributed applications and applets to be developed quickly by the average developer (as opposed to the more complex and arcane world of CORBA and DCE). In addition, the Web provides, through its hypertext capability and through the CGI interface, the semblance of seamless integration of otherwise disparate applications—regardless of whether those applications are really integrated or not.

This appearance of seamless integration has raised user expectations for all applications, including Calendaring and Scheduling. If Calendaring and Scheduling is to be integrated well with a company’s Intranet, it will have to work with those standards mentioned above, with standard browsers, e.g., Navigator and Internet Explorer, and with standards-based Web servers. In addition, true integration will necessitate adoption of additional emerging standards, like the IETF interoperability specification and directory services like LDAP (Lightweight Directory Access Protocol).

After Calendaring and Scheduling tools become well integrated parts of corporate Intranets, the next step is the Internet. People will want to schedule outside the corporate firewall with individuals outside the company. Many meetings today are with individuals and groups outside a corporation, e.g., with customers, vendors, prospects, etc. In fact, as vendor/customer relationships become closer, the need to share tasks across companies also arises. An ideal situation will have Calendaring and Scheduling work as well across corporate boundaries as it does within, as does electronic mail. The World Wide Web is certainly poised to make such an ideal situation a reality.

However, while the path to Calendaring and Scheduling integration with Intranets is fairly clear, such is not the case for the Internet. There are security issues to be worked out, as well as the less well-defined concerns of what kind of information should be protected behind a corporate firewall and what should be made available. In addition, such a scenario will only be viable if some level of Calendaring and Scheduling interoperability is achieved.

The issue of protecting valuable corporate data once it travels outside a firewall is simply part of the more general security issues of secure transports (addressed by the Secure Sockets Layer) and bullet-proof user authentication schemes (the same issues being dealt with currently in the context of such areas as Internet commerce). These are relatively easy problems to deal with, since other people have either solved them or are in the process of solving them. The more difficult issues that each corporate entity must decide for itself, include:

• What calendaring data, if any, should be made available outside the firewall?
• Should schedules be made available to "trusted" outsiders?
• Should only free/busy information be made available?
• What are the rights of outsiders?
• Should outsiders be allowed to insert meetings onto insiders’ schedules, or should they be just capable of proposing meetings that an insider can choose to view or not?
• Should outsiders be capable of delegating tasks to insiders, or should these be advisory tasks that can be viewed or not?

From a cultural viewpoint, the answers to these questions are not simple. Some corporations will choose to put nothing outside the firewall, at the expense of continuing to live with the lack of inter-corporate scheduling capability. Others may try to get a competitive advantage by making hard choices and using the available Calendaring and Scheduling standards.

In general, calendaring data is considered to be very proprietary and is not lightly released outside a corporation. In addition, users guard their schedules fiercely, since it is their time upon which others are impinging when a meeting is scheduled or a task is delegated. Care needs to be taken that Calendaring and Scheduling does not fall into the e-mail trap, where countless meetings, tasks and reminders are deposited on people’s schedules daily, to the point where they need filters to ignore all but a select few or just ignore them entirely. Since inter-company scheduling will provide a significant competitive advantage and a means to make companies work more closely together, these issues will be addressed by Calendaring and Scheduling vendors together with their customers. The day may even come when you will be able to schedule a haircut or a dentist appointment with your computer, instead of juggling with your phone in one hand and your appointment book in another. All of this depends on standards being developed and accepted by the vendors and customers of Calendaring and Scheduling solutions. Once those standards and their subsequent implementations are in place, Calendaring and Scheduling will indeed be as ubiquitous as e-mail on the Internet.

As information and intellectual property become the new business currency, companies are turning to groupware technologies to remain competitive. The investment in technology and training should provide a means by which an enterprise can effectively convert the tidal wave of information into a competitive advantage.

Groupware may be the key to increasing productivity in spite of fewer available resources. Time management services are often at the top of the groupware implementation list because they help optimize the most expensive, non-renewable resource a company has—employees’ time.