EA Corp edition, BPMN 2.0 & business rules?

[PWarren]

Suggested approach for including business rules in EA BPMN 2.0 diagrams?

Looking to initially separate business rules from requirements as the beginning steps towards business rule management.

I see the requirement business rule stereotype, but what about business rule objects and/or as part of activity elements?

Seems to be a lack of detailed information around this in the EA documentation, an ongoing Achilles heel for EA and Sparx...

[RoyC]

Does this help at all?

http://www.sparxsystems.com/enterprise_architect_user_guide/10/domain_based_models/modeling_business_rules.html

[PWarren]

Some what...

Wondering why in EA there is no icon on the BPMN 2.0 palette for creating a business rule activity directly though, since so many other tool vendors now have that. Or making the activity a business rule object.

Problem is there are 19 projects, so potentially 19 business domain models and the client's RA's (combined business and system analyst role) and only two of those have had domain models produced. One of the lead RAs seems reluctant to produce the rest of them.

So I was looking for a workaround, that allows for the separation of business rules from the requirements, along with lower level decision logic for gateways. We are not producing any code, just visual diagrams for capturing As-is and eventually To-be states for COTS applications and systems.

[Graham_Moir]

Could it be that Business Rules are not supported in the Corporate edition?

[PWarren]

I think it is partially supported or available, which is part of my confusion, in the Corp Edition. I see the option in Activity, type, to create it as a business rule. It is also possible, when gathering and defining requirements, to further define a specific requirement as stereotype business rule. Yet, EA has not, that I know of created any support documentation; How-Tos, tutorials, etc., in regards to using BRs in BPMN 2.0, which for our purposes and projects we need to incorporate them and define relationships to other 'objects'.

Other tool vendors have, and each one uses a slightly different approach so it is important to learn that to use the modeling approach for that particular vendor and tool. It is not enough to just understand or known the BPMN 2.0 standard.

Guess I'll just need to discover it on my own, and write "The Missing Manual for Enterprise Architect, BPMN 2.0 and Business Rules"  

That and buy either the Business and Software Engineering edition or the Ultimate edition of Enterprise Architect so I can both introduce and complete this for my current client.

[OpenIT Solutions]

Our solution to this was to do what i think your hinting at. We form a dependency between a BPMN Activity and a Sparx BusinessRule. We then :-

- updated the bpmn quicklinker to include BusinessRules.
- created model searches to report upon the relationship
- created relationship matrix profiles to report upon and maintain the relationship.

But i agree it does feel that Sparx is lacking integration between BPM and Business Rules.

[PWarren]

Thanks for the reply, I'm going to see if that fits our approach too.

I went ahead and bought the Ultimate single license edition, if for nothing more than proving or disproving EA is a good tool for BPMN 2.0 and BRs. I have also installed the BPMN 2.0 add-in to see what in addition to the Corporate install it provides.

After reviewing the above link provided by RoyC, I do see value in producing a business rule database, BUT how to then interact with them is what I will be investigating and building on. Others on the projects feel/think there is little value in producing a domain model for a COTS solution, so I think that approach is for us outdated.

We are NOT designing and building software and code, just ensuring that a COTS solution covers all business needs and identifying gaps where it falls short, including business rules. For the one application I am currently assigned to, a very early initial analysis shows there are very few BRs and most are controlled manually through human experience, knowledge, activities and tasks, and not automation.

As more and more software development companies move away from monolithic predefined solutions and products, i.e. one-size-fits-all, to a Lego building blocks of modules, heavily customizable, it will have an impact on tools such as EA. Will Sparx and EA keep up is the question.

[PWarren]

I also think it worth mentioning that this is for the Electric Utility Industry in the USA, and one specific aspect, Nuclear.

As with most of my contracts, no doubt there will be additional outputs generated from this effort, above and beyond what the client feels they need. For example, a set of core, reference process models that can be reapplied to other clients. Meter to Cash is one example, as it is fairly standard across all utility companies, including American co-ops.

Has anyone here created an enterprise level diagram, one in which you would represent the applications/systems for a specific domain; nuclear? I think this is where a domain model would benefit the client as they are not yet thinking in those higher level view terms.

I need to now review TOGAF, my preferred enterprise architecture approach, and see if a domain package (nuclear) of domain models is valid...