Blogs

RedMonk

Skip to content

Time for IBM to restart the San Francisco Project?

Anyone remember the San Francisco Project ? It was an IBM initiative in the mid to late 1990s to turn some basic business application functionality-general ledger, say-into shared intellectual property that a range of ISVs could use to build applications.

The San Francisco Project (SFP) basically failed, with much of the technology being folded into other efforts, notably Enterprise Java Beans (EJB) in 1998.

But would SFP fail today, given what IBM now knows?

The context today is far more appropriate than it was, in a formal Gladwell Tipping Point sense. What’s different?

The Internet

  • Has proved its worth as a coordination and collaboration mechanism

The Rise of Open Source

  • Eclipse: showed that IBM can succeed with an open source project and create an open ecosystem in the process
  • Linux: you may have heard of it
  • Gluecode – making money on the service, not the code

IF IBM doesn’t do it, Microsoft will

Better hardware and Java performance.

  • One of the major sticking points with San Francisco was system performance. The level of abstraction of the components meant they were not sufficiently performant for use in business applications.

IBM would not have to break its commitment to ISV partners that it won’t sell applications in order to proceed with a strategy to breathe new life into the SFP, but could begin to make arguments and investments against Oracle, SAP and Microsoft, which all sell both applicaitons and infrastructure. IBM could make the argument to partners it was offering them a go-to-market advantage, similar to the Eclipse effect. Increasingly, the money in this business is is going to be packaging and maintaining software, rather than building it.

Industry consolidation in the business application space by Oracle and SAP leaves IBM somewhat exposed though. Bib Blue is badly in need of control, or at least competitor commoditisation points.

IBM probably still has the source code, and knows exactly what ISVs contributed the first time around.

One of the leading lights in SFP – Danny Sabbah, who now runs Rational, is fond of saying “There is nothing new in IT”.

He is right of course. Most of the basics of computer science are done already–Goldfarb was thinking of markup in 1966! The question is how and when we apply these core concepts. Thus, OTI becomes Eclipse, and so on.

What matters most is context, and it seems to me that the context today for standardised, community-built, business logic is very different. So why don’t Danny and Buell sit down and think about that Golden Gate, bridging application logic and infrastructure, and how IBM can work more effectively there.

Categories: Uncategorized.

Comment Feed

