Sparx Systems Forum
Enterprise Architect => Uml Process => Topic started by: Paolo F Cantoni on September 20, 2015, 01:00:21 pm
-
We're embarking on a process to create a unified modelling environment for Business Level Architecture (using ArchiMate with extensions), down to physical modelling of real artifacts.
In business modelling, there's a change-over from ArchiMate to BPMN (for example as mentioned and documented in: : Mastering ArchiMate Edition II by Gerben Wierda).
However, when looking at more technical detailed design, we can describe detailed program flow using UML activity diagrams etc. The EA help file has a section: Comparison of UML Activities and BPMN Processes which seems to say that you can render any UML Activity diagram in BPMN, but not necessarily in the other direction. That's my understanding.
Has anyone used BPMN diagrams for detailed program or computing process (as opposed to business process design)?
If so, can you share your experiences?
Any "traps for young players"?
TIA,
Paolo
-
Paolo,
I've seen it in practice (overly detailed BPMN diagrams) and I found in that case BPMN was nut used anymore for BPM, but for functional modelling. Something which I think is still better done with use cases.
Recently I've seen a lot of companies that use a combination of Archimate (architecture), BPMN (business processes) and UML (functional and technical analysis), and it seems to work pretty good.
Each of those fields is usually analysed by a different profile, and each of these profiles seems to feel right at home with their respective modeling language.
Geert
-
Paolo,
I've seen it in practice (overly detailed BPMN diagrams) and I found in that case BPMN was nut used anymore for BPM, but for functional modelling. Something which I think is still better done with use cases.
Recently I've seen a lot of companies that use a combination of Archimate (architecture), BPMN (business processes) and UML (functional and technical analysis), and it seems to work pretty good.
Each of those fields is usually analysed by a different profile, and each of these profiles seems to feel right at home with their respective modeling language.
Geert
Thanks for that Geert,
I guess my question wasn't as wide as your answer. My question specifically, was: if you're using a UML Activity diagram, is there any problem with replacing it with a (as) semantically equivalent (as possible) BPMN Process diagram. I'm thinking that I can use a specific subset of BPMN for expressing the same semantics of the UML it's replacing.
In our situation, we're not trying ot use 3 different modelling methodologies, but trying to create a more unified holistic methodology that "dips its lid" to the originating methodologies.
I agree with you on Use Cases - that woudl be an example where we might extend our unified methodology to include the concept.
Paolo
-
I have successfully used simple BPMN diagrams to enhance use case scenario descriptions. It's easily possible to use BPMN as replacement for ADs and to use additional features offer by BPMN by and by.
q.
-
My preference is to have a jumping off point, where the modelling switches from BPMN down to UML (Use Case).
For example, on the BPMN diagram you have an Activity "Purchasing Clerk Creates Purchase Order" which is linked by a message to the "Purchasing System" lane, and an Object called "Purchase Order".
Any occurrence of a Human interfacing with a System is potential for a Use Case.
If you BPMN diagram has activities like (Add Line to Purchase Order) I'd suggest that it has gone down too low into the weeds.
I can see reasons why someone would like to create that kind of duplication across different modelling paradigms, but I'd prefer not to.
Andy
-
My preference is to have a jumping off point, where the modelling switches from BPMN down to UML (Use Case)
I'm with AndyJ on this one.
Geert
-
My preference is to have a jumping off point, where the modelling switches from BPMN down to UML (Use Case).
[SNIP]
I can see reasons why someone would like to create that kind of duplication across different modelling paradigms, but I'd prefer not to.
Andy
Hi Andy and Geert,
Duplication is EXACTLY what I'm trying to avoid. :D I previously had to do that - trying to join ArchiMate and ISO11179 - that sucked! This time around, I'm able to create a new MDG that allows me to mix and cross-over much more naturally.
Paolo
-
My experience is that BPMN is better than Activity diagrams for being able to estimate effort and cost for things like security reviews. People are also more likely to assume that an activity diagram is a flowchart.
-
My experience is that BPMN is better than Activity diagrams for being able to estimate effort and cost for things like security reviews. People are also more likely to assume that an activity diagram is a flowchart.
While I agree that UML Activity diagrams are more like flow charts than BPMN diagrams. Indeed, I often describe them to lay people as "flowcharts on steroids", I'm not clear what caused you to make that observation. What is the impact of "lay" persons seeing activity diagrams as flow charts?
Paolo
-
]While I agree that UML Activity diagrams are more like flow charts than BPMN diagrams. Indeed, I often describe them to lay people as "flowcharts on steroids", I'm not clear what caused you to make that observation. What is the impact of "lay" persons seeing activity diagrams as flow charts?
Well if you end up with a page containing only actions and decisions there was no point doing an activity diagram :-)
-
]While I agree that UML Activity diagrams are more like flow charts than BPMN diagrams. Indeed, I often describe them to lay people as "flowcharts on steroids", I'm not clear what caused you to make that observation. What is the impact of "lay" persons seeing activity diagrams as flow charts?
Well if you end up with a page containing only actions and decisions there was no point doing an activity diagram :-)
Must be "thick" this morning (on bus on way to work), don't really see how your statement is related to your point re Activity Diagram vs Flow Chart.
Paolo
-
]While I agree that UML Activity diagrams are more like flow charts than BPMN diagrams. Indeed, I often describe them to lay people as "flowcharts on steroids", I'm not clear what caused you to make that observation. What is the impact of "lay" persons seeing activity diagrams as flow charts?
Well if you end up with a page containing only actions and decisions there was no point doing an activity diagram :-)
Must be "thick" this morning (on bus on way to work), don't really see how your statement is related to your point re Activity Diagram vs Flow Chart.
Paolo
My point is that Activity diagrams can carry a richer set of information than flow charts, for example what information artifacts (objects) are created and where they are stored. This is useful information for things like security and compliance activities.
But it's a complete waste of everyone's time if your AD is really only a flow chart because all you're sowing is processes and decisions. You haven't gained anything for the organisation by attempting to introduce a UML diagram type.
-
My point is that Activity diagrams can carry a richer set of information than flow charts, for example what information artifacts (objects) are created and where they are stored. This is useful information for things like security and compliance activities.
But it's a complete waste of everyone's time if your AD is really only a flow chart because all you're sowing is processes and decisions. You haven't gained anything for the organisation by attempting to introduce a UML diagram type.
I would say there is a place for simple diagrams - visual modelling is about managing complexity and simple diagrams can help in that - but that you should avoid simplistic diagrams. If an activity diagram is part of a rich behavioural model, it can be as simple as you like without being simplistic.
-
But it's a complete waste of everyone's time if your AD is really only a flow chart because all you're sowing is processes and decisions. You haven't gained anything for the organisation by attempting to introduce a UML diagram type.
Well, you improved marketing. And that's what marketing guys care for: not the product, but the marketing of the product. :P
But honestly I also used this marketing technique sometimes. A graphical representation of even simple scenarios often brings a different light on things.
q.
-
r simple diagrams - visual modelling is about managing complexity and simple diagrams can help in that - but that you should avoid simplistic diagrams. If an activity diagram is part of a rich behavioural model, it can be as simple as you like without being simplistic.
One of the things that contributes to the failure of architecture in a organisation is constantly introducing the business users to new methodologies or practices. It creates a type of exhaustion.
So it's counter productive to show a UML activity diagram and explain how they work when you're showing nothing more than a flow chart with different notation. Pretty much everyone you'll come across already knows the notation for a flow chart.
EA does flow charts - draw a flow chart.
-
One of the things that contributes to the failure of architecture in a organisation is constantly introducing the business users to new methodologies or practices. It creates a type of exhaustion.
So it's counter productive to show a UML activity diagram and explain how they work when you're showing nothing more than a flow chart with different notation. Pretty much everyone you'll come across already knows the notation for a flow chart.
EA does flow charts - draw a flow chart.
Ahh... Now there's a profound statement... (Not taking the p..s... I REALLY mean it!)
We've taken the view that we need a normative model which is properly specified (using some of the ideas I've been "rabbiting on about" around here) and a communicative model which is used to provide a simpler view of some aspects of the normative model. There are reference back to the normative model so that the communicative model doesn't get "too far out of whack" with the normative model.
The business craves (illusory) simplicity. In fact, the Einsteinian dictum applies: "Keep things as simple as possible, but no simpler.".
In the past, I've observed:
"A picture is worth a thousand words, until it has more than 6 shapes and 12 lines - after which ALL bets are off!"
"Executives can handle direct data query until they need to join two tables"
We (as Architects) have to find ways to get around this semantic impedance problem.
We are looking into ways to manage the process of creating compatible and simplified diagrams which track the evolution of the normative model. Wish us luck! ;D
Paolo
-
I think the mistake is in thinking that other people need to see our normative model.
What if our tooling could take our beautiful normative models and render them as something else. i.e. you draw an activity diagram but import a flow chart into your PowerPoint.
-
I think the mistake is in thinking that other people need to see our normative model.
What if our tooling could take our beautiful normative models and render them as something else. i.e. you draw an activity diagram but import a flow chart into your PowerPoint.
Yes, that's the conclusion I've come to. Hence what we're going to be experimenting with.
We can build a self-consistent normative model (at varying levels of detail and scope), but providing our communicative model is consistent with that, we can use it to better communicate with non-modellers.
In addition, I believe if we can show that the traceability is there, business people will be more receptive since they will know that (like Google Earth) the closer you get to the ground what you see will still be consistent with what you are seeing from 10 Km up.
Paolo
-
As I general rule I like to only show people the "moving parts" they interact with. On occasions I have run sessions with two different groups of business users to explain how one set of moving parts interacts with another.
-
What I particularly like about using BPMN in EA, is to be able to do the high level process, which you can give to execs and users, and drill down to the minutiae, which the developers need.
I've built a script which also writes the "Steps" part of a use-case directly from a BPMN diagram (unless you have very complex processes), which I hope to publish at some point, since you can't do enough complexity in the scenarios within EA.
-
What I particularly like about using BPMN in EA, is to be able to do the high level process, which you can give to execs and users, and drill down to the minutiae, which the developers need.
I worked on a project that was implementing a piece of legislation. We understood the desired outcome and the hard dates involved but we had no idea of the numbers of affected citizens. It was obvious that existing processes in the extant system would be affected but not replaced. A previous project had failed catastrophically because the needed business processes weren't all well understood.
We started a journey with Sparx EA and BPMN that went from the high-level processes to very specific detail of individual processes. This was then exported out to an Intranet and used by the staff to perform a "mantronic" process where demand was very low, and the developers used it to code the new high demand processes into the system.
It was nice to be able to answer questions from management by pointing at the appropriate layer and saying "that".