Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: avi10000 on April 21, 2023, 07:51:52 am
-
Hi all,
What other business languages does EA offer apart from BPMN, but with similar characteristics to BPMN?
I am having problems with BPMN's visual capabilities. (See Bugs area about centering text.)
The other business language must not have these problems.
Further requirement, the business language's activity elements must be rectangular with rounded corners.
(Otherwise I am going back to Visio.)
Desperate...
Thanks
Avi
-
In the Business Modeling perspective you'll find quite a list, but they are largely complimentary. I would also add ArchiMate..If you're rejecting BPMN because you don't like the resize behavior you will have gaps in what you can effectively express.
-
UML is the easiest and most effective business language.
Fight me.
-
There's nothing wrong with Visio if you like to draw things. That's a popular way of representing things. (Un)fortunately it's copletely free of any formalism. See if that fits you.
q.
-
Hi Richard,
Thanks for the response.
Do you mean to use UML Activity Diagrams?
Indeed I was thinking of that. But I wanted to be "professional" and use a language that is targeted for business processes.
(Btw, I guess that using a different tool for BPMN e.g., Eclipse UML, might not have text problem (but could have different problems.
Btw #2, I will have to use act diag actions rather than activities, because activities do not let you legally connect them with control flows for some reason. And apparently that is the correct practice according to the UML spec.)
Also occurred to me that UML activity diagrams offer the streaming feature, i.e., outputs partial results to share with concurrent activities. This is very useful to me. (BPMN does not offer streaming, AFAIR.)
Now you said it, I think I will take you up on it.
Cheers ! :)
Avi
UML is the easiest and most effective business language.
-
For the record: I think BPMN is one the best MDG available in EA.
It allows me to create nice professional process definitions. I haven't encountered the resizing issue you are talking about and I'm wondering why?
Do you have like really long names for your Activities?
Anyway, it feels like a the resizing issue is a minor cosmetic issue. Deciding to use another language allthogether because of this feels like "throwing away the baby with the bathwater"
On the other hand, if you are trying to model streaming features, and partial results to concurrent activities, you might not be modelling business processes after all but much more technical system processes.
In that case, UML Activity diagrams might be better suited. (and yes, you don't put Activities on an Activity Diagram)
Geert
-
Hi Richard,
Thanks for the response.
Do you mean to use UML Activity Diagrams?
Indeed I was thinking of that. But I wanted to be "professional" and use a language that is targeted for business processes.
(Btw, I guess that using a different tool for BPMN e.g., Eclipse UML, might not have text problem (but could have different problems.
Btw #2, I will have to use act diag actions rather than activities, because activities do not let you legally connect them with control flows for some reason. And apparently that is the correct practice according to the UML spec.)
Also occurred to me that UML activity diagrams offer the streaming feature, i.e., outputs partial results to share with concurrent activities. This is very useful to me. (BPMN does not offer streaming, AFAIR.)
Now you said it, I think I will take you up on it.
Cheers ! :)
Avi
UML is the easiest and most effective business language.
For requirement modeling, use case diagrams
For business process modeling, attach any number of sequence diagrams to the use case. Avoid activity diagrams unless you are describing procedural code (for example a class method at logical / physical level)
For data modeling, use the classes generated by the sequence diagrams to define domain object models and ERDs (database data models) at logical or physical level
For system architecture, use component diagrams. The residents of the components are classes and database objects from the DOM / ERDs
For system infrastructure, use deployment diagrams whose artifacts are the components of the component diagrams at physical level
You have a full system architecture with traceability from user requirements to deployed systems and back. You can change anything in any of above steps (requirements, users, classes, components, nodes) and quickly propagate the change to all other levels.
(BPMN and activity diagrams are not object oriented so they don't really fit into the architecture)
It takes experience to get it right but that's why all architects have white hair in their head
-
For business process modeling, attach any number of sequence diagrams to the use case. Avoid activity diagrams unless you are describing procedural code (for example a class method at logical / physical level)
Hi Richard,
You seem to have a rather software centric view on things.
When we model business processes, we often don't even want to consider software, or systems.
A Use Case is a group of functionality that is to be automated (i.e. software), but business processes exist even without automation. (e.g. phone calls, paper documents, et...)
And frankly, if I wanted to validate my business process with the business, they would shoo me out of their office if I came to them with sequence diagrams.
Sequence diagrams are a very technical type of diagram, and are hard to understand by non-technical users.
Flow charts on the other hand is something they know and understand. BPMN looks a lot like flowcharts, so that tends to go a lot better.
Your remark about BPMN and Activity diagrams being not object oriented illustrates my point about the software centric view.
I can understand that your approach works for your environment, but modelling if often done for a much broader scope than just the software or systems.
Geert
-
I'm with Geert. Though I never user BPMN purely I borrowed a couple of elements to put them in a specific profile. Basically AD's are used to communicate with business people which works well. However, adding a bit of sugar (after talking with some of them) makes things even flow better. The less you use the better.
q.
-
Hi qyerty,
> The less you use the better.
Do you mean the less different types of elements you use the better?
I'm with Geert. Though I never user BPMN purely I borrowed a couple of elements to put them in a specific profile. Basically AD's are used to communicate with business people which works well. However, adding a bit of sugar (after talking with some of them) makes things even flow better. The less you use the better.
q.
-
Yes. BPMN has an overwhelming set of elements. Using (too) many of them will not light up but confuse the (usually BPMM-unskilled) readers. So KISS is a good principle here (like so often).
q.
-
Why not stick to ArchiMate?
For me, the set of Business elements provided is sufficient for the business processes I describe (Process, Event, Junction cover more than 80%).
And it has the benefit of relating business elements to application elements.
In my opinion, each business process step is supported by 0, 1 or more application services which in turn can use other services or interfaces to deliver the required functionality.
-
Thanks
Yes. BPMN has an overwhelming set of elements. Using (too) many of them will not light up but confuse the (usually BPMM-unskilled) readers. So KISS is a good principle here (like so often).
q.
-
ArchiMate also offers a business process notation?
Why not stick to ArchiMate?
For me, the set of Business elements provided is sufficient for the business processes I describe (Process, Event, Junction cover more than 80%).
And it has the benefit of relating business elements to application elements.
In my opinion, each business process step is supported by 0, 1 or more application services which in turn can use other services or interfaces to deliver the required functionality.
-
ArchiMate also offers a business process notation?
Only rudimentary compared to BPMN. I always combine ArchiMate with BPMN, i.e use ArchiMate to specify the business processes and then use BPMN to describe it.
Henrik
-
For business process modeling, attach any number of sequence diagrams to the use case. Avoid activity diagrams unless you are describing procedural code (for example a class method at logical / physical level)
Hi Richard,
You seem to have a rather software centric view on things.
When we model business processes, we often don't even want to consider software, or systems.
A Use Case is a group of functionality that is to be automated (i.e. software), but business processes exist even without automation. (e.g. phone calls, paper documents, et...)
And frankly, if I wanted to validate my business process with the business, they would shoo me out of their office if I came to them with sequence diagrams.
Sequence diagrams are a very technical type of diagram, and are hard to understand by non-technical users.
Flow charts on the other hand is something they know and understand. BPMN looks a lot like flowcharts, so that tends to go a lot better.
Your remark about BPMN and Activity diagrams being not object oriented illustrates my point about the software centric view.
I can understand that your approach works for your environment, but modelling if often done for a much broader scope than just the software or systems.
Geert
Not so Geert Sir.
I've never worked in software development. My work is in Supply Chain - building new factories, moving logistics centers etc. I work with procurement managers, manufacturing managers, development managers, site managers and local government agencies.
I always use UML (as described in above post) to coordinate business process, contractual agreements and system changes between these parties. I start my workshops with 15 minutes training on the diagrams of the day (use case, sequence, class, component). The simple reason is that other languages (flowcharts, IDEF etc.) don't do the job.
Case in point: can you think about integrating the roles/responsibilities, contractual agreements and system data exchanges needed to support the R&R and contractual obligations between the Chongqing finance bureau and a german logistics service provider? Based on a few flowcharts from each? Good luck. But a good round of use cases with (1) actor definition, (2) sequence diagrams integrating the roles from each party, (3) how they exchange information to perform the contractual obligations, and (4) a class diagram (logical level) built from the sequence diagram did the job and ended up as attachment to the signed contract. This is just one of dozens of examples in my experience. (ps all done in Sparx EA! Yay!)
One of the sad reasons why UML failed is because big industry players pushed it as a programming language which never made sense (but it looked good in the management brochures). They were hoping to make money selling CASE tools that could generate better code than a guy sitting in front of a text editor. That never worked out (maybe 20 years from now with AI... possibly).
UML is great for talking to people with different backgrounds and integrating process-data-systems in a single model that can be changed easily. The big consultants are pushing flowchart-like languages for the simple reason that they can easily generate hundreds of powerpoints for the customers and bill lots of hours (been there, done that). These flowcharts are better than nothing but vastly inferior to a decent UML model.
The books, videos and talks about UML as a business modeling tool are out there: it works fine for me. If you are interested you can google my name + UML: you'll find a few invited talks at The Open Group and Data Modeling Zone.
Anyways, I'm for whatever works for you: my point is that there is always a better way to skin the cat.