GPCE 2004 - Jack Greenfield Keynote
Once more on this trip I find myself in a conference room watching a keynote speech at an early hour.
This one is being given by Jack Greenfield to the Generative Programming and Component Engineering conference (co-located with OOPSLA).
Jack (as yet) has no blog so here's his "bio" from the www.softwarefactories.com website:
Jack Greenfield is an Architect for Enterprise Frameworks and Tools at Microsoft. He was previously Chief Architect, Practitioner Desktop Group, at Rational Software Corporation, and Founder and CTO of InLine Software Corporation. At NeXT, he developed the Enterprise Objects Framework, now called Apple Web Objects. A well known speaker and writer, he also contributed to UML, J2EE and related OMG and JSP specifications. He holds a B.S. in Physics from George Mason University.
Jack says it's no good asking customers "what do you want?" because they will naturally reply: "Make what I am doing now faster/better/cheaper!" (related via a story of a tractor salesman asking a farmer in the early 20th century what he wanted, to which the farmer replied, horses that worked longer hours for less feed)
According to Jack, customers want to know:
- What types of systems can I build?
- How do I go from requirements to deployment?
- Why are methodologies so ineffective?
- Why are modeling tools so ineffective?
Logically walking through a set of questions regarding methodolgies, Jack is observing for what problems/solutions each is optimized:
- Is Agility the Answer?
- Is Formality the Answer?
The answers are, for various reasons, no.
Many have observed that, in any other industry, success ratios like we regularly obtain in the software industry would be considered not just dismal but a failure of enormous proportions.
Jack says the key is to not only exploit the economy of scale (cheap to build copies 2..n) but to also exploit economies of scope by reusing designs and components while factoring out variabilities. Thus using domain specific process, tools, languages, and contentwe can automate rote and menial tasks.
Software factories are not intended to make developers into drones but rather to create tools to deal with the things which machines do exceedingly well and free developers to focus on the creative and abstract reasoning which is machines, for all practical purposes, cannot do at all.
"One is most agile when working Domain Specific Tools and Languages"
What all this does is point towards raising the level of abstraction. For example, a web service is really a concept, held in the mind and actually represented by 7 different files, all of which need to be touched do so something simple such as changing the name of the service. In many cases it is desirable to manipulate these concepts directly using a DSL which abstracts the actual manipulations.
A Software Factory Schema is a graph of interrelated viewpoints which range from business capabilities to services to physical networks and systems to code/code-like artifacts to documentation to tools to deployment units.
A viewpoint is "where you stand" and a view is "what you see".
One then goes from a Software Factory Schema, which is "like a recipe for a specific class of systems" to a Software Factory Template which is a set of artifacts like solution templates, project templates, patterns, dynamic help, workflow, policies, reports, groups & permissions and criteria.
The net result is an "IDE which is dynamically configured to build a specific line of products" (aka a Software Factory).
These factories are not design-first/code-later but rather a network of gradually unfolding artifacts, templates and recipes which can be done and undone, as necessary, in a very aglie way.
The net result of Software Factories is, hopefully, to stimulate the development of Software Supply Chains by partitioning factories either horizontally or vertically. In a horizontally partitioned factory one can either outsource development using factories built-in house or use factories supplied by an outside vendor to build systems in-house. In a vertically partitioned factory, one purchases components from upstream suppliers, sells components to downstream suppliers and creates a B2B relationship when components are exposed as services.
(And so, we once again come to the end of a presentation in which a very smart person tries to communicate to other very smart people things which are difficult to explain. It's still amazing to me (and I've experienced this myself more time than I can count) how it's often more difficult to communicate the power of an abstract software concept/product/solution than it is to conceive it or build it!!)
Bottom line: Software Factories can consolidate knowledge, increase productivity and predictability while simultaneously reducing cost and risk across distributed networks of interdependent groups of companies.