Eclipsecon

Process Driven Software Development at a larger Financial Institution

Iterative and agile methodology, BPMN2 Modeling, Eclipse Stardust Roundtrip with BPMN2Modeler

Runtime Extension

Version 1.0Presentation 27.10.2014

2 © 2014 ITpearls AG

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

Process Driven Software Development Agenda

3

Process Driven Software Development Abstract

© 2014 ITpearls AG

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 AGBob Brodt, Red Hat, Inc.

4 © 2013 ITpearls AG

Process Driven Enterprise Development Dozens of Processes? Start managing Business Processes

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

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

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

Business Rules going viral

Different process standards

Many models and documents

Disconnected artifacts Complex application

interaction Increasing number of

Test Cases

1 2

34

5

Process Driven Enterprise Development BPM Rooted in the Enterprise Strategy

© 2014 ITpearls AG

6

© 2013 ITpearls AG

BPM Management From Strategy to Projects

7 © 2014 ITpearls AG

Strategic Capabilities and Process Management Process Maps as part of the Business Architecture

8 © 2014 ITpearls AG

Strategic FundingInvest along your top 3 Business Priorities

9 © 2014 ITpearls AG

End2End ModellingAgile Modelling 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

10 © 2014 ITpearls AG

BPMN2 Roundtrip ModelingHow to bring your BPMN2 Models into Eclipse Stardust

11 © 2014 ITpearls AG

BPMN2 Roundtrip ModelingInstrument the BPMN2 Models in BPMN2 Modeler

12 © 2014 ITpearls AG

BPMN2 Roundtrip ModelingDeploy n Models into your Runtime Environment

13 © 2014 ITpearls AG

14

Mandate 1: Make it BPMN 2.0 spec. compliant

© 2014 ITpearls AG

15

Mandate 2: Make it Extensible

© 2014 ITpearls AG

16

Mandate 3: Leverage Graphiti

© 2014 ITpearls AG

• Flat learning curve• Fast development of graphical editors• Common look and feel• Accessibility

17

Extension Points

© 2014 ITpearls AG

• 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.

18

Screen Shot

© 2014 ITpearls AG

19

Get Involved!

© 2014 ITpearls AG

• 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

20

Links

© 2014 ITpearls AG

• OMG BPMN 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

21

Glossary

© 2014 ITpearls AG

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.

22 © 2013 ITpearls AG

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.

Agile ModelingAgile Modeling Principles according to Scot Ambler (1)

23 © 2013 ITpearls AG

Agile ModelingAgile Modeling 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.

24 © 2013 ITpearls AG

IT-StrategyThe 5 Dimensions

25 © 2013 ITpearls AG

Enterprise ArchitectureCapabilities within IT-Architecture