4 ms·

In a sense yes, although I suggest that a "business process" is too broad and difficult an abstraction. Better for most [1] systems in industry and commerce to

In a sense yes, although I suggest that a "business process" is too broad and difficult an abstraction. Better for most [1] systems in industry and commerce to elicit and model sequences of recorded events [2] involving interactions with things, people and places in different contexts, with support for constraints [3]. Modeling the above in a business sense, with support in existing paradigms and languages is already a solved problem, just a little known one. --- [1] The other type of system in industry and commerce being the continuous system that isn't based on recorded events, but instead on logging errors and abnormal circumstances, e.g. an elevator control system or an automated warehouse delivery system, or the engine monitoring software in your car. [2] Recorded for business or legal reasons. [3] It's those constraints that prevent an elevator from moving with its doors open, or billing for that product not shipped, or allowing someone to vote twice.

Myrmornis 9y ago
I’m not sure I understand everything you said there. Software engineers are often tasked with designing and implementing “business processes”, just as they are tasked with implementing correct logic in a concurrent threaded program, or system of microservices. Don’t you feel that when they step up to the whiteboard and draw yet another completely ad-hoc diagram, for any of the above problems, with no agreed rules of composition or semantics, that these people, who often have degrees in computer science and mathematics, are basically communicating using cave paintings?
- aryehof 9y ago
  There are some that can walk up to a white-board and (repeatedly and predictably) create a domain object model representing complex business requirements. One directly convertible to code. They can do this because they know a set of higher order patterns, beyond just a knowledge of "objects" and "classes". Beyond just a design approach of identifying classes as the "nouns" in a problem domain. These higher order patterns represent those business processes, as you call them. Sadly such a skill is very rarely seen, or even in demand, given that data modeling is the basis for most design today.
  - Myrmornis 9y ago
    OK, so that covers data modeling, and I agree with you that that is a rare and yet critical skill. But if I'm envisioning correctly the talents that you're describing, that still leaves a large amount of concurrent/asynchronous logic undescribed/undesigned. I expect you know what I mean; maybe a jumble of words like "multiple superimposed event-driven parallel state-machines" gives the idea. You mention a "domain object model". Are you talking about diagrams that capture much of the dynamics/asynchronous behavior that I described (in which case, where can I learn about such a diagramming language?) or is it more restricted to the nouns?
    - aryehof 9y ago
      I am talking about a domain model of the problem under consideration. That model is the same thing from analysis/design to code. It is independent of technical concerns and plumbing. Independent of a particular interface or mechanism for persistence. I'm talking about using standard programming language features, rather than yet another (diagrammatic) language that requires translation to executable code. Those technical concerns are dependent on the non-functional requirements of the particular required solution. This includes aspects of concurrency. I suspect your interested in a "framework" that supports both problem domain modeling and specific technical circumstances?
dragonwriter 9y ago
The distinction you draw is unnecessary; both types of systems deal with planned responses to events, and both have to deal with out-of-spec inputs. And while them recognition of planned response to events as the unifying abstraction for system analysis is not new (it's at the heart of the structured analysis/design approaches of the 1960s and 1970s which, while displaced somewhat by object-oriented analysis and design, are echoed in more recent tools and technologies like BPMN and Flow-Based Programming, though the analytical methods haven't come back as much as the tools have.) But, no, modelling for both validation by domain experts who are not computing experts and implementation by developers who are not domain experts is not a solved problem in the general case. I do agree that a lot that has been learned that is useful in finding adequate solutions to that in specific cases is not as widely known as it should be.

Myrmornis 9y ago

I’m not sure I understand everything you said there. Software engineers are often tasked with designing and implementing “business processes”, just as they are tasked with implementing correct logic in a concurrent threaded program, or system of microservices. Don’t you feel that when they step up to the whiteboard and draw yet another completely ad-hoc diagram, for any of the above problems, with no agreed rules of composition or semantics, that these people, who often have degrees in computer science and mathematics, are basically communicating using cave paintings?

aryehof 9y ago
There are some that can walk up to a white-board and (repeatedly and predictably) create a domain object model representing complex business requirements. One directly convertible to code. They can do this because they know a set of higher order patterns, beyond just a knowledge of "objects" and "classes". Beyond just a design approach of identifying classes as the "nouns" in a problem domain. These higher order patterns represent those business processes, as you call them. Sadly such a skill is very rarely seen, or even in demand, given that data modeling is the basis for most design today.
- Myrmornis 9y ago
  OK, so that covers data modeling, and I agree with you that that is a rare and yet critical skill. But if I'm envisioning correctly the talents that you're describing, that still leaves a large amount of concurrent/asynchronous logic undescribed/undesigned. I expect you know what I mean; maybe a jumble of words like "multiple superimposed event-driven parallel state-machines" gives the idea. You mention a "domain object model". Are you talking about diagrams that capture much of the dynamics/asynchronous behavior that I described (in which case, where can I learn about such a diagramming language?) or is it more restricted to the nouns?
  - aryehof 9y ago
    I am talking about a domain model of the problem under consideration. That model is the same thing from analysis/design to code. It is independent of technical concerns and plumbing. Independent of a particular interface or mechanism for persistence. I'm talking about using standard programming language features, rather than yet another (diagrammatic) language that requires translation to executable code. Those technical concerns are dependent on the non-functional requirements of the particular required solution. This includes aspects of concurrency. I suspect your interested in a "framework" that supports both problem domain modeling and specific technical circumstances?

dragonwriter 9y ago

The distinction you draw is unnecessary; both types of systems deal with planned responses to events, and both have to deal with out-of-spec inputs. And while them recognition of planned response to events as the unifying abstraction for system analysis is not new (it's at the heart of the structured analysis/design approaches of the 1960s and 1970s which, while displaced somewhat by object-oriented analysis and design, are echoed in more recent tools and technologies like BPMN and Flow-Based Programming, though the analytical methods haven't come back as much as the tools have.) But, no, modelling for both validation by domain experts who are not computing experts and implementation by developers who are not domain experts is not a solved problem in the general case. I do agree that a lot that has been learned that is useful in finding adequate solutions to that in specific cases is not as widely known as it should be.