First of all, I'm getting VERY curious as to your background and what you do now (not for recruiting, just out of complete curiosity). You'll have to shoot me a note offline if you are willing:
pmonday@comcast.net.
I do have a bit of a different perspective on this...
Originally posted by HS Thomas:
Goals of San Francisco Component Framework
==========================================
1: Building a library of reusable business objects that could be used with ease in any part of the globe.
Lesson : Business systems are more complicated than operating systems and GUIs.Note we have many View Technologies but few whole component frameworks.
BTW, what are initial impressions of Spring Framework ? - (it seems to be an MVC for any type of distributed technology, at first glance.)
I could add that there is a gap between the language of the framework and Business Analysts who didn't seem to accept that they should learn the framework or UML for OO but prefered an unconstrained approach.
"Light came to them sideways, behind and sometimes from the front"
Unfortunately or Fortunately , I think this attitude is still true. Perhaps your book can be used for effective communication with Business Analysts ?
Building reusable component frameworks for business is "hard" for a few reasons:
- Business processes are largely organic and viewed as a "value" for a business (though this is changing), therefore, generalizing a business process and creating "plug" points essentially commoditizes a business process (not something businesses sometimes even accept as possible)
- You are right about the "gap", though I would push the gap even farther. With so much given to you off the shelf, there was a substantial amount to understand and learn...often, individuals feel they will be more adept at building it themselves than having to learn all of this "stuff"
- The framework suffered from a lack of standardized business process languages and workflow engines (much of this was built into the framework in a specific fashion...like lifecycle management)
- There is a severe gap in knowledge between a technical team building a framework and the type of people who have to use the framework (to be adept at SF you had to have good knowledge of OO patterns and the SF patterns, yet the closer you get to a customer, the less of this can be exposed...by the time you are IN a customer site, you are dealing with consultants and IT folks that frankly don't have time to learn SF design patterns since SF is a part of their toolkit, not their only tool).
- There are already business processes in place at enterprises that don't always match the coarseness and granularity of SF...further, there is DATA in place. This is where standards in BP models would be a huge help in the technology sector, and it in turn would help customers open up their choices. This change will take years... Until that happens, I suspect it will be hard to have an accepted business framework that gets used for generalized infrastructure.
- The user interface and user experience was always secondary in SanFrancisco which led to a gap between customer UI needs and how the FW handled transactions and moving data to clients.
Now, what's interesting is whether SF SHOULD have addressed these gaps. IBM is very good about not competing with their customers...they don't build general software solutions (like Retek, PeopleSoft, Oracle and SAP do), they supply infrastructure. So you have to listen to people about how far "up the stack" you can go...whether SF's "license" was too small to be successful could be an interesting debate...
Originally posted by HS Thomas:
2: A Component Framework for effective OO development
Lesson : Without design patterns it would not have even been possible.
Did any of the SF Patterns survive into J2EE Patterns, or patterns in your book ? Loss of Policy Patterns - any regrets. Business analysts love policies..
regards
[ December 05, 2003: Message edited by: HS Thomas ]
I would, again, suggest you get the SF Design Patterns book. These patterns are definately applicable WITHOUT SF and in a J2EE environment. Some of the "foundation" patterns and constructs are in J2EE (especially with respect to persistence).
Also, IBM still supports SF (I saw they just extended support through 2004) as there are applications deployed with it. Finally, last I knew, IBM did still use an EJB version of the upper tiers in professional service engagements.
I did a patterns tutorial for IBM devWorks before I started at Sun. I did use some of the SF patterns in the tutorial as examples of "moving beyond GoF".
Your last comment is interesting...IBM spent a LOT of time working with domain experts and listening to them about processes and policies. The SF Design Patterns book is SO well written because it talks about WHY these things were necessary....and btw, I think it still comes with SF Version 1.3 :-)