In-Depth

Fog lifting on SanFrancisco

• By Lana Gates
• June 4, 2001

Assembly lines can be found in nearly every facet of manufacturing: the automotive industry, the food industry and the shipping industry, just to name a few. They speed up development and production. So why not use assembly lines in the software industry? In fact, off-the-shelf component assembly has been the goal of software developers for some time now. Nowhere has the effort to create assembly-line-like components been more prominent than at IBM, which in the mid-'90s moved its cross-platform component development hopes from its ill-fated Taligent effort with Apple Corp. to SanFrancisco.

"Software is the only manufacturing industry that hasn't shifted to the assembling of components," noted Joe Damassa, vice president of application development marketing for IBM's Software Solutions Division, Somers, N.Y. Damassa expects software to move in that direction. And IBM is urging it along with its SanFrancisco project.

SanFrancisco began in 1994 when software vendors requested IBM's help in taking advantage of object-oriented technology. These vendors were recreating the same components every time they were writing (and porting) applications. IBM, with the help of more than 200 business partners, decided to build reusable components. In fact, the SanFrancisco effort really started in Rochester, Minn., home of the IBM AS/400. There, circa 1994-95, developers began to work with server-side Java. Their efforts were spurred by IBM's overriding objective to provide a better means for independent third-party software vendors to support development on the AS/400 and other IBM platforms.

"We defined a set of common objects that we turned into components. We found people using SanFrancisco were initially Unix people, object-oriented people, and AS/400 and midrange people," said Damassa. "They weren't building application suites like an ERP system. They were extending systems like SAP or building small applications."

SanFrancisco's original pre-built and pre-tested application business components were based on a proprietary model. As time went on, SanFrancisco migrated to client/server, Java and then to JavaBeans. In its present release -- 1.4, released in June -- SanFrancisco is beginning to embrace Enterprise JavaBeans (EJB) as well.

This begs the questions: Is SanFrancisco an eternally moving target driven by the buzz of the moment? Is it too many things to too many people? Is it becoming too complex?

"Shortest path to completion"

The goal of SanFrancisco, according to IBM's Damassa, is application development productivity. "The quickest application is one you don't have to write," he noted. He added that the basic premise of SanFrancisco has remained the same through its history: assemble applications from components rather than build them from scratch. What is changing, he said, is the target. "We're focusing more on corporations [IT organizations] rather than just partners to use components to build the initial applications."

This target change is an important step for IBM because SanFrancisco currently really only targets ISVs, according to John Singer, program director, application delivery strategies for consulting firm Meta Group in St. Louis. IBM is trying to target systems integrators as well, he said, but mainly ISVs.

"When you get into the basic Global 2000 client," Singer said, "they don't build the same system again and again. They build once and look for the shortest path to completion. To make it successful requires a lot of discipline on the part of the development organization." On the other hand, he added, SanFrancisco "makes sense for ISVs and systems integrators because they build the same thing over and over again."

Triple-layer core

SanFrancisco comprises three layers of reusable code: a foundation layer, Common Business Objects (CBOs) and Core Business Processes (CBPs). The foundation provides the infrastructure and services required to build distributed, managed-object, multiplatform applications. It is basically an application server, according to Singer. CBOs provide definitions of commonly used business objects that can be used as the foundation for interoperability between applications. CBPs provide business objects and default business logic for selected vertical domains, including accounts receivable, accounts payable, general ledger, order management and warehouse management. As Java came to prominence, these layers were layered upon a Java Virtual Machine (JVM) layer.

The problem with SanFrancisco, Singer noted, is that the whole framework combines infrastructure services with application development code. So you are "basically buying an application server as well as a development framework," he explained. When SanFrancisco moved to Java, no servers supported Java; IBM then built its own server, which makes up the foundation layer.

As SanFrancisco moves to EJB, that problem will be eliminated. "That's where they rework it so the EJB server provides the core functionality that goes into that [foundation] layer; what you're left with is common business objects and components riding on top," Singer said. In fact, CBOs and CBPs will become Enterprise JavaBeans running on WebSphere Application Server
Advanced Edition, with support for other EJB servers, including WebSphere Enterprise Edition, expected in the future. Migration will not be simple. Moving from one component architecture to another will require regeneration of source code -- IBM is working with Rational to provide an automated migration mechanism.

