SoftwareSupplyChain

ThoughtStorms Wiki

JonUdell interviewed WardCunningham and JackGreenfield about his work and SoftwareFactories : http://weblog.infoworld.com/udell/2004/11/22.html#a1119

Very interesting discussion (starting around minute 25).

Basically JackGreenfield and WardCunningham are talking about moving up levels of abstraction. What they mean by this is building new layers that "add value" ie. make manipulations of the lower level easier.

Greenfield explicitly points out that this is what always happens as software develops :

problems are solved

good practice becomes noticed and codified (recognised algorithms and patterns)

the patterns get turned into libraries (what Cunningham and Greenfield are calling "frameworks")

and then move into "tools"

Greenfield is pretty explicit that these tools are graphical though he also recognises that they are also languages.

Aside : as one of the TextPeople hoping for TheReturnOfTheCommandLine I'm disappointed. The obvious next move (for me) is for these things to move into the ProgrammingLanguage itself. High level languages now include lists and dictionaries as "native" (ie. with idiomatic ways of refering to them like operator overloading for square bracket notation in PythonLanguage) rather than libraries accessed as generic objects. Why shouldn't the new things that Greenfield is talking about?

The answer is probably because of a paradox raised by Greenfield and Cunningham : as you get more abstract you get more concrete. In other words these higher level patterns they are finding, documenting and making into tools are domain specific In particular, they are focused on the needs of "Enterprise" customers.

So these are "abstract" in one sense (that they are high level) but also "concrete" in the sense that they are relevant to particular situations / locations in the world :

This is, therefore both an answer to DoesAbstractionScale? The answer, no it doesn't, hence the larger systems fall back on to more concrete (world-specific) language. And maybe it makes programming at this level SituatedSoftware? :-)

(I wonder if we can call this process AbstractToConcrete :-)

Greenfield identifies this paradox and points out the problem that the higher level becomes so specific that it squeezes out IndependentSoftwareVendors.

We think that the industry is now at a very interesting juncture. Where, in order to raise the level of abstraction much further ... and therefore to provide much more value, we're going to start getting market footprints that are too small for the traditional model of distribution which has been that platform vendors build out their reusable assets by-and-large and end-users consume them by-and-large with help from SIs and ocassionally ISVs'

...

'And when one looks at ... industries that are mature, one tends to see that this issue has been dealt with through the formation of a structure called a "SupplyChain". Supply chains are a natural phenomenon that arise when you have complex products that essentially are developed using assemblies and sub-assemblies which in themselves are complex and domains of expertise. And you end up with differentiation of roles across a supply chain where you have some folks who are building things from first principles, some folks who are assembling things into assemblies and sub-assemblies, some folks who are branding product and essentially assembling finished product from those parts, and then other folks who's job is focussed on distribution, customization, delivery, installation and so on.

So our initial thinking here was well let's see if we can find a way to accelerate this process of going from gaining experience, building patterns, building a framework and then ultimately ending up with tools, and make it happen more quickly. So that instead of taking ten years for the next turn of the crank, it might happen much more rapidly and in a much more unstructured way if you will with much more flowers blooming. *

ProductivityOfKnowledgeWork

ClassWarBetweenProductsAndServices

OnBranding

JonUdell assumes this supply chain will be "woven together" by WebServices. (ServiceOrientedArchitecture)

Greenfield thinks you start with the purpose of your software, but there's a "disconnect" between goals and the pieces available in the framework. So how to find the pieces, connect the pieces with the goal. Greenfield wants a SoftwareFactory to "answer that question" of how you use the pieces to build the goal. That's the idea of a factory.

The interesting thing about a factory is that one tends to have a consumer / supplier relationship between the builder of a factory and a user of a factory.

Maybe the problem is how to capture context ( OnContext and (WarpLink) ReconnectingTheSmallPieces )