|
|
|
With more than 200 partners and developers involved, the San Francisco project constitutes the largest single Java development program in existence. Could this be the shining dream IBM hopes it will be, or is it just another passing fancy?
For decades, San Francisco has been thought of as America's City on the Hill, a place where dreams begin amid a haze of fog and blasts of sunshine. Now, IBM is borrowing the name for its Shared Frameworks initiative, an ambitious effort to help hundreds of business partners leap into the modern age of object-oriented programming, Java, and multiplatform deployment. In the recent past, IBM tackled a number of these ambitious efforts (AD/Cycle, Taligent, and OpenDoc come to mind) and all were essentially failures. Will the San Francisco Project's fate be any different?
The San Francisco Project is a sophisticated, complex set of business object frameworks written in Java that IBM developed during the past three years in conjunction with more than 200 partner organizations. Currently, the San Francisco Project is recognized as the largest single Java development program in the world with more than 200 developers on the team.
In August, IBM released the first products to come out of the effort: the San Francisco Foundation and Utilities and the San Francisco Common Business Objects. Together, these products are known as the San Francisco Base software, or the San Francisco General Ledger, and they make up the first in a series of Core Business Process frameworks. This toolkit will be provided initially on the Windows NT and AIX platforms-due to some platform-specific tools such as IDEs and installers, it's not quite ready (but is aiming for) 100% Pure Java certification. Next will be releases for other platforms including IBM's OS/400, Hewlett-Packard's HP-UX, and Sun's Solaris operating systems.
Two analysts, David Andrews and Maria DeGiglio of the D.H. Andrews Group, have followed this project closely. Their August 1997 report states, "Without a great deal of fanfare, IBM has quietly developed a product that could change how application software is created. The product...will allow developers to spend less time creating more sophisticated applications."
Business Frameworks
What is a business framework? It's a set of objects designed to cooperate on accomplishing business tasks that are designed to be extended from the beginning. This concept differs from previously released frameworks in that it focuses on business objects. Previous frameworks (Microsoft's MFC and Rogue Wave's zApp, for example) generally focus more on a specific technology such as cross-platform operating system services and GUIs. The San Francisco Project is a set of object frameworks, each one encapsulating a specific domain produced using rigorous object-oriented analysis and design.
This initiative originated when about a dozen of IBM's AS/400 business partners approached the company looking for help in making the transition from their existing, outdated COBOL and RPG technologies to object-orientation, GUIs, and multiple delivery platforms. The project was originally implemented in C++, but in early 1996, IBM managers realized that Java was a much more promising path to take. The partners, generally small- and medium-sized vendors offering various accounting and vertical market packages, were reading about these new technologies and saw the sudden rise of new major competitors such as SAP and PeopleSoft. They realized that to be competitive they needed more resources than their individual organizations could manage.
"We designed San Francisco with our development partners from the ground up to enable businesses to compete more effectively in the emerging global marketplace," says Steve Ladwig, general manager of network computing and software for the IBM global, small, and medium business units. "The Java-based software building blocks give developers, especially those focused on meeting the needs of small and growing businesses, an innovative way to lower development costs and improve time to market." IBM estimates that an application taking advantage of the frameworks will get at least 40% of its code from them.
The partners are not getting San Francisco for free. While the initial look and developer education are provided at no cost to potential partners, IBM charges a "low single digit" royalty rate (which decreases as the sales volume increases) once applications built on the framework go on sale; and service revenues related to application sales-such as training, consulting, and maintenance-are not included in the calculation. Andrews and DeGiglio believe that IBM has chosen a pricing model that may even help the project succeed (even though it is risky for IBM) because it allows for the wide variation in pricing models used by the independent software vendors who are, after all, the project's direct customers.
The partners are scattered around the globe. They include North American companies like Lawson Software, Acacia Technologies (a division of Computer Associates), ActionWare, and Visient Corp.; Asian companies such as Teijin Ltd. and Sumitomo Metal Information Systems Corp. (both from Japan); Lansa Aspect Computing Ltd. (Australia); and European firms G.U.S. AG and Company (Germany), JBA Ltd. (U.K.), and International Business Systems (Sweden). Some of these groups are closer to the effort than others; JBA Ltd. and International Business Systems, for example, are the only companies outside IBM that work directly on the programming effort. There is also an inner circle of about a dozen partners that IBM closely consults regarding design issues.
A second group of tool vendors are committed to supporting San Francisco in their own products. These vendors include Tower Technology Corp., which will provide support in its Java IDE; Synon, which will provide support in its Obsydian business process analysis and fourth-generation language tool; Rational Software, which will add San Francisco object-oriented analysis and design modeling and code generation to Rational Rose for Java; and Borland International, in the JBuilder Java IDE. In fact, Rational Rose was used as an integral part of the San Francisco design process and part of the documentation supplied with the San Francisco toolkit are numerous Rose model diagrams.
Inside the Framework
The framework itself is a reasonably complicated entity that comprises more than 2,500 classes. It is divided into three layers: Foundation, Common Business Objects, and Core Business Process. The three layers provide a distinct segment of the overall functionality: the Foundation layer contains basic services and definitions; the Common Business Objects layer contains intermediate, somewhat complex entities that are useful aggregations of Foundation layer classes; and the Core Business Process layer is a set of full-featured business frameworks.
The design process included consultation with the partners. The first round determined what the framework would include and what the partners would design for competitive differentiation. For example, as a result, IBM did not supply any user interface implementations except for a very skeletal GUI that was useful for the partners' own education and understanding. The second round of consultation focused on how the partners would extend and change the supplied source code; partners are supplied with the source to the Common Business Objects and Core Business Processes layers and are free to change them as desired.
Patterns in the Framework
The design team at IBM didn't neglect its homework either, learning much from the Gang of Four effort Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (Addison-Wesley, 1995). IBM defines a design pattern as a reusable solution for frequently encountered object models or scenarios. Patterns, according to lead architect Kathy Bohrer, offer four main advantages: they speed understanding, reduce design and programming errors, allow the use of less experienced team members, and reduce maintenance costs and testing time. The San Francisco designers divided the patterns they used into two groups: cookie cutters and mini-frameworks.
An example of the cookie cutter type of pattern is Dynamic Identifier. Classes based on this pattern are enumerated types that can be dynamically modified by users as the application runs. A list of departments might start with 10 entries, but after a corporate reorganization, only seven might remain. Administrators are provided with tools for this type of maintenance task and the application does not need to be stopped and restarted. The General Ledger classes AnalysisCode and AnalysisGroup implement Dynamic Identifier; an AnalysisCode represents a specific account in the chart of accounts; AnalysisGroup is a user-defined set of code that makes up a useful group for reporting things such as accounts needed by the government for legally required reports or department managers for determining the health of their unit.
An example of the mini-framework type of pattern is Balanced Caching. This pattern lets developers identify a set of parameters, such as specific account balances in a set of accounts, for a specified period of time, to be cached for fast response (so the balances don't need to be recalculated every time an application must retrieve one). The CachedBalancedSetCollection class (part of the Common Business Objects layer) is one which implements this pattern and in turn is used by the General Ledger Core Business Process to manage the various subsidiaries and other independent entities that make up the enterprise actually running the software.
The extension point strategy-which provides classes, methods, or objects that are built into the framework explicitly to be replaced for extensibility-supports easy identification of where to make changes. It also facilitates developer ease in understanding how to make those changes. This is important because one of the project's primary goals is to make frameworks easy to extend. This strategy also uses a set of design patterns:
*Properties, which let implementations add attributes and establish new object relationships at run time
*Policies, which replace or modify business rules
*Encapsulated Chain of Responsibility, which lets you use different policies for different objects or processes
*Special Class Factories, which provide a special class factory to map objects to existing database tables or partition objects of the same type across different servers.
Other Parts of the Framework
The Foundation layer consists of a set of basic services such as name service, object transaction service (for persistence), object movement management (partitioning) and locking services, plus utilities. This layer is further divided into two segments: the kernel and the foundation object model classes. The actual functionality is implemented in the kernel, while the publicly exposed services are in the foundation object model classes. This division preserves the Foundation's flexibility and allows for evolution and enhancement without disturbing client classes that would otherwise depend on specific implementations. A key foundation object model class is Entity, which encapsulates several of the kernel services including persistence, locking, and security.
For example, this Foundation layer runs on top of the Java Remote Method Interface (RMI) to support distributed processing. However, it may be necessary to replace this functionality with a true CORBA ORB or even an implementation of Microsoft's DCOM. IBM also recently shipped Component Broker, which includes development tools, DSOM 4.0 (a CORBA 2.0-compliant ORB), and the capability to connect components developed in multiple languages, using multiple communication pipes, various data stores, and running on multiple platforms. However, there is no explicit integration between San Francisco and Component Broker in this first release, but the architecture should simplify a future transition if that choice is made.
One of the key utilities provided with this layer of San Francisco is the schema mapper. This tool lets developers correlate class data members with specific database schema objects. The initial mapper only supports POSIX (flat ASCII) files and the IBM DB2 and Oracle databases, but not ODBC or JDBC connectivity. According to Verlyn Johnson, an IBM advisory software engineer involved in the project, these are the only databases the partners required.
The second layer, the Common Business Objects, provides definitions of commonly used business objects that you can use as the foundation for interoperability between applications. This layer is composed of several independent frameworks (comprising more than 170 classes) that fall into one of two categories: business objects common to multiple domains and common application level services. In general terms, business objects are entities that a person who is knowledgeable in the domain would reference when describing how to perform a business task in nontechnical terms. Business Partner is an example of a business object that occurs across many domains.
The class encapsulates the characteristics of a partner or a supplier such as default currency, description, and the languages used by the partner, and extends the Foundation's Entity class. Another example of this type is Address, which provides a generic way to describe a location (including a postal location). Common application level services are more likely to be identified when discussing an approach for automating a process. This layer is particularly useful for inter-application communication and cooperation; by using the same underlying object definitions and base services, there is no need for translation.
Decimal Structure, which lets you define the number of decimal positions and rules about how the number is to be processed, such as rounding on input or output, is one of the application service objects included. Another application service is the Sequential Number Generator, which programmers often need to code themselves or else be dependent on a database-specific API.
The outer layer, the Core Business Processes, covers significant business domains. Its primary objective is to create a sound architecture and a highly extensible object-oriented implementation for the basic structure and behavior any application provider delivering a solution in the selected application domains would require.
On top of this, a very limited set of application functionality is implemented so the frameworks will actually do something useful out of the box. This layer gives independent software vendor partners the greatest leverage; they can implement a well-designed user interface, proprietary business rule algorithms, and regional requirements built on a solid foundation. However, the partners are free to jump in at any of the three levels depending on their needs. IBM even expects that some kernel functions will be swapped out for third-party implementations.
The first domain the project team is focusing on is business financials, which includes General Ledger, Accounts Payable, and Accounts Receivable Core Business Processes; the General Ledger is part of the initial toolkit release. Other early Core Business Processes planned for development will include Order Management (Sales Order and Purchase Order Core Business Processes) and Warehouse Management. The General Ledger framework contains the structure and default behavior related to managing the accounts on the general ledger for a company or hierarchy of companies. Examples of the business tasks it supports include journaling (create, validate, process, and post General Ledger journals) and closing (close the books for a General Ledger accounting period such as month or year).
A prime goal for the project is to help the partners' development staffs make the leap from the traditional waterfall development life cycle and procedural programming paradigms to modern iterative development life cycle and object-oriented programming. Delivering the Core Business Processes as it has done, IBM is earnestly meeting the goal. The design models and source code for these high-level aggregations can be read and studied for their educational value as well as used as application building blocks.
Writing on the eve of the first product announcements, a definitive answer to the question of whether or not IBM's San Francisco project will succeed is premature. However, several meaningful differences from the early projects are already apparent:
*IBM did not launch this program with immense publicity and fanfare. Instead, work was done quietly and deliberately with a large group of partners and not in the glare of constant press releases and analyst pronouncements.
*IBM worked closely with a large group of partners who really are the customers to understand its requirements to the nth detail rather than assembling a set of industry insiders to decide the customers' needs for them.
*The San Francisco Project is based on real, existing (albeit cutting edge) technology and is an attempt to apply that technology, not invent more.
*The first real burst of sunlight being given to the project is the announcement of real, usable products.
These factors aren't conclusive; the question will not be truly answerable for a year or two, when IBM's partners have built and tried to sell their own products based on this framework. However, as a further sign of the giant's turnaround, San Francisco shows that IBM is learning its lessons and trying to live in the current age of computing; yesterday's glories are celebrated, but aren't ruling the present.
The Andrews Group report cites several additional reasons to be optimistic: the first release has overcome some of the hardest problems; IBM is not pushing for near-term profits; a large number of application developers need San Francisco to succeed; and, the business proposition is attractive to independent software vendors. How can you judge for yourself if this product is living up to its potential? Key indicators include a steady stream of function and performance improvements, software tools with San Francisco-specific capabilities, real deployments of San Francisco-based applications, and customer demand for these applications.
The San Francisco Project is a sophisticated effort that may result in one of the first widely used, powerful business object frameworks. The design clearly takes advantage of well-understood object-oriented analysis and design procedures, design patterns, and spiral software construction practices. The move from C++ to Java shows an organizational maturity that many would not have recognized even a year ago. The final answer may not be in, but clearly the cards are falling in the right combinations.
