Downloaded 13 times
Uploaded bySopra Steria
EclipseCon BPM Day Ludwigsburg - Roundtrip Modelling with Eclipse Stardust
The document discusses a process-driven software development approach utilizing BPMN2 modeling and Eclipse Stardust aimed at larger financial institutions. It emphasizes the need for agile methodologies and effective business architecture to manage increasing process complexity and automation demands. Presenters highlight key strategies for implementing BPM practices that align with enterprise strategy and improve business outcomes through iterative modeling and stakeholder engagement.
More Related Content
Similar to EclipseCon BPM Day Ludwigsburg - Roundtrip Modelling with Eclipse Stardust
EclipseCon BPM Day Ludwigsburg - Roundtrip Modelling with Eclipse Stardust
- 1. Eclipsecon Process DrivenSoftware Development at a larger Financial Institution Iterative and agile methodology, BPMN2 Modeling, Eclipse Stardust Roundtrip with BPMN2Modeler Runtime Extension Version 1.0 Presentation 27.10.2014
- 2. Process Driven SoftwareDevelopment Agenda First Part Gregor Gisler, ITpearls AG • Abstract • Dozens of Processes? Start managing Business Processes • BPM Rooted in the Enterprise Strategy • From Strategy to Projects • Process Maps as part of the Business Architecture • Invest along your top 3 Business Priorities • Agile Modelling of the top priority Processes • How to bring your BPMN2 Models into Eclipse Stardust 2nd Part Bob Brodt, RedHat Inc. • BPMN2Modeler Runtime Extensions • Mandate 1: Make it BPMN 2.0 spec. compliant • Mandate 2: Make it Extensible • Mandate 3: Leverage Graphiti • Extension Points • Screen Shot • Get involved • Appendix 2 © 2014 ITpearls AG
- 3. Process Driven SoftwareDevelopment Abstract With BPM maturing over time new customers buy into BPM or improve their existing infrastructure. These new BPM initiatives aim at raising the abstraction level with end to end modeling capabilities, harvesting SOA investments made in the last years, and take advantage of new BPM engines. With higher abstraction in place combined with agile methods the development cycles tend to be shorter and the cost for functional units are decreasing. This leads to a surge in processes to be automated. An increasing number of implemented processes leads to more complexity. In this presentation you will be shown ways on how to tame the complexity with a development process that includes business architecture, iterative (roundtrip) process development and deployment based on Eclipse Stardust. Presenters: Gregor Gisler, ITpearls AG Bob Brodt, Red Hat, Inc. 3 © 2014 ITpearls AG
- 4. Process Driven EnterpriseDevelopment Dozens of Processes? Start managing Business Processes Complicated/Complex Business Interaction Exponential growth of automation needs (processes to automate) Multiple Business Channels Raised Customer Expectations Increase of regulations Agile Principles Cost Pressure Technology lifecycle Repository based modeling tool Shared Repository Graphical Specification Traceability Standardized modeling method based on UML profiles Integrate BOM and Process Data Generate Forms and other recurring artefacts 4 © 2013 ITpearls AG Business Rules going viral Different process standards Many models and documents Disconnected artifacts Complex application interaction Increasing number of Test Cases Do Business Archit. Reuse Models, apply modeling standards Standardize communication Bring roles and activities together Apply agile modeling Apply KPI’s and establish cont. impr. Document Generation 1 2 4 3
- 5. Process Driven EnterpriseDevelopment BPM Rooted in the Enterprise Strategy 5 © 2014 ITpearls AG
- 6. 6 BPM Management From Strategy to Projects © 2013 ITpearls AG
- 7. Strategic Capabilities andProcess Management Process Maps as part of the Business Architecture 7 © 2014 ITpearls AG
- 8. Strategic Funding Investalong your top 3 Business Priorities 8 © 2014 ITpearls AG
- 9. End2End Modelling AgileModelling of the top priority Processes • Model together with Business – ensure all Stakeholders participate • Model in short iteration cycles – keep the momentum • Use a modelling method like “Method&Style” • Don’t model generic – force the people to be concrete • Don’t model just for documentation reason’s to fill your process maps – invest your time and energy modelling processes that are identified as “strategic” (within top 3 business priorities and failed in the assessment) and have FUNDING! • Have a proper tool at hand that encourages Business to model (including Model Wizard, Model Interchange Group proven and more) • Demand a role model from Business early – there is no time to define this in one iteration – usually there is lots of infrastructure involved with this • Don’t forget the BOM – Business knows a lot about their data and what is needed to run the processes successfully • Define input- and output data early and separate Process from User Data • Know the environment and how to access the data (EAI Landscape) • Establish a model repository that is easy to use and enforce proper usage 9 © 2014 ITpearls AG
- 10. BPMN2 Roundtrip Modeling How to bring your BPMN2 Models into Eclipse Stardust 10 © 2014 ITpearls AG
- 11. BPMN2 Roundtrip Modeling Instrument the BPMN2 Models in BPMN2 Modeler 11 © 2014 ITpearls AG
- 12. BPMN2 Roundtrip Modeling Deploy n Models into your Runtime Environment 12 © 2014 ITpearls AG
- 13. 13 © 2014ITpearls AG
- 14. Mandate 1: Makeit BPMN 2.0 spec. compliant 14 © 2014 ITpearls AG
- 15. Mandate 2: Makeit Extensible 15 © 2014 ITpearls AG
- 16. Mandate 3: LeverageGraphiti • Flat learning curve • Fast development of graphical editors • Common look and feel • Accessibility 16 © 2014 ITpearls AG
- 17. Extension Points •BPMN2 model extensions • “Bring your own” EMF model • Define extensions in plugin.xml • Define certain extensions at runtime via configuration files • Tool Palette extensions • Tool Profiles • Custom Activities, Connections, Artifacts, etc. • DSL for defining compound elements • Tabbed Property Sheets • Add, omit or replace individual tabs • Customize presentation of graphical elements • Hook into Graphiti’s Feature Container framework • Hook into Graphiti’s Tool Behavior Provider • Override default presentation, or provide a “custom look” • Customize file parsing/serializing • EMF Resource Factory • Override default BPMN2 modeler resource behavior • Hook into object lifecycle for handling custom creation, decoration, change notification, etc. 17 © 2014 ITpearls AG
- 18. Screen Shot 18© 2014 ITpearls AG
- 19. Get Involved! •Eclipse BPMN2 Modeler Project: https://www.eclipse.org/bpmn2-modeler/ • source code: git clone git://git.eclipse.org/gitroot/bpmn2-modeler/org.eclipse.bpmn2-modeler.git • Wiki: https://wiki.eclipse.org/BPMN2-Modeler • Forum: https://www.eclipse.org/forums/index.php/f/226/ • My email: bbrodt@redhat.com 19 © 2014 ITpearls AG
- 20. Links • OMGBPMN Model Interchange Working Group: http://www.omgwiki.org/bpmn-miwg/doku.php?id=start • Value Driven BPM: Peter Franz and Mathias Kirchmer: http://www.accenture.com/SiteCollectionDocuments/PDF/Accenture-Value-Driven-Business-Process- Management-Transcript.pdf • The Business Capability Map: The «Rosetta Stone» of Business/IT-Alignment – Cutter Consortium 20 © 2014 ITpearls AG
- 21. Glossary Term Meaning Capability An ability that an organization, person, or system possesses. Capabilities are typically expressed in general and high-level terms and typically require a combination of organization, people, processes, and technology to achieve. For example, marketing, customer contact, or outbound telemarketing. Governance The discipline of monitoring, managing, and steering a business (or IS/IT landscape) to deliver the business outcome required. Value Stream Value streams, a key component of the business ecosystem, may take a little more explanation. Value streams depict how a business achieves value for an internal or external stakeholder. They are defined as an end-to-end collection of activities that create a result for a customer. 2 Value streams are a very high-level view of value accretion, broken into stages. Value stream stages further decompose into business processes, which typically define the details below various stages of a given value stream. 21 © 2014 ITpearls AG
- 22. Agile Modeling AgileModeling Principles according to Scot Ambler (1) The best practices of AMDD (Agile Model Driven Development) are Active Stakeholder Participation. Stakeholders should provide information in a timely manner, make decisions in a timely manner, and be as actively involved in the development process through the use of inclusive tools and techniques. Architecture Envisioning. At the beginning of an agile project you will need to do some initial, high-level architectural modeling to identify a viable technical strategy for your solution. Document Continuously. Write deliverable documentation throughout the lifecycle in parallel to the creation of the rest of the solution. Document Late. Write deliverable documentation as late as possible, avoiding speculative ideas that are likely to change in favor of stable information. Executable Specifications. Specify requirements in the form of executable “customer tests”, and your design as executable developer tests, instead of non-executable “static” documentation. Iteration Modeling. At the beginning of each iteration you will do a bit of modeling as part of your iteration planning activities. Just Barely Good Enough (JBGE) artifacts. A model or document needs to be sufficient for the situation at hand and no more. 22 © 2013 ITpearls AG
- 23. Agile Modeling AgileModeling Principles according to Scot Ambler (2) Look Ahead Modeling. Sometimes requirements that are nearing the top of your priority stack are fairly complex, motivating you to invest some effort to explore them before they're popped off the top of the work item stack so as to reduce overall risk. Model Storming. Throughout an iteration you will model storm on a just-in-time (JIT) basis for a few minutes to explore the details behind a requirement or to think through a design issue. Multiple Views and Diagram. Each type of model representation has it's strengths and weaknesses. An effective developer/requirements engineer will need a range of models in their intellectual toolkit enabling them to apply the right model in the most appropriate manner for the situation at hand. Prioritized Requirements. Agile teams implement requirements in priority order, as defined by their stakeholders, so as to provide the greatest return on investment (ROI) possible. Requirements Envisioning. At the beginning of an agile project you will need to invest some time to identify the scope of the project and to create the initial prioritized stack of requirements. Single Source Information. Strive to capture information in one place and one place only. Test-Driven Design (TDD). Write a single test, either at the requirements or design level, and then just enough code to fulfill that test. TDD is a JIT approach to detailed requirements specification and a confirmatory approach to testing. 23 © 2013 ITpearls AG
- 24. IT-Strategy The 5Dimensions 24 © 2013 ITpearls AG
- 25. Enterprise Architecture Capabilitieswithin IT-Architecture 25 © 2013 ITpearls AG
Editor's Notes
- #2 © 2012 BPMessentials.com - Bruce Silver Associates in Zusammenarbeit mit itp commerce ag
- #3 The editor is extended through user-written plugins which implement one or more of the following extension points. The plugin defines what we call a «Target Runtime» because it customizes the editor for the BPMN2 language subset that is supported by a specific execution engine. The Target Runtime language subset can be extended in a number of ways: You can bring your own model. If you already have an EMF ecore file and java implementation classes, these can be directly used by your editor plugin. This is how the Stardust plugin implements the model extensions for the Stardust engine. Extensions can be defined using plugin.xml definitions. Finally, these definitions can be declared in a configuration file in your runtime workspace and will be dynamically loaded when the editor is started. The Tool Palette can be completely redefined. Tool Profiles allow you to define a set of tools and associate them with a profile name. These tool sets can then be customized for a specifc developer role, or task. There is also a Domain Specific Language that allows you to create what are called «compound tools». Thus, you could define a single tool that creates a sequence of connected activities, gateways, events, etc. Property sheet tabs can be customized for each type of BPMN2 element. The core editor provides default tabs that can either be subclassed, replaced by a custom implementation or completely omitted. Graphical elements can be customized using hooks into certain Graphiti implementation classes. We have found that not all XML parsers are created equal. Some engine language parsers are written by hand and don’t necessarily follow all of the rules of XML. This is why the editor allows for overriding the EMF Resource implementation. This is where parsing and serializing behavior can be defined. Finally, the editor provides hooks into the editing session lifecycle, object creation, initialization and finalization for specialized handling.
- #14 [Transition slide: Gregor, this is where you hand off to me.] In 2012 Red Hat sponsored development of the original prototype for what was to become the BPMN2 Modeler. BPMN2 Modeler is an eclipse project under the SOA top-level project and, as such, is open source so we invite the community to use the product, make suggestions for improvement, and contribute bug fixes and enhancements.
- #15 The mandates for the project were simple: First, Make it BPMN 2.0 spec compliant. The BPMN 2.0 specification is huge and overly complex in my opinion because it tries to be all things to everyone. In our case compliance does not necessarily mean exposing the entire specification through the UI, but make that which is implemented, conform to the specification. The editor uses the Eclipse BPMN2 metamodel project as the underlying model. This model does indeed implement the complete BPMN 2.0 spec so the editor can surface all of the BPMN2 elements through the UI. However, for simplicity we chose not to do so for the core editor. This leads us to the second mandate...
- #16 Mandate 2: Make it extensible. I’m not aware of any execution engine that implements the entire BPMN 2.0 spec, and each has different requirements depending on the applications it is designed for. Our baseline during development of the editor’s public API, was jBPM which is Red Hat’s offering in the BPM space. The jBPM engine implements a rich subset of BPMN 2.0 but also defines several extension elements. So, not only does the editor’s plugin API need to be able to surface these extension elements through the GUI, it also needs to hide those elements which are not supported by the engine.
- #17 Mandate 3: Leverage the eclipse Graphiti graphical editor framework. Graphiti is an abstraction layer on top of eclipse GEF and Draw2d which makes it relatively simple to build rich graphical editors with very little coding. There are several benefits to using such a framework: A flat learning curve: the user interaction and graphical rendering is all handled by Graphiti and provides reasonable defaults. The developer needs to focus only on managing the model and responding to model changes triggered by user interactions. Fast development: because most of the editor is already implemented in the framework itself, developing a new editor is relatively simple. Common look and feel: Graphiti provides all of the features you would expect from a graphical editor, including Drag-n-drop support, tool palette, an Overview page, Property pages, hover help and tooltips, etc. Accessibility: refers to a software tool’s usability by disabled persons. This is already part of the Graphiti framework.
- #18 The editor is extended through user-written plugins which implement one or more of the following extension points. The plugin defines what we call a «Target Runtime» because it customizes the editor for the BPMN2 language subset that is supported by a specific execution engine. The Target Runtime language subset can be extended in a number of ways: You can bring your own model. If you already have an EMF ecore file and java implementation classes, these can be directly used by your editor plugin. This is how the Stardust plugin implements the model extensions for the Stardust engine. Extensions can be defined using plugin.xml definitions. Finally, these definitions can be declared in a configuration file in your runtime workspace and will be dynamically loaded when the editor is started. The Tool Palette can be completely redefined. Tool Profiles allow you to define a set of tools and associate them with a profile name. These tool sets can then be customized for a specifc developer role, or task. There is also a Domain Specific Language that allows you to create what are called «compound tools». Thus, you could define a single tool that creates a sequence of connected activities, gateways, events, etc. Property sheet tabs can be customized for each type of BPMN2 element. The core editor provides default tabs that can either be subclassed, replaced by a custom implementation or completely omitted. Graphical elements can be customized using hooks into certain Graphiti implementation classes. We have found that not all XML parsers are created equal. Some engine language parsers are written by hand and don’t necessarily follow all of the rules of XML. This is why the editor allows for overriding the EMF Resource implementation. This is where parsing and serializing behavior can be defined. Finally, the editor provides hooks into the editing session lifecycle, object creation, initialization and finalization for specialized handling.
- #19 Highlights: Graphical drawing canvas mulitpage tabs at top – diagrams multipage tabs at bottom – sub processes within a diagram Property Sheet Alternative: use popup dialogs to save screen space Tool Palette Profiles Outline Business Model Diagram Interchange Model Thumbnail