Weıve been telling this story for years. Create a magical framework with common business services shareable across all enterprise applications. Such a framework will allow organizations to share objects within and among enterprises and allow application architects to create new systems with as much as 90 percent reusable code. Application backlogs no longer exist, and maintenance is centralized. This is still a good story to wowıem at conferences, but the time has come for us to declare victory, accept defeat, or try something else.
This is not to say that frameworks are ineffective. They have been providing value at the application level for years. Iıve certainly promoted the use of both home-built and third-party frameworks in my column. Clearly, the problems exist at the enterprise level.
A few promising enterprise framework development efforts to provide this solution are underway. One that has the most potential is IBMıs San Francisco project. Others are happening behind the corporate firewalls, but few have yet to take on the entire enterprise. Letıs find out why.
The concept of frameworks is certainly nothing new. Reuse has been with us since the advent of structured programming languages. In fact, we probably reused more code back in the days of shared Cobol function libraries than we do today (although the paradigm puts great limits on extensibility and customization). In the late ı80s we rediscovered object-oriented development, and C++ emerged as the most popular object-oriented language. Using object orientation, the concept of true frameworks emerged.
C++ frameworks were, at their core, a common set of object services allowing developers to share objects among applications. They arenıt applications unto themselves but rather a set of objects that can provide some sort of value for an application. For instance, you can create a set of inventory control objects that are reusable in both your sales order-entry application and your accounting application. These are known as business objects or frameworks. Whatıs more, there are third-party frameworks available on the open market to add additional value to your application, such as database access and interface development features. These are known as service objects or frameworks.
The object-oriented model offered more features than that of the structured world. It gave both application architects and developers the ability to extend or customize the features of each object using object-oriented mechanisms such as inheritance and encapsulation. Whatıs more, C++ was a common general-purpose and standard programming language found on most platforms. It seemed that we solved the problem of having to reinvent the wheel each and every time we created an application. Right?
Wrong. The fact is, while we had the technology, tools, and even a few examples of organizations leveraging the power of frameworks, the all-encompassing framework that spans the enterprise never really appeared.
Enterprise frameworks are failing for several reasons, the most damning of which are scale, tools, and the Web. Frameworks were implemented at the enterprise level, and most IT organizations found that taking on such an effort required too much time and money and involved too many people. A better approach is to begin to create such frameworks at the business unit level and move the framework up the hierarchy to serve, ultimately, the enterprise. This "baby steps" approach gives application architects and developers many small wins (thus promoting the viability of frameworks on a small scale) before they must attempt to integrate a common framework at the enterprise level. Of course, there has to be some coordination among the interested parties.
In their success, tools killed frameworks. The new line of client/server and general-purpose application development tools (4GL and visual development tools) gives developers "new and improved" but different approaches to systems design and development. The result is many applications, all using different tools, and none able to share objects.
The Web was the final death knell for frameworks. As we became enamored with the thought of using the Web as a common platform within platforms, we once again changed tools and enabling technologies. Moreover, with the advent of Java, interest in C++ (once a rock-solid standard) is falling by the wayside.
The Web, however, while having a dark side, also offers opportunity. New technology such as Java promotes the use of object-oriented languages and, thus, the use of frameworks. Whatıs more, Java is a "write once, run everywhere" language thatıs able to replicate the runtime environment on many different platforms. While Java is not C++, it could provide application architects what C++ never really did: the ability to share objects across the enterprise.
The San Francisco project began in 1994 when a group of developers asked IBM to build a technical foundation for next-generation applications. IBM based the technical foundation on object technology, giving developers the ability to share common objects across applications using object-oriented mechanisms such as inheritance. In this case, IBM designed an integrated group of software objects that contain the foundation for an application that cannot function by itself as an application ı another framework in the making.
The goal of San Francisco, as currently stated, is to help developers make their products unique while sharing a common foundation of business functions. San Francisco is also looking to provide a cost-effective method for adding new features in less time. It also hopes to give the enterprise a migration path toward object technology for those who have yet to take the plunge.
San Francisco is using object technology to get to where it wants to go with the goal of creating an easy transition path to object technology for customers. San Francisco selected Java as the object-oriented language and architecture of choice. Although this is a good choice because of the popularity of the language and its momentum in the market, Java is still a bit wet behind the ears. Whatıs more, itıs uncertain how Java will succeed in the demanding world of enterprise applications. Problems such as performance still need solving.
I see the San Francisco framework as providing the most value to vertical-market software vendors who want to create custom applications on a common set of services. For example, Lawson Software has already implemented the general ledger portion of San Francisco with its packaged application offering. Others are soon to follow. I also see San Francisco playing in the enterprise application development space, once it has proven successful in the package market. To this end, San Francisco is focusing on business management software, such as financial systems and manufacturing planning systems. IBM is not addressing the needs of horizontal software, such as personal productivity and office automation. This is a good choice if you ask me, considering the popularity of products such as SAP R/3, Baan, and PeopleSoft, and their steady growth in the market.
IBM is using a phased development approach. In the first phase IBM will provide the framework for the general ledger, accounts receivable, order processing, and warehouse management functions. Applications that leverage San Francisco are available now.
Interestingly enough, San Francisco will initially run on Windows NT. But very soon youıll be able to run it OS/400, AIX, and OS/2. Pretty much anybody whoıs anybody in the software development world has signed up with IBM, with the exception of Microsoft.
There are four layers in San Francisco (the framework, not the city). Developers can leverage any or all of the layers to provide value to an instance of an application. (See Figure 1.) When looking at the framework in the context of the client/server model, itıs clear that the framework exists at the server. Itıs the responsibility of the developer to create the client portion of the application. The developer customizes the application using the framework as a foundation.
The lowest layer is known as the Base. Itıs the layer that interacts with the native features of the platform. The Base leverages the Java Virtual Machine (JVM) to access platform-specific features. The Base layer manages the interfaces to the operating system as well as other applications and the network. Moreover, the Base is the foundation for the higher-level objects and can carry out such operations as finding objects, providing an object naming service, installation services, and security, as well as resolving conflicts. The Base layer comes with the Object Model Classes, which are low-level objects that serve as a base for higher-level objects in the framework. Thus, developers may leverage these objects rather than having to go to the native APIs (Win32). This not only provides ease-of-development, but it also maintains portability.
The next layer up from the Base is the Common Business Objects layer. This is really a collection of objects that performs common functions that span most business applications. Examples of functions include calculating a tax rate, currency conversion, or units of measure. Itıs just a matter of linking to these objects from the application layer and either taking these services as is or customizing them to meet the exact requirements of the application.
Moving up, youıll find the Core Business Process layer. This is where the application becomes something recognizable, such as a general leader or a warehouse management application. Although they provide base-core features, they serve only as a framework for an application and are not applications unto themselves (for example, they donıt have user interfaces). Thus, you can consider the Core Business Processing layer as a group of objects providing business services with the potential of being bound together into an application.
The topmost layer is the Commercial Applications layer. Here is where the framework becomes an application and where developers tie all of the objects found at the lower levels together to form the application. This means that Java developers with an understanding of the frameworks will create a custom set of objects as well as the user interface. IBM is estimating that the framework will provide as much as 40 percent of the base functionality to an application, and as the framework matures it could go up to 60 or 80 percent in some cases. My guess is weıll see more like 20 percent in the beginning, moving as high as 50 percent when mature. I just canıt see the commercial market allowing applications to function like the competition, so weıll see an awful lot of customization.
The stakes are high for all players, including IBM. Clearly, the development cost for San Francisco will run into the millions. Like other framework development efforts, the return on investment wonıt come for some time. Even then, itıs going to be difficult to measure. It will be interesting to see how many vendors are still with IBM as the months turn into years. The concept of building a product over years is nerve wracking for anyone in the software development business.
There is a credibility issue here as well. IBM has a long history of putting a lot of money, time, and effort into a technology only to abandon it later. I still remember AD/Cycle and Office Vision. It is nice to learn that IBMıs business model includes a long period of investment, but I think many will panic when they donıt see the return right away. Frameworks are like an investment in a good highway infrastructure. Itıs going to take years before people realize the benefits. IBM should set expectations accordingly with all of its partner organizations.
Perhaps the bigger issue is our ability to leverage frameworks all together. We are working in an industry where youıre measured for your ability to accomplish a lot of little tasks, on time, on budget. The concept of the magical enterprise framework is the process of building an infrastructure for the long haul. Thus most organizations, while paying lip service to sharing common objects, are not yet prepared to take the plunge. My hope is that San Francisco will succeed and show the rest of the world that itıs possible to create a magical framework to add common value to any number of applications. Please donıt screw this one up, IBM.