Fog lifting on SanFrancisco
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."
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
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
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
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
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
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.