16 Responses

  1. “Golden Gate”… wasn’t that a Borland initiative, aimed at coat-tailing IDAPI onto the (anticipated) success of San Francisco? I hate it when those late-90s memories get stirred up. (J.D. Edwards, that was proper software. Marcam, they were good. Kids these days…)

    But yes, the SF framework does seem like an idea whose time has come – at least, it seems a bit more like an idea whose time has come than it did back then.

  2. San Francisco would still fail today as it the model isn’t just about producing code. They never figured out how to get customers of large Fortune enterprises to participate in shared development…

    http://duckdown.blogspot.com

  3. James – You are not the first person to suggest that IBM bring back the SFP – curious…

    Teressa JimenezNovember 16, 2005 @ 2:02 pmReply
  4. Well i know ZDNet picked up on the idea from my blog… but its no surprise the idea might resurface in more than one place.

    most of all THANKS FOR COMMENTING!!!

  5. Ah great point as usual Mr McGovern. On the other hand – isn’t it possible enterprises would be more open to the idea today? OSS is less scary than it was. I believe that you have argued that analysts and or vendors should encourage enterprises to open source some of their componentry – there are examples out there.

    how can we help enterprises better understand open source governance and its advantages. instant shared escrow anyone?

    and what better way to customise open frameworks than with vertical community… you said this last week (infoworld):

    McGovern said his Hartford, Conn.-based financial firm would be more receptive to open source products if they existed in a format that would address specific components of the financial industry off the shelf.

    “In our particular industry, selling insurance, we have some things that are common amongst all other players in our vertical [including] notions of rating engines [and] claims and policy administration,” he said. “If there were OSS components that we could pull off the shelf and [that] get us closer to solving our real business problems, we would be very interested in those things.”

  6. An open-source on-demand story is a bit sweeter than a plain open-source Enterprise stack.

    This is how it plays out:
    1. IBM open sources a reference implementation which provides standard API for integration between various application blocks, such as GA to Asset Register to HR. IBM then encourages VAR to either sell hosted versions and for committed buyers to host them in house

    2. IBM then provides on-demand facilities to provide load balancing, as well as a migration path to a more performant version.

    3. IBM continue to command mind share through providing add-on Rich Client components such as Outlook plugins, etc

    4. Customers already on other platforms get to pick and choose application blocks which have better functionality than their own and hires IBM to integrate to it using the standard APIs.

    5. IBM’s hosted service might chose to aggregate customer information and selling them to bureau of statistics, or like Google, sell ads… integrating into the Purchasing system.

    6. IBM could provide a user-pays WS backend which vendors pay to determine when the next sales call is appropriate, and for production planning. This is viral and will bring more players into the system.

    7. Existing ISVs which doesn’t have a complete offering (e.g. GL for small businesses) could expand their offerings by integrating to the API and offer a full suit. This brings in existing players. In their long term interest, they will see it fit to migrate their GL to the integrated IBM offering too, since it’s less development expense in the future.

    Who does this put at risk?

    The losers are large Small Business Accounting vendors which often have scaling problems. e.g. Microsoft Small Business Accounting, which by default doesn’t work over a LAN, and software such as Quicken.

    The market dries up for medium sized ISVs, who market their GL or HR or manufacturing product. Some who survive on their existing support agreements, but find it harder to win new clients.

  7. Great post James. Whilst you mention a few reasons why SFP might be more viable today, the big two are:

    1. ISVs, particularly those serving the SME market, know they are under threat from the impending weight of aggressive competition from Microsoft, Oracle and SAP, let alone the existing SME heavyweights, Sage and Intuit. If they build to SAP’s or MS’s platforms in order to reduce their development costs, they know they are very likely to be squashed in due course by their “partner” when it builds out its functionality to include the ISV’s niche (unless its a really small niche). Only IBM offers a no-compete promise that an ISV can rely upon; and

    2. IBM does need to try something to halt the ongoing aggregate success of Oracle, MS and SAP in being able to bundle and sell applications with infrastructure (JP Morgan’s analysts call this “appli-structure”). In a world where infrastructure has become commoditised (well, at least its commoditising), IBM’s pitch to ISVs to use our infrastructure just isn’t all that compelling: however, using our infrastructure AND base business application software is exciting. And if IBM did this, yes it could think of creative strategic deals with the likes of Sage and Intuit, and offer the larger ISV world a way to thrive against Oracle, MS, SAP.

    Keep up the good work!
    Cheers,
    Nigel

  8. thanks nigel.

    Nigel and Chui Trey have really made me think more clearly about opportunities and so on and how it all fits together

  9. James,

    I too have been giving further thought to this over the past few days, and hope you will do a follow-up at some stage because its such an interesting concept. Here’s how I see some key issues.
    – Irving Wladawsky-Berger has made some interesting posts recently on his blog concerning the industry-wide benefits to be obtained in standardizing common business processes. Whilst he has focused on SOA as a means for businesses (and industries) to adopt these, a San Francisco project would also facilitate this (although its sounds like it was SOA-ish to a large degree anyway).

    – I agree with one commentator to your original post that SFP won’t work with large enterprises: however, it would with SMEs, and the ISVs who serve them. In fact, given SOA is a long way off entering the SME world (its still a long way off entering the large enterprise world, if people are honest), then SVP would be the best way to achieve what Irving is envisaging;

    – Is it really practical to dust-off and deploy SVP? I wouldn’t have thought so. I also cannot imagine such a large, distributed project as SVP 2.0 succeeding in a time frame that is acceptable. However, what about IBM buying such a product (i.e. a generalist ISV), adding to it and then opening it up for use by ISVs? What about using Compiere for this purpose?

    – In your original post you say “IBM could begin to make arguments and investments against Oracle, SAP and Microsoft”. I can see the arguments angle, and I can see investments in general marketing. But did you mean investments in ISVs? Doing so raises the conflict issue. But on the other hand, without doing so leaves IBM open to another PeopleSoft or Siebel scenario, that is, losing important ISVs to acquisition by infrastructure/middleware competitors.

    Cheers,
    Nigel

  10. I do think so, and the trends are going like Google Map. After hardware/software in formation, then groupware/blogware in function, now is to integrated resources, services and functions into a ware, I call it usageware.

    Then we can develop new business from this viewpoint. For an example, currently mobile phone operaters’s call center can say “hello, Mr. Bao” when receive my cell phone call, and actually they know my location when calling. In a usageware era, any enterprise can get this advantages for their customer services, by using a usageware from MP operaters, without the need to know the MP user database and how to locate the users.

    my blog in http://proven.iblog.com

  11. Hi James,
    A friend of mine in Nebraska informed me of this blog yesterday.

    Believe it or not, there has been a full blown Enterprise level software package based on the San Francisco Project principals available from Mid-Comp International in Melbourne, Australia since 2002. It’s called Odyssey, and it has fully embraced all the SF concepts with the exception of distributed databases. ( We opted for a central data respository after it proved 10 times faster in trials)

    Is it a toy? Well, it has completely replaced JDEdwards & IMAS, and has sucessfully competed against SAP, Movex, IBS, Great Plains, etc.

    Mid-Comp has deployed Odyssey into the Australian subsidiaries of companies like Nintendo, who have been using it to run their entire Australian operations for the last 4 years.

    It currently consist of over 22,000 classes & approximately 800 JSPs.

    IBM have known about it for years, but unfortunately are not all that dynamic in assisting us to tell the world ….. that it exists and that it actually works !! Maybe there is simply disbelief?

    Anyway, just thought your group should be made aware that we’ve “been there, done that”

    Best Regards,
    Steve

  12. I know, I have encountered this blog a bit too late, but I canť help myself and I have to post some remarks. I was amazed by SFP at those days in late ninetees and I still believe that it was a big idea.
    I’m convinced, that the real causes, why San Francisco project “failed” weren’t technical ones. For me, it was because managements of companies, SFP was aimed at (let’s call them ISV’s smaller than SAP), were not able to understand, what such an idea (of building an “virtual SAP”) could bring them. At those days, I was working for a company of exactly that type, that were companies, that initially prompted IBM to create something that turned out to be SFP. It was an AS/400 shop searching for where to go next, intending to transfer its applications to Java.
    Management decided not to go the San Francisco way. I was convinced then, that we can (possibly) rebuild our existing systems in Java either based on SF, or we are not able to do it at all. Unfortunately, the option 2 came true.
    But I still believe, that the idea of building a “virtual SAP” backed by IBM is a right one, not just for IBM, but also for many others.

    Stanislav KoblizekFebruary 3, 2008 @ 11:36 amReply
  13. My dad was the lead architect for the san francisco project. He quit IBM after they decided not to go the san francisco route. He is now a professor and he is still convinced it would have worked. Oh well, IBM can do what they want.

  14. I am not sure that this will be started up again. It is a shame but I guess we will have to accept it.

  15. I was there!

    In 1998, I was working with IBM’s SF Java Programming group. But before 2000 I was laid off with no explanation, and to this day (2012) I have never learned about the fate of the technology and tools we were developing.

    In 2002 (I think) I found a book at the software bookstore, describing the SF object structure. The book was over 1000 pages, and over $100.00
    But I have never actually met anybody who has heard of IBM’s San Fransisco Java framework.



Some HTML is OK

or, reply to this post via trackback.