CF
I am trying to formulate a strategy that uses EPC to represent high-level business processes and have process steps eventually decompose to executable actions in any type of system, not just SAP or ARIBA. I think BPMN is the way to transition the business content to the actual system requirements for execution, but I am not experienced in using BPMN.
Is this a good way to bring the story from what the business needs to do, to what the systems should be able to perform? If so, can anyone recommend a way to do this by sharing some simple documentation? I need a way to show "soup to nuts" in a way that will translate to both business and IT. (My background is business and not IT, by the way, although I am a BPM professional.)
Thank you in advance for any assistance and/or suggestions.
I highly discourage you using two different notations without a need.
Using 2 or more notations you loose
- reusability of already designed flows
- automated holistic, coherence checks
- implicit update of all diagrams influenced if you alter something
As a result you have to
- redraw already designed flows in a different notation to further refine them
- check the coherence of the interface of 2 models manually
- check manually if a change in one model influences other models
All three tasks a computer performs much better, than a human.
Consequently I suggest you
- to use the notation that reflects your way of thinking,
- to use only one notation and
- to respect the 7+-2 principle (http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two) on management level presentations.
Hello Carolyn,
while Carsten Pitz' considerations are all valid, I need to object. In fact we do recommend to use EPC as the notation most adequate for the business people. But if you want to use your business process definitions to define requirements and specifications for IT initiatives to automate those processes, ARIS supports you in that with the webmethods extension pack.
- You generate BPMN models from your EPCs, and enrich them with more detail such as the type of function ("task" in BPMN terms). This is what we call the logical level process models
- ARIS supports you in comparing the models for coherence, since the objects in BPMN and EPC notation maintain their identity.
- From there you can export those BPMN models into webmethods Designer, where the IT people will connect the tasks to real IT services (of SAP(TM) systems or any other system with an interface), implement user tasks as user interfaces that will run in My Webmethods Server(TM) and thus provide a seemlessly integrated user experience independent of the connected systems. So those are the implementation level processes at the IT level.
- These steps are supported through workflows in the tool so you can trace them.
So, opposed to Carsten Pitz' conclusions my conclusions are:
- you do not need to redraw already designed flows in a different notation. The tool does this for you.
- The tool assists you in ensuring the coherence of the views at EPC level and (BPMN) logical level of detail.
- Integrated workflows will submit changes at the downstream level to the upstream level participants for review. While most details of the IT implementation will not be relevant for the business people, those details relevant to them will be be brought to their attention. E. g. the solution design (logical level) or implementation may discover another (non-technical) prerequisite for a task and ask business to adjust the process model.
- A broad set of semantic checks available in ARIS assist you in ensuring the quality needed to drive such a methodical approach.
We call this method "Model-2-Execute" and it is part of the Software AG PRIME method framework. Even if you do not have webMethods Integration Platform(TM) in your company (yet ;-) ) The combined use of the two notations serves to address their respective target groups: Business and IT.
ARIS helps you to align business and IT and keep them aligned! In the course of this approach you may even discover, what business people really know about their requirements towards the IT systems and specify those in ARIS as well (business objects and their attributes, wireframe models of screens, IT systems (to-be) supporting process steps). All that can become part of the Business Blueprint - as we call it - which is the first step in an automation effort according to the Model-2-Execute scenario. You hand those specifications to the solution designers, which will base their IT designs on the business blueprint. Everything resides in the same ARIS repository and can be kept aligned.
If you need help to make your pitch for Model-2-Execute, feel free to contact Software AG Global Consulting Services.
Regards, M. Zschuckelt
In reply to Hello Carolyn, by M. Zschuckelt
Hello Carolyn,
Hello Mr. Zschuckelt,
I heard of the Model2Execute approach. Work mates of mine used that technology very successfully. As far as I heard, your Model2Execute approach is well crafted. I have not yet used it myself, but have been in contact with my work mates a long time. Learned a lot about Model2Execute. And I as also you, Mr. Zschuckelt I also consider it after re-reflecting your, Carolyn post without much doubt sufficient to cover your, Carolyn current requirements.
But as far as I know it is a MDD (Model Driven Development) approach, MDD approaches are - I am not aware of any exceptions (*) - one direction roads. As a result any changes to the generated BPMN model that influence the EPC source model are not propagated back to the EPC source model.
As long as you respect Model2Execute is a one direction road, everything is perfect. To be more specific, as long as you treat the generated BPMN model read only everything is fine. But as soon as you for example rename some element in the in the generated BPMN model both models are incoherent. Even worse if a new BPMN model gets generated by an EPC model update the your changes in the generated model get overwritten.
In my experience some architects, business analysts, developers, ... forget this restriction if the project is in progress. Some day they start to alter the generated model instead of alter the source model. Well, that is the start event of the chaos occurred. Just to express it in EPC slang.
So better be aware of this restriction all time.
The MDD approach is very powerful. You model high-level and let the generator handle the low-level details. I really, really like the MDD approach. I started to use MDD - let me verify - Nov '04. Ups, that is almost 9 years. Am I growing old?
I consider Model2Execute a good door to enter the world of MDD. And as I wrote before I consider it without much doubt sufficient to cover your current requirements.
But just to give you a vague impression of the vast potential of the MDD approach. Or just why I like MDD.
Actually I use OMG MOF M2T (which is the Object Management Group's Meta Object Facility Model to Text Transformation Language) as MDD technology. This technology is extremely generic, much more generic than Model2Execute and as a result much more complex to use. But you can in principle generate every textual artifact using MOF M2T. This includes but is not limited to BPMN, BPEL, WSDL, Java, C#, C++, Objective C, HTML, SVG, XML FOP, DDL, XML Schema. As a result using MOF M2T you can for example model an GUI (graphical user interface) including validation, workflow, ... and let the generators produce implementations for say Android 4.x, Android 2.x, Apple iOS, Java Swing, Microsoft .NET XAML/C# and a JSF2 based web front end. If a change of the GUI is required you only alter the model. The generators produce all artifacts. Even the user manual on how to use the GUI as HTML + SVG and via XML FOP also PDF is generated. If there is some fault in an implementation fix the generator and regenerate the the code for all your products.
The downsides, first you need different qualifications in your project team. Writing a generator is much more abstract than writing code for a specific user story, a specific set of requirements. You need team members that deal with that level of abstraction, people able to write generators. Furthermore much of the work is done on model level. You need team members able to model rather than people able to code. Your team members also have to be very disciplined, must respect and strictly adhere to the restrictions and rules implied by the MDD approach. As a result you have to hand pick your team members.
Furthermore producing generators is work, a damn lot of work. The generators have to be well designed, the design has to reviewed at least by two independent reviewers, carefully coded,also the code reviewed at least by two independent reviewers, thoroughly tested and documented down to the very detail. Simply because an issue in the generator generates an arbitrary number of issues into the code. A generator is a very critical asset. As I wrote before, a damn lot of work = a damn lot of invest. To make that invest pay off, you need a sufficient amount of code to be generated. That could be a sufficient number of small or medium sized applications or a sufficient complex application.
But once the generators work properly, you
- deliver faster
(with mocks (non-functional dummy business logic) generated by the generator several non-functional prototypes can be generated within a meeting with your customers. Non-functional prototypes give your customer an impression how the application will look&feel. Your customer can as it sees the GUI tell you what has to be changed. You alter the model accordingly genenerate a new prototype and show your customer the altered prototype. If you moderate your customer accordingly such an iteration could be done in less than 3min, not by random the length of a pop song. So try hard to make an iteration last no longer than 3min. Make your customer to discuss only one idea, only one issue at a time. Try hard, really hard. And make your generators generate mocks, that can later be replaced by functional code.) - deliver better quality
(First as describe above, you are able to deliver exactly what your customer needs. Furthermore you gain from massive re-use and standardization) - deliver manuals that describe the actual application
(One single model = a single source of truth, or "one ring to ..." [J.R.R. Tolkien])
This is way I like the MDD approach. Or do I love it?
But as Mr. Zschuckelt and also me wrote before, start with Model2Execute. Having reflected your post again, I advise you to start with Model2Execute. With Model2Execute the generator is already done by Software AG. As a result your ramp up time will be very short = minimal invest.
@Mr. Zschuckelt: please correct me if I am wrong in respect to Model2Execute.
Greetings,
Carsten
(*) I do not consider the Together/J approach a MDD approach, because no translation takes place. With Together/J the annotated Java code is the representation of the UML model.
Hello,
thank you very much, Carsten, for this elaborate testimony. So let's return to earth and Carolyn's question:
I understand your primary intention is to produce technical requirements documentation for the IT department based on your modeled business processes. If your IT department likes BPMN notation better than EPC, it is an option to have BPMN generated from EPC. While the tasks in BPMN are identical to the functions/process steps in EPCs and retain their identity, there are some issues Carsten pointed out:
- You may find, that IT design adds more detail to their BPMN models, which you are not interested in in your business view EPC models. So the tasks in business and IT view may not map 1:1. This does not do any harm as long as you have checked, that you really aren't interested in them. ARIS can support you in the governance of such review cycles using either the standard mini-workflows integrated in ARIS Connect or arbitrary custom processes in the ARIS Process Governance component.
- If you look further towards Model-2-Execute and sharing BPMN processes with IT for development in webMethods Designer(TM), out-of-the-box workflows support you in locking the BPMN models on the ARIS side, while IT develops them. This avoids inadvertent changes to the specification after development commenced. Changes in webMethods Designer can be synchronized back to ARIS. Then workflows can be initiated to evaluate, if the changes affect the business process or are of purely technical nature.
If you have CentraSite as your Service Repository for IT services ARIS can draw service definitions from there and you can integrate existing services in your ARIS BPMN models. When sharing the models with IT, service tasks will already be implemented for using those services. This is an example of what Carsten meant by code generation.
Having the single source of truth in your ARIS repository, the generation of manuals, specification and documentation is indeed the key benefit of Model-2-execute
Speaking of cycle times: No, with ARIS you won't build a mock HTML/Mobile/Swing or whatever realistic looking GUI in 3 minutes. But what we did with customers in Subject Matter Expert workshops is this: Create a wireframe model using the model type "screen design". It offers a lot of UI elements for building wireframes. What's even more important: In the screen design models you can add the business object attributes you want displayed and connect them to the respective UI elements. Active UI elements like buttons can be connected to IT functions they should trigger. These are model elements like any other ARIS objects and described with attributes. So as a result you get: Involved workshop participants sharing their knowledge in a structured way, that is very adequate for capturing all necessary IT requirements like UI and functionality. And work will not be interrupted for 3 minutes, while a new mock is generated.
Model2Execute is not simply about generating heaps of code or inventing the "Do-what-I-want-button", which obviously will never exist. It is a whole approach of describing, what a business department needs to specify and consider, so the IT department will preferably have as little as possible gaps in their specification. The approach is about "getting it right the first time", "aligning business with IT", generating as many artifacts as possible from the knowledge captured in the business department, and capturing that knowledge in a manner adequate for the business department, and digestable for the IT department through ARIS scripts, reports and generated documentation and - yes - as much as possible generated code.
As I said, the main issue bringing an IT project to success is keeping up the communication between business and IT and understanding business requirements. That is the benefit of the modeling effort using the ARIS method and specifically those components of it we consider relevant for M2E efforts. As Carsten pointed out, you have the issue of the one-way-street from model to code. To overcome this, at one point there is the synchronization of process information back to ARIS. At all other points the collaboration features of ARIS Connect may help your organization to facilitate the feedback cycles for users not trained on the ARIS clients. IT people or any other viewers can give comments, feedback or initiate change requests as they consume model content in ARIS Connect just as easily as they comment on something they see on their friend's Facebook page.
I think, now I got carried away again...
Carolyn, I'd love to know, if this discussion is of any value to you or we should leave it at that and solve the "soup-to-nuts" question.
Regards, M. Zschuckelt
Incidentally, I just saw a promotional video on Model-to-Execute, which shows quite nicely the capabilities of the ARIS EPC to webMethods integration and how that can be kept in sync both ways. It's quite neat:
http://www.ariscommunity.com/users/josephe-blondaut/2014-01-29-brand-new-aris-tutorials
At the bottom of that post you find the link to the model-to-execute video.
@Carolyn Faure, maybe that is the soup-to-nuts presentation you were looking for?
Regards, M. Zschuckelt
