The San Francisco Treat(ise)

San Francisco, the city, provides a melting pot for different ideas, background and cultures, bringing creative people together to make a great city. IBM Corp.'s recently upgraded San Francisco application framework seeks to bring together diverse tools, expertise and platforms to create great software. With public transportation, easy access, various attractions and splendid architecture, the city truly has something for everyone. Similarly, IBM has merged many stages of the software life cycle to make the San Francisco framework appealing to enterprise developers and ISVs alike.

The San Francisco business framework germinated in 1996 out of IBM's AS/400 division, back when IBM's System Object Model (SOM) and Microsoft's Component Object Model (COM) were still on equal footing. As SOM lost and Java gained the attention of the industry, San Francisco morphed into a Java framework. Release 1.2 works with a number of popular Java tools, uses leading third-party analysis and design tools, and has licensing agreements with 400 ISVs.

The scope of the San Francisco initiative is huge. The framework addresses the entire software lifecycle: collecting business process information, performing analysis and design, generating and modifying code, reiterating designs, and delivering applications. Most companies spend a great deal of their time developing and redeveloping noncompetitive core business technologies -- noncompetitive meaning that clients don't consider these technologies part of the feature set of the product. IBM figures that up to 80 percent of business software development is sucked up in these core processes. San Francisco will eventually offer a complete set of common business objects (CBO), allowing vendors to license the core objects, while concentrating on the 20 to 30 percent of the software that provides client value and product differentiation.

While San Francisco, the city, is divided into districts, San Francisco, the framework, is divided into three layers of reusable code: Foundation, CBOs and Core Business Process. Unlike other frameworks, where only the highest layer is designed for reuse, San Francisco allows for extension of any layer.

The Foundation layer provides the technical underpinnings required for a distributed, cross-platform, object-oriented solution. San Francisco melds the Object Management Group (OMG) service definitions with Java functions to create a simplified kernel service layer providing object collections, object transactions, inter-object communication and object persistence management. However, the framework does not provide a CORBA-compliant Object Request Broker. The Foundation layer also provides a skeleton of both usable objects and interfaces, called Object Model Classes, which programmers can use instead of defining their own, incompatible architectures. These objects implement many of the design patterns that occur again and again in any programming task.

The CBO layer provides higher level objects that are specific to business solutions but are likely to be used across many business domains. Examples of CBOs include currency, customer, address, language and invoice. In software aimed at the global market, developing just these seemingly simple items can consume tons of resources. CBO can be extended to add specific behaviors for an individual business domain.

The Core Business Process layer is the highest level of the framework. Its goal is to encapsulate vertical business processes and logic. At this layer you will find nearly complete business modules such as General Ledger, Warehouse Management and Accounts Receivable. IBM expects that the Core Business Process modules will provide about 40 percent of an application's functionality right out of the box. Framework programmers will have to enhance the user interface, apply industry and international customization, define specific business rules, and add competitive differentiators to the product.

I find IBM's framework interesting because of its focus on solutions rather than technology. The San Francisco documentation emphasizes a development process that involves business domain experts as well as technologists -- a key to success. By providing applications that have basic functionality right out of the box, developers should find it easier to remain focused on the goal of most business software: user interface, integration, domain-specific features and competitive differentiation. More times than I care to admit, I've found myself staring at a new project and facing the daunting task of developing all the same core services again in a new language or paradigm. Often, by the time the core services are finished, the team has burned too much energy to provide excellent differentiators.

IBM's San Francisco model holds promise, but its extremely broad scope adds liability. Only a company with Big Blue's clout and experience can pull off such a broad initiative. Once more compliant products are released, Java's performance issues are addressed, and questions of enterprise licensing are ironed out, IBM could witness a rush to the business application gold of San Francisco.

Eric Binary Anderson is Development Manager at PeopleSoft's PeopleTools division (Pleasanton, Calif.) and has his own consulting business, Binary Solutions. Contact him at