Feature/function focus

There are ISVs and systems integrators looking forward to SanFrancisco's migration to EJB. They like not having to worry about the system's infrastructure or architecture, and being able to focus on developing the products at hand. Front Ends Inc., a Houston-based solutions developer, has been using SanFrancisco for about two years. "It supplied us with a lot of the application already written, and let us focus on features and functions that customers need -- not on features and functions of the architecture," said David Lubbers, president and chief architect.

Front Ends used SanFrancisco to build PatientFlow Adaptive Resource Measurement (ARM), a content-neutral workflow product for a chain of healthcare clinics in the state of Texas. PatientFlow ARM runs the business processes. At press time, Front Ends was also working on building a management project on top of a healthcare system to track treatment for a healthcare business with 1,000 clinics worldwide.

As now configured, SanFrancisco's biggest asset to Front Ends is its code generator, according to Lubbers. Front Ends, using Rational Rose, draws pictures of the application it wants to create and feeds the model to the code generator, which generates the application. "In 30 days we could model and produce code for the back end of the entire system," Lubbers said. "It would have taken man-months to produce the code ourselves."

Chuck White, service delivery manager with Keane Inc., a global IT consulting firm and systems integrator based in Boston, has also been very impressed with SanFrancisco. "For a product this full-functioned and this large, IBM's done a good job," said White, who works in Keane's office in Rochester, Minn. "It's real beneficial to companies that don't have cross-domain experience," he added, meaning a company building a financial application, for example, could also take advantage of the product's order-entry features without any experience in that area.

He added, however, that if a company is only interested in a financial application, it does not have to install the order management pieces of the framework. "The plug-and-play approach provides what you need when you need it," White explained. In other words, a company does not have to use all of SanFrancisco to realize its benefits.

IVIS International, a financial knowledge management company in Raleigh, N.C., used SanFrancisco to create two products. IVISoft ThinQuiry, a knowledge portal solution, provides seamless access to corporate electronic knowledge assets in multiple data stores through a single enterprise knowledge portal. The Java application can attach itself to any data store or knowledge warehouse residing on any platform in an enterprise so that users can access and navigate through corporate knowledge assets using a common user interface. ThinQuiry can model these physical data stores to a logical business model without knowing the applications that produce or maintain those data stores.

IVISoft Stacks is a high-capacity CD-ROM archive solution that can be deployed in place of microfilm, microfiche or magnetic tape for capturing, managing and leveraging a corporation's electronic knowledge assets on demand. IVISoft ThinQuiry is a bundled component of Stacks so that the archive can be accessed and navigated just like any other data store in the enterprise.

Like Front Ends, IVIS realized the benefits of being able to focus solely on building applications. SanFrancisco "allows us to focus our product development energies on feature and function differentiation as opposed to spending enormous amounts of time on the plumbing of distributed applications," said Gary Alexander, vice president of product and business development. "The business content of the framework will allow us to increase our speed to market, while offering us the opportunity to shape our solutions to address the specific needs of our customers."

And like Keane, IVIS enjoys being able to pick and choose which parts of SanFrancisco it wants to use. "The business content in this framework is phenomenal," said Alexander. But is it too big? "There is no doubt that there is a lot of software in there," he added, "but it is accommodating an awful lot of people with an awful lot of different business agendas and needs." He believes, as does Keane Inc.'s White, that SanFrancisco is to each company what they want it to be. Front Ends' Lubbers said that although SanFrancisco is very large, it is not overly large.

Steep learning curve

Meta Group's Singer, however, disagrees. "In its current incarnation, [SanFrancisco] is too big because a lot of it covers the application server portion, which is what [IBM is] changing," he said. Aside from that, SanFrancisco's order management and warehouse management CBPs have 700 components. "That's a lot to master," Singer noted. "The issue for being able to make use of something like this is the time and effort you have to put into it. Once [IBM] removes the infrastructure part, it will be less bloated but still complex enough that the learning curve would still be an issue."

Market research firm Gartner Group, Stamford, Conn., found the same thing to be true. Based on SanFrancisco's Java version, the firm expected fewer than 5% of the 30,000 vendors of packaged software for small- and mid-sized enterprises to have SanFrancisco-based products on the market by 2001. Gartner Group attributed this small percentage to the vast learning curve involved. Actually, it found that vendors would have to climb three different learning curves: retraining staff in object principles, teaching developers the SanFrancisco framework, and training field support personnel in the complexities of Java deployment.

The EJB version should make SanFrancisco easier for more people to use. "Breaking it out into more manageable size components will help," said Singer. He added, though, that IBM would have to build in modeling and code generation capabilities to make the framework easier to use.

Migrating to EJB

The migration from Java to EJB seems to be a natural one, according to ISVs and systems integrators alike. IBM's Damassa feels the same way. It is no secret that technology changes. "IBM is now throwing its weight behind EJB as an industry open standard," explained Damassa. EJB support opens SanFrancisco server-based solutions to more choices in databases, hardware and operating systems.

Keane's White agrees with Damassa. SanFrancisco is helping set directions in the industry, White said. "The move to the Java language and EJB makes it more of an open environment," he noted. The way IVIS' Alexander sees it, "SanFrancisco can be used to develop and deploy solutions today. In the future, EJB will be the end game as far as distributed object Java-based solutions are concerned, and IBM is moving aggressively in that direction with this framework."

IBM intends to migrate SanFrancisco CBOs and CBPs to EJB components in a 12- to 24-month period. SanFrancisco 1.4 was the first step of the migration process. The rest of the migration will take place in three stages. A technology preview, scheduled for year-end 1999, will provide an initial view of the direction IBM will take when migrating SanFrancisco application content to EJB.

The second stage, a development release, will contain much of the function to be included in SanFrancisco's EJB version. This release should be available during 2000. The final stage, a fully deployable release, will complete any remaining migration of CBOs and CBPs, additional servers and enhancements. This can be expected six to 12 months after the development release.

In addition, IBM plans to provide a set of migration tools to help automate the transition of many of the applications built with SanFrancisco 1.4 to the EJB version. These tools will be part of the development release.

IBM's Damassa said customers overall are embracing SanFrancisco and EJB. "Ninety percent of our Fortune 2000 customers have at least three or more server platforms," he said. "They're not going to throw that all out, so they love the promise of Java and EJB to help them maintain what they've built."

Migrating SanFrancisco to EJB will make it possible for SanFrancisco-built applications to run on any EJB server, including IBM's WebSphere Application Server. That is one thing that Front Ends is looking forward to -- that and IBM developing the tools necessary to develop on top of the WebSphere product suite, said Lubbers. In addition, Lubbers looks forward to seeing development companies build applications on top of SanFrancisco objects that Front Ends can then offer to its customers.

IVIS' Alexander expects to see IBM expand its CBOs and CBPs content to include more domains over time. "Right now, it's very financial systems-focused," he explained, which is highly complementary to IVIS' ISV business but could be a hindrance to other companies. Another thing that is lacking is an object-oriented database. Front Ends would like to see SanFrancisco adopt one; the technology currently supports DB2, Oracle and SQL Server relational databases, but not an object-oriented database. "It's kind of a weird scenario," Lubbers said. "You deal with objects in the code but then they get dumped into a relational database. It would be nice if it was objects pure and simple all the way through."

IBM definitely has some hurdles to cross before it can realize its vision for a "software assembly line." Meta Group's Singer likens IBM to other vendors of complex development frameworks: Forté, Dynasty, Uniface. "They haven't necessarily taken the world by storm," he said, adding that IBM has the same hurdles to overcome, namely the complexity of the framework. "You can't deal with this [complexity] unless you have strong object-oriented skills," he said.

Gartner Group agrees. "Small software vendors and corporate developers experienced in the use of objects can leverage their skills through SanFrancisco," stated a research note by Gartner's Ross Altman, analyst, and Jim Duggan, research director for application development and management. "Others should wait for a future version that can provide a smoother transtion.