Christopher Spottiswoode comments from a Metaset/MACK point of view
(on Haim Kilov and I.D. Simmonds, Business patterns: reusable abstract constructs for business specification):

(Please first read my Introduction to these comments on your papers.)

In the absence of the paper I couldn’t deduce much, but I did like to find - amid your few words - this fragment: "information gathering" and "joint ownership." While they are of course mainstream A&D and CASE notions, I enjoyed finding them spotlighted there. Cf. these few quotes from my own materials:

• From the introduction to my faq: "[Metaset] was, after all, designed to help people simplify complexity together -- that being the main and recurrent theme in the paper and in the questions below."
• Under question 11 of the faq: "One of the reasons for developing Metaset in the first place was to host the airing of complex issues and the cultivation of simple consensual outcomes."
• The word "Consensus" (consensus promoting joint ownership) was even on the cover of my 1986 book (advertised at the end of question 2 of the faq).

Your paragraph I’ve just quoted opened with this: The motivation for our work is to allow the production of complete, rigorous business specifications understandable by both business users and system developers. These specifications require rigorous expressions of semantics -- that is, assertions -- rather than loose, "intuitive," descriptions.

You have there very well motivated the MACK "typology" (see [5, 6, 7]), and - for that understandability - the "MVC-like" function producing typology representations for every kind of user’s own contexts (Find the phrase "your way of seeing things" in the faq).

Your "information gathering" and "joint ownership" specification fragments obviously have equivalents in some of Metaset’s market-related typologies: see e.g. "POP" in [Paul] and "buying typologies" [7].

I can also put that specification problem in the context of the burgeoning integration between run-time and A&D-time of which my 1976 IDIOM ("Interpretable Design for Integrated Operation and Management" - see [3]) was an early precursor, and which was emphasized in this Unisys quote in my paper: "A number of customers now view workflow as the driving technology that is used to control all business processes (one of which happens to be software development!) in an enterprise."

That closer integration was also implicit in Jeff’s summary of last year’s Workshop, where he called for a tighter "coupling between analysis, design, and implementation".

Such designtime/runtime integration is of course most appropriate to Tom Peters’ "Nanosecond Nineties" and the high-velocity market that JIT has presaged and the Web is starting to enable far more widely! Metaset will enable it in the software component market, both from an architectural and an infrastructural point of view.

Then your final sentence in that paragraph was: Unlike typical programming constructs, instantiations of business patterns are inherently interactive and so must adapt to their changing environment. Such refinement or variation, as well as more radical mutation, is intrinsic both to MACK itself and to the operation of the market that MACK is designed to boost. And there will be relatively few such typical programming constructs remaining which are not transparent to their users (Those are the RE-methods).

Further, well, your description makes you seem just as confident of your work as I seem to be of MACK! If your architecture is as simple, and the implementation more ready than Metaset, then maybe I should use your product instead? I have always insisted that I wanted Metaset merely in order to use it, and not because I really wanted to develop it.

Difficult to believe? See question 8 of the faq, where I explain the abbreviation "mt", and question 11, where I explain how I saw my own central involvement being reduced to a minimum non-delegatable residue. Throughout my written materials you can see how my excitement centres around the use of the infrastructure and the consequent benefits (which also imply great income-earning potential in their use by anyone). You can also deduce how I have been forced back into programming because it has seemed to be a necessary precondition for that future that seems so possible despite all the Scyllas and Charybdians of existing technology who cannot progress through the straits.

So please can I take you up on your offer of references?

(P.S. I have subsequently read Jeff’s minutes of your Hyannis contributions, which seem to indicate that your team is in fact very far behind Metaset. What a disappointment for me! And I mean that. If that still seems implausible, see also the "my own phasing out" bit in the "Strategy" section in my introduction to these comments.)