1

In a Software Engineering class, we had an assignment to read Parnas' seminal paper on modularization [0]. In this paper, two approaches of dividing a software into modules are discussed:

  1. Traditional Approach: A flow chart is drawn to work out the single processing steps and the program's high-level flow. Then every processing step is turned into a module. This approach doesn't yield very good results.
  2. New Approach: Every design decision will be turned into a module by the means of information hiding. This approach leads to much better results.

My personal interpretation of the term design decision is that the modules are identified as data structures rather than as processing steps of an algorithm. This makes sense, because data structures are much more suitable for information hiding then processing steps of an algorithm. (The information inside a data structure is hidden behind functions, whereas a function only hides more detailed processing steps and no information; the information is actually passed in as arguments.)

Why does the second approach work so much better than the first approach? Here comes my second interpretation: The single processing steps of an algorithm are not replaceable (and thus not reusable), whereas it's possible to convert data structures into other data structures.

And here's my question: Could that be the reason why software development using workflow engines (based on BPMN, for example) never really took off?

My personal experience is that the activities created in such workflows are hardly ever reused, but there often are big data structures passed around all the involved activities, even if most of the activities use only one or two of them.

My question exaggerated: Could we get rid of all those clumsy workflow engines by giving managers Parnas' paper to read?

[0]: On the criteria to be used in decomposing systems into modules (Parnas 1972)

3

Why is the "new" (in 1971) approach better ?

The second approach, which is the one that Parnas recommends, will ensure the principle of separation of concerns.

In other words, identifying design decision that are difficult and likely to change, and encapsulating them in modules will result in a system architecture, that keeps independent things independent. As a consequence, most changes will remain local to a module, which will facilitate maintenance despite having larger code bases.

Nowadays, with object oriented programming and microservices, we even apply this principle several levels further.

Will it kill workflow engines ?

Workflow engines address a very different need and are not to be seen as the implementation of the first approach.

The first approach is based on the algorithmic sequential decomposition of tasks and business processes. This results in modules that inflexibly communicate with each other in a rigid fashion, according to the analysed workflow.

Workflow engines on the contrary implement in a modular way the complex interactions between different systems and actors. By encapsulating these interactions, you can easily change the orchestration.

In addition, it must be said that workflows are not only a technical matter. For example, you will not replace humans with modules when automating an approval workflow, in which several human actors cooperate through different systems and applications for making a business decision.

  • Thank you. I haven't seen any implementations of processes using a workflow engine as you described it. This could be due to the bad understanding the people had that implemented it. Most managers I had to deal with saw workflow engines as a device to enable non-programmers to program. Their notion of programming is mostly about the sequential execution of instructions and some basic branching and loops: Problems that already have been solved with structured programming. – Patrick Bucher Jun 25 '18 at 8:46
  • @PatrickBucher indeed, there's a lot of marketing that tries to let workflow engines look as something graphic without any programming. Maybe there are such great products, but from my own experience, the reality is different. It's like a car engine: everybody knows how it works, but when you need to tune it, you'd better go to a professional. For workflow engines, you still might end up developing some specific business rules enforcement, or some adapters for mapping incompatible message content. – Christophe Jun 25 '18 at 10:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.