Apr 222014

P1010513I have been playing with the idea of a very generic process core. It is sufficiently abstract to not be useful on its own, but only as a pattern for building content. I think there may be a small handful of these generic patterns. I am still considering how many other patterns I need, and whether the whole concept is useful in the wider world outside of my head.

Pattern One

  • Select data
  • Set criteria
  • Analyse data
  • Associate results
  • Present results

That doesn’t sound like much, but when I look for a method to automate the review of individual requirements statements against measurable criteria, I get this.

  • Select requirements for review
  • Set analysis criteria
  • Analyse requirements against criteria
  • Associate results of analysis with requirements
  • Present results

This is far more useful, now we can look at the process for automated parsing of requirements statements.  The criteria could include a list of ‘bad’ words (and, but, maybe, if, approximately…), a list of stakeholders (one MUST be present in each stakeholder requirement), a mandatory structure (<stakeholder> shall be able to <goal> <qualifier>) and other criteria. As each statement is analysed, the result of the analysis is associated with the requirement (more than one implementation is possible here). The results of the analysis of individual requirements and the results of the group (12% have no stakeholder, 2% are missing a ‘shall’, 34% have a ‘bad’ word, etc) are then presented back to the user.

Now if we consider testing.

  • Select items under test
  • Set analysis (test) criteria
  • Test against criteria
  • Associate results of test
  • Present results

Here we are selecting requirements or test statements. The test plan will have some pass/fail criteria. The test is carried out, and the results stored and related to the requirements. The test report is presented to a human user.

I think this is the most basic form of process pattern, it contains no user corrective action, there is no feedback loop. It does not mention any transfer between tools or data stores when, for instance, the data is selected from one place and analysed in another; that is implementation specific.  There is no mention of the nature of the presentation of the results, on screen, on paper, as a table, as text, as a diagram; again that is implementation specific.

This pattern is likely to be an inner loop for a more complicated process, and is part of a small set of similar repeating patterns. I am looking at this because I am working on identifying some common core of process that is valid across industries. I wanted a very simple pattern to use so that I am not tempted into domain specific language. I expect to find more of this small set of process patterns, but I am not sure that I will ever surface it in the work I am doing, it is part of how I am building generic process, and should make the result more easily consumable because it will have a familiarity that comes from repetition.

Am I reinventing the wheel here? Is there a well defined set of underlying universal process patterns from which we can build useful and increasingly specific processes? It seems to me to be so deeply buried, and so abstract, that it is either widely known, or never considered.


  2 Responses to “A universal process pattern; can an extreme example of abstraction still be useful?”

  1. I don’t know the answer to your question, but I enjoy the thought pattern associated with it! 🙂

  2. I actually created Universal Process Architecture about a decade ago as a result of a recursion problem in creation of the UNCefact Business Process Catalogue Please feel free to contact me Brian Leapman

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: