People who downloaded this DZone Refcard also liked:

Agile Adoption: Reducing Cost

By Gemba Systems

About this agile adoption refcard

Faster, better, cheaper. That’s what we must do to survive. The Time to Market Refcard (a companion in this series) addresses faster, the Quality Refcard addresses better, and this Refcard addresses cheaper. This is about building the system for less.

Some of the costs of software development are associated with man hours needed to build the system, others with cost of maintenance over time, and yet others include hardware as well as software platform costs. Practices that educe any or all of these costs without sacrificing quality reduce the overall cost of the system.

Then there is the Pareto principle – a.k.a. the 80/20 rule. This rule suggests that roughly 20% of the software system is used 80% of the time. This is also backed up by research that is even more dramatic [figure with usage]. Practices that help the team build only what is needed in a prioritized manner reduce the cost and still deliver the most important business value to the customer (the part she uses).

Figure 1 Practices that help reduce the cost of building software.

You will be able to use this Refcard to get 50,000 ft view of what will be involved to reduce the cost of developing your systems.

Four Strategies to reduce cost

Software development is complex and often very complicated. It is HARD. This is not some new revelation, in fact Fred Brooks in the well known paper, “No Silver Bullet.”, states:

The essence of a software entity is a construct of interlocking concepts ...

I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.

There are four major strategies that can help you reduce the cost of building and maintaining your software

Maintain the Theory of the Code

One way to look at software development is ‘theory building’. That is, programs are theories – models of the world mapped onto software – in the head of the individuals of the development team. Great teams have a shared understanding of how the software system represents the world. Therefore they know where to modify the code when a requirement change occurs, they know exactly where to go hunting for a bug that has been found, and they communicate well with each other about the world and the software.

Conversely, a team that does not have a shared ‘theory’ make communication mistakes all the time. The customer may say something that the business analyst misunderstands because she has a different world view. She may, in turn, have a different understanding than the developers, so the software ends up addressing a different problem or, after several trials, errors and frustrations, the right problem but very awkwardly. Software where the theory of the team does not match, or even worse, the theory is now lost because the original software team is long-gone, is very expensive to maintain.

Building a shared theory of the world-to-software-mapping is a human process that is best done face-to-face by trial and error and with significant time.

Build Less

It has been shown that we build many more features than are actually used. In fact, we can see in Figure 2, only about 20% of functionality we build is used often or always. More than 60% of all functionality built in software is rarely or never used!

One way to reduce the cost of software is to find a way not to build the unused functionality. There are several Agile practices that help you get to that point.

Functionality Usage

Figure 2: Most functionality built is never used.

Pay Less for Bug Fixes

Typically, anywhere between 60%-90% of software cost goes into the maintenance phase. That is, most of our money goes into keeping the software alive and useful for our clients after the initial build. Practices that help us reduce the cost of software maintenance will significantly affect the overall cost of the software product or system.

Figure 3: Maintain the theory of the code helps reducing the cost of making design changes and fixing bugs. Building less enables better understanding and helps to understand the theory of the code for a change because there is less to change

Pay Less for Changes

The only thing constant in today’s software market is change. If we can embrace change, plan for it, and reduce its cost

when it eventually happens we can make significant savings. One of the strongest points of Agile development is that its practices enable you to roll with the punches and change your software as the business world changes.

The four strategies above: maintain the theory of the code, build less, paying less for maintenance and being able to react to change are not independent.

The practices

Evolutionary Design

Evolutionary Design

	Evolutionary design is the simple design practice done continuously. Start off with a simple design and change that design only when a new requirement cannot be met by the existing design.
	Evolutionary design reduces the cost by focusing on always building less. This, in turn, directly affects the cost of change drastically.
	You are on a development team practicing automated developer tests, refactoring, and simple design. That’s it, because this is one of those things that is applicable to all types of development projects. The context is especially a match if the technology used technologies is new to a large part of the team.

Simple Design

	If a decision between coding a design for today’s requirements and a general design to accommodate for tomorrow’s requirements needs to be made, the former is a simple design. Simple design meets the requirements for the current iteration and no more.
	Simple design reduces cost because you build less code to meet the requirements and you maintain less code afterwards. Simple designs are easier to build, understand, and maintain.
	Simple design should only be used when your team also is writing automated developer tests and refactoring. A simple design is fine as long as you can change it to meet future requirements.

Refactoring

	The practice of Refactoring code changes the structure (i.e., the design) of the code while maintaining its behavioe.
	Costs are reduced because continuous refactoring keeps the design from degrading over time, ensuring that the code is easy to understand, maintain, and change.
	You are on a development team that is practicing automated developer tests. You are currently working on a requirement that is not well-supported by the current design. Or you may have just completed a task (with its tests of course) and want to change the design for a cleaner solution before checking in your code to the source repository.

Automated Developer Tests

	Automated developer tests are a set of tests that are written and maintained by developers to reduce the cost of finding and fixing defects—thereby improving code quality—and to enable the change of the design as requirements are addressed incrementally.
	Automated developer tests reduce the cost of software development by creating a safety-net of tests that catch bugs early and enabling the incremental change of design. Beware, however, that automated developer tests take time to build and require discipline.
	You are on a development team that has decided to adopt iterations and simple design and will need to evolve your design as new requirements are taken into consideration. Or you are on a distributed team. The lack of both face-to-face communication and constant feedback is causing an increase in bugs and a slowdown in development.

Evocative Document

	Evocative documents are documents that evoke memories, conversations, and situations that are shared by those who wrote the document. They are more meaningful and representative of a team’s understanding of the system than traditional documents.
	Evocative documents help by accurately representing the team’s internal model of the software and allowing that model to be handed down from master to apprentice. The better understanding of the system over time also reduces the maintenance cost of the system over time because appropriate changes reduce the deterioration of the software.
	Current documentation isn’t working – as a document is passed from one person to another much of the context and value is lost, and as a result, the maintenance team’s understanding of the codebase constantly deteriorates. This is resulting in the calcification of your software system.

Automated Acceptance Tests

	Automated acceptance tests are tests written at the beginning of the iteration that answer the question: “what will this requirement look like when it is done?”. This means that you start with failing tests at the beginning of each iteration and a requirement is only done when that test passes.
	This practice builds a regression suite of tests in an incremental manner and catches errors, miscommunications, and ambiguities very early on. This, in turn, reduces the amount of work that is thrown away and therefore enables building less. The tests also catch bugs and act as a safety-net during change.
	You are on a development project with an onsite customer who is willing and able to participate more fully as part of the development team. Your team is also willing to make difficult changes to any existing code. You are willing to pay the price of a steep learning curve.

The remaining practices also help reduce the cost of software development. Because of the limited size of the refcard, we will only summarize them below.

	A backlog is a prioritized list of requirements that enable a team to build less by making sure they always work on the most important items first and help the team understand the theory of the code when used as an evocative document that shows a larger picture of the system.
	An iteration is a time-box where the team builds what is on the backlog and is a potential release and therefore enables building less.
	The done state is a definition agreed upon by the entire team of what constitutes the completion of a requirement. The closer the done state is to deployable software, the better it is because it forces the team to resolve all hidden issues early and thus reduces cost.
	The cross-functional team is one that has the necessary expertise among its members to take a requirement from its initial concept to a fully deployed and tested piece of software within one iteration. A requirement can be taken off of the backlog, elaborated and developed, tested, deployed.
	A self-organizing team is in charge of its own fate. Management gives the team goals to achieve and the team members are responsible for driving towards those goals and achieving them. A self-organizing team recognizes and responds to changes in their environment and in their knowledge as they learn. A self-organizing team is frequently a cross functional team as well.
	The Retrospective is a meeting held at the end of a major cycle - iteration or release - to gather and analyze data about that cycle and decide on future actions to improve the team’s environment and process. A retrospective is about evaluating the people, their interactions, and the tools they use.
	Continuous integration reduces the total time it takes to build a software system by catching errors early and often. Errors caught early cost significantly less to fix when caught later. It leverages both automated acceptance tests and automated developer tests to give frequent feedback to the team and to pay a much smaller price for fixing a defect.
	A user story is an evocative document for requirements. A user story is a very high level description of the requirement to be built –it usually fits on a 3 x 5 index card – and is a “promise for a conversation” later between the person carrying out the Customer Part of Team practice and the implementers.

How to adopt Agile practices successfully

To successfully adopt Agile practices let’s start by answering the question “which ones first?” Once we have a general idea of how to choose the first practices there are other considerations.

Become “Well-Oiled” First

One way to look at software development is to see it as problem solving for business. When considering a problem to solve there are two fundamental actions that must be taken:

• Solving the right problem. This is IT/Business alignment.
• Solving the problem right. This is technical expertise.

Intuitively it would seem that we must focus on solving the right problem first because, no matter how well we execute our solution to the problem, if it is the wrong problem then our solution is worthless. This, unfortunately, is the wrong way to go. Research shows in Figure 3, that focusing on alignment first is actually more costly and less effective than doing nothing. It also shows that being “well-oiled”, that is focusing on technical ability first, is much more effective and a good stepping-stone to reaching the state where both issues are addressed.

Figure 4: The Alignment Trap (from Avoiding the Alignment Trap in Information Technology, Shpilberg, D. et al, MIT Sloan Management Review, Fall 20078.)

This is supported anecdotally by increasing reports of failed Agile projects that do not deliver on promised results. They adopt many of the soft practices such as Iteration, but steer away from the technically difficult practices such as Automated Developer Tests, Refactoring, and Done State. They never reach the “well-oiled” state.

So the lesson here is make sure that on your journey to adopt Agile practices that improve time to market (or any other business value for that matter), your team will need to become “well-oiled” to see significant, sustained improvement. And that means you should plan on adopting the difficult technical practices for sustainability.

Know What You Don’t Know

The Dreyfus Model of Skill Acquisition, is a useful way to look at how we learn skills – such as learning Agile practices necessary to reduce cost. It is not the only model of learning, but it is consistent, has been effective, and works well for our purposes. This model states that there are levels that one goes through as they learn a skill and that your level for different skills can and will be different. Depending on the level you are at, you have different needs and abilities. An understanding of this model is not crucial to learning a skill; after all, we’ve been learning long before this model existed. However, being aware of this model can help us and our team(s) learn effectively.

So let’s take a closer look at the different skill levels in the Dreyfus Model:

Figure 5: The Dreyfus Model for skill acquisition. One starts as a novice and through ecperience and learning advances towards expertise.

How can the Dreyfus Model help in an organization that is adopting agile methods? First, we must realize that this model is per skill, so we are not competent in everything. Secondly, if agile is new to us, which it probably is, then we are novices or advanced beginners; we need to search for rules and not break them until we have enough experience under our belts. Moreover, since everything really does depend on context, and we are not qualified to deal with context as novices and advanced beginners, we had better get access to some people who are experts or at least proficient to help guide us in choosing the right agile practices for our particular context. Finally, we’d better find it in ourselves to be humble and know what we don’t know to keep from derailing the possible benefits of this new method. And we need to be patient with ourselves and with our colleagues. Learning new skills will take time, and that is OK.

Choosing a Practice to Adopt

Choosing a practice comes down to finding the highest value practice that will fit into your context. Figure 1 will guide you in determining which practices are most effective in decreasing your time to market and will also give you an understanding of the dependencies. The other parts in this section, How to Adopt Agile Practices Successfully?, discuss other ideas that can help you refine your choices. Armed with this information:

Figure 5: Steps for choosing and implementing practices.

What Next?

This Refcard is a quick introduction to Agile practices that can help you reduce the cost of building and maintaining your software and an introduction of how you to choose the practices for your organizational context. It is only a starting point. If you choose to embark on an Agile adoption initiative, your next step is to educate yourself and get as much help as you can afford. Books and user groups are a beginning. If you can, find an expert to join your team(s). Remember, if you are new to Agile, then you are a novice or advanced beginner and are not capable of making an informed decision about tailoring practices to your context.

References

About Gemba Systems

Gemba Systems is comprised of a group of seasoned practitioners who are experts at Lean & Agile Development as well as crafting effective learning experiences. Whether the method is Scrum, Extreme Programming, Lean Development or others - Gemba Systems helps individuals and teams to learn and adopt better product development practices. Gemba Systems has taught better development techniques - including lean thinking, Scrum and Agile Methods - to thousands of developers in dozens of companies around the globe. To learn more visit http://us.gembasystems.com/

Recommended Book

Agile Adoption Patterns will help you whether you’re planning your first agile project, trying to improve your next project, or evangelizing agility throughout your organization. This actionable advice is designed to work with any agile method, from XP and Scrum to Crystal Clear and Lean. The practical insights will make you more effective in any agile project role: as leader, developer, architect, or customer.

---

BUY NOW

books.dzone.com/books/agile-adoption-patterns

DZone greatly appreciates your support.


Your download should begin immediately.
If it doesn't, click here.

People who downloaded this DZone Refcard also liked:

Effective Process Modeling: with BPM & BPMN

By Matjaz Juric and Ana Sasa

About Business Process Management

BPM (Business Process Management) is a set of related activities, such as process modeling and design, process execution, process monitoring, and process optimization. This Refcard provides an overview of the BPM lifecycle together with the roles and results of business process modeling. It gives an overview of the BPMN (Business Process Modeling Notation) and presents the most important BPM patterns.

BPM: Business Process Lifecycle

A business process lifecycle covers the following phases (Figure 1):

• Process modeling - definition of the process models using the selected methodology and notation (such as BPMN).
• Process implementation – implementation of end-to-end IT support for the process. SOA provides technologies and tools to make the implementation phase quick and efficient.
• Process execution and monitoring – execution of the process and monitoring of the process to gather the Key Performance Indicators (KPI).
• Process simulation – simulated execution of the process with the objective gathering KPIs and identifying optimization points.
• Process optimization – improving the process efficiency, effectiveness, agility, flexibility, and transparence.

Figure 1: BPM process lifecycle

BPM: Modeling

Why do we Model Business Processes?

Who should take part in process modeling?

The team should include different profiles and encourage looking at the process from different angles. This is particularly important for optimizations. Four to six people is usually an optimal team size. The following table lists the various profiles that should comprise the team:

How do we model?

How to approach designing a process model:

We should model the process to understand the detailed structure of it. We should identify at least the following:

• Process activities, on various levels of details (depending on the selected approach)
• Roles responsible for carrying-out the process activities
• Events, which trigger the process execution and events that interrupt the process flow
• Input and output documents exchanged within the process
• Business rules that are part of the process

Below is the most conventional approach for designing a process model, in order of occurrence:

1. Identify the roles
2. Identify the activities
3. Connect the activities with roles
4. Define the order of activities
5. Add events
6. Add documents

Figure 2: Process model for each individual process

Figure 3: Results of Business Process Modeling

About BPMN

BPMN (Business Process Modeling Notation) is a graphical notation for business process modeling. The objective of BPMN is to support business process modeling for business and technical users. It provides a notation that is intuitive yet able to represent complex process semantics. BPMN is maintained by the Object Management Group.

Flow Objects

Flow objects are the main BPMN constructs that define the behavior of a business process. There are three categories of flow objects:

• Activities: they represent the work performed within a business process (see Figure 4).
• Gateways: they represent how a sequence flow diverges or converges in a business process (see Figure 5).
• Events: they depict that something happens in a business process (see Figure 6).

Figure 4: Activity types and markers

Figure 5: Types of gateways

Figure 6: Events, event triggers and results

Connecting Objects

Connecting objects are used to connect flow objects to each other and to other information. There are three categories of connecting objects: Sequence flow ( see Figure 7), Message flow ( see Figure 9), Association ( see Figure 11).

	Defines the order of execution of flow objects.
	Sequence flow with a condition (conditional flow).
	Default flow, which is chosen if none of the conditions are satisfied.

Figure 7: Sequence Flow

Figure 8: Construct that can be connected via sequence flow (blue shaded field represent a legal connection)

Shows the flow of messages between two entities.

Figure 9: Message Flow

Figure 10: Construct that can be connected via message flow (blue shaded field represent a legal connection)

Figure 11: Association

Other constructs

Figure 13: Swimlanes and pools

Figure 14: Artifacts

Exception Flow

In order to model an exception flow, we use intermediate events attached to the boundary of an activity. If such event is triggered during the activity execution, the flow is redirected through the intermediate event.
Example: The activity Check With Supplier of the example process has an intermediate timer event attached to its boundary. If the supplier does not provide a response within a certain timeframe, we remove the item from the order.

WorkFlow patterns with bpmn

Sequence
Workflow Pattern Description: An activity starts after completion of another activity.
BPMN: Activities are connected by a sequence flow directed towards the subsequent activity.
Example: After checking if the supplier can provide the necessary items in the Check With Supplier task, we notify the customer about their order in the Notify Customer task.

Parallel Split
Workflow Pattern Description: A path diverges into two or more parallel subsequent paths. The subsequent paths execute concurrently.
BPMN: The pattern can be implemented in several ways: We use several outgoing sequence flows for a flow object; We use a parallel gateway to divide a sequence flow into several sequence flows. We use an expanded sub-process in which we place the activities to be performed in parallel. We use an inclusive gateway with equivalent conditions.
Example 1: After receiving payment for the order we prepare the ordered items for shipment and issue the receipt concurrently.
Solution 1: Parallel split with outgoing sequence flows.	Solution 2: Parallel split using a parallel gateway	Solution 3: Parallel split using an expanded sub-process
Example 2: If the order items are in stock we send the confirmation of the order to the customer and reserve the ordered items in the inventory. These tasks are performed in parallel. Otherwise we check if the supplier can deliver the items

Solution 1: Parallel split using an inclusive gateway

Solution 2: Parallel split using a parallel gateway

Synchronization
Workflow Pattern Description: Two or more paths converge into one subsequent path. The subsequent path is enabled when all the preceding paths complete (and-join).
BPMN: The Pattern can be implemented in two ways: We use a parallel gateway to merge several sequence flows into a single flow. The outgoing flow activates when all the incoming sequence flows are enabled. We use an expanded sub-process in which we place the activites to be performed in parallel. Expanded sub-process completes after all the activities it contains complete.
Example 1: After preparing the ordered items for shipment and issuing the receipt, we ship the package to the customer.
Solution 1: Synchronization using a parallel gateway.	Solution 2: Synchronization using an expanded sub-process.

Exclusive Choice
Workflow Pattern Description: A path diverges into two or more subsequent paths. When the incoming path is enabled exactly one of the subsequent paths is selected and enabled.
BPMN: We use an exclusive gateway.
After analyzing the order we check whether the customer has provided a promotional code. If a promotional code is provided we collect discount information and use it to calculate final price. Otherwise, we calculate final price for the order without discounts.	Example 1: Exclusive choice with data-based exclusive gateway
After we notify the customer about the earliest possible delivery of the ordered items, the customer may change the ordered items, confirm the proposed date or cancel the order. If the customer does not respond in a certain timeframe an intermediate timer event is triggered.	Example 2: Exclusive choice with event-based exclusive gateway

Simple Merge
Workflow Pattern Description: Two or more alternative paths converge into a single subsequent path.
BPMN: The pattern can be implemented in two ways: We use an exclusive merge gateway to merge alternative paths. We use a flow object with two or more incoming sequence flows. The incoming sequence flows represent the ends of alternative paths. Any one of the incoming sequence flows trigger the flow object. Note: The behavior is the same in both cases provided that the incoming sequence flows are alternative.
Example: The two alternative paths used to calculate the final price of the ordered items are merged using the exclusive merge or by sequence flows leading to the “Check Inventory” task.
Solution 1: Simple merge with exclusive merge gateway	Solution 2: Simple merge with sequence flows to a flow object

Advanced Branching and synchronization pa tterns

Multi-Choice
Workflow Pattern Description: A path is diverged into two or more subsequent paths. One or more subsequent paths may be executed.
BPMN: The pattern can be implemented in several ways: We use an inclusive gateway. We use a collection of contidional sequence flows. We use a complex gateway.
Example 1: Based on requirements the customer specified in the order, we confirm the order via e-mail, by regular mail or both. Example solutions 1 nd 2 represent equivalent behavior.
Solution 1: Multi-Choice with an inclusive gateway	Solution 2: Multi-Choice with conditional sequence flows
Example 2: An order from the received order list may concern one or more departments. Depending on this, one, two or all three subsequent branches can be executed.

Structured Synchronizing Merge (Synchronizing join)
Workflow Pattern Description: Two or more paths converge into a single subsequent path. Several incoming paths may be enabled, in which case they are synchronized before the subsequent path is activated. In different process instances different number of incoming paths may be taken.
BPMN: We use an inclusive gateway.
Example: Based on requirements the customer specified in the order, we confirm the order via e-mail, by regular mail or both. If both activities are required to be executed, paths have to be synchronized before the process can continue.

Multi-Merge (Multiple Merge)
Workflow Pattern Description: Two or more paths converge into a single subsequent path. Each Incoming path activates the subsequent path.
BPMN: We use sequential flow for every ending of a converging path directed towards the flow object of the beginning of the subsequent path.
Example: We confirm the order via e-mail, by regular mail or both. if either of the activities takes place, the order information file needs to be updated.

Iteration based patterns

Arbitrary Cycles (Unstructured Loop)

Workflow Pattern Description: Loops that have more than one entry or exit points.

BPMN: Sequence flow connected to an upstream activity.

Structured Loop
Workflow Pattern Description: A task or a subprocess is repeated while or until some condition is true.
BPMN: We set the attributes of the activity as follows: We set the value of the LoopType attribute to “Standard”, We set the contidion expresion for the attribute LoopCondition, to model a “while” loop we set the value of the attribute TestTime to “Before”, to model an “until” loop we set the value of the attribute TestTime to “After”.
Example: After receiving a list of orders the Process Order subprocess is performed for every order until the end of orders is reached in the list.

Multiple instance patterns

Multiple Instances without Synchronization
Workflow Pattern Description: Multiple instances of a task or a subprocess are created. They run concurrently and are not synchronized on completion.
BPMN: We set the values of activity attributes as follows: LoopType attribute to “multiInstance”, MI FlowCondition to “None”. we set the value of the MI_Ordering attribute to “Parallel”
Example: For every order in the order list an instance of the Process Order subprocess is invoked. The subprocess instances are executed concurrently. Every instance generates a token that continues after the instance is completed.

Multiple Instances with a Priori Design-Time Knowledge
Workflow Pattern Description: Multiple instances of a task or a subprocess are created. The number of instances is known at design time. They run concurrently and are synchronized at completion before the process continues.
BPMN: We set the attributes of the activity as follows: we set the value of the LoopType attribute to “MultiInstance”, the expression of the MI_Condition attribute returns an integer representing the number of instances known at design time, we set the value of the MI_FlowCondition attribute to “All”. we set the value of the MI_Ordering attribute to “Parallel”
Example: If a request for a loan exceeds 1000 USD the loan needs to be checked for approval by 3 eligible employees.

Multiple Instances with a Priori Run-Time KnowledgeWorkflow Pattern Description: Multiple instances of a task or a subprocess are created. The number of instances depends on various run-time factors. Instances run concurrently and are synchronized at completion before the process continues.
Workflow Pattern Description: Multiple instances of a task or a subprocess are created. The number of instances depends on various run-time factors. Instances run concurrently and are synchronized at completion before the process continues.
BPMN: We set the attributes of the activity as follows: we set the value of the LoopType attribute to “MultiInstance”, the expression of the MI_Condition attribute is based on run-time factors and returns the actual number of required instances at run-time, we set the value of the MI_FlowCondition attribute to “All”. we set the value of the MI_Ordering attribute to “Parallel”
Example: The process receives a list of all orders. The expression of the MI_Condition attribute depends on the number of orders in the list, which can be different for every process instance. For every order in the order list an instance of the Process Order subprocess is created. The subprocess instances are executed concurrently. After all the subprocess instances are completed, the process continues.

Termination Patterns

Implicit Termination

Workflow Pattern Description: A process or a subprocess instance terminates when there is nothing else to be done and it is not deadlocked. The instance has completed successfully.

BPMN: The pattern can be implemented in one of the following ways: We end every path of the process or subprocess with an end event. If we use a start event we must use at least one end event. An end of a path in the process is indicated by a flow object without an outgoing sequence flow. The process completes when all tokens that were generated for the instance are consumed. Note: We must either conclude all paths with an end event (with an exception of compensation activities) or not use end event for the given process/subprocess.

Example: In the example process there are two alternative paths that the process instance can take. If the order cannot be fulfilled, the customer is notified. After this the end event is reached and the process completes. If the order can be fulfilled several activities take place and ordered items are shipped. After this the process reaches an end event and completes.

Explicit Termination

Workflow Pattern Description: Aprocess or subprocess terminates and the remaining work is cancelled.

BPMN: We use a terminate end event.

Example: In the example, the process splits into two parallel paths after order analysis. If additional documentation is required, the customer is notified. Even though order preprocessing activities already take place, if the customer does not send the required documentation in time, the process terminates explicitly and all the remaining activities are cancelled.

Conclusion

BPM is essential for continuous improvement of business process efficiency and effectiveness with the overall goal to produce business results faster, cheaper, better. This Refcard has provided the overview of the BPM lifecycle, presented the BPMN notation and demonstrated the most important patterns.

Other References and Resources

M.B. Juric, R. Loganathan, P. Sarang, F. Jennings: SOA Approach to Integration, November 2007. OMG: Business Process Modeling Notation (BPMN), Version 1.2, January 2009.

M.B. Juric, P. Sarang, B. Mathew: Business Process Execution Language for Web Services 2nd Edition, January 2006. H. Gaur, M. Zirn, et al.: BPEL Cookbook: Best Practices for SOAbased integration and composite applications development, July 2006.

Wil van der Aalst, Arthur ter Hofstede, et al.: Workflow Patterns, http://www.workflowpatterns.com/.

About The Author

Matjaz B Juric

Matjaz B Juric, Ph. D., is associate professor at the University of Maribor and the head of the SOA Competency Centre. He has been consultant for several large companies on the BPM/SOA projects and has worked on projects, such as SOA Maturity Model, SOA in Telcos, performance analysis and optimization of RMI-IIOP, etc. Matjaz is author of courses for the BPEL and SOA consulting company BPELmentor.com. He is also a member of the BPEL Advisory Board.

Ana Sasa

Ana Sasa has dedicated the last five years exclusively to the field of SOA. She has worked on a number of IT projects for government agencies and large companies and has specialized knowledge and experience in the technical, business and organizational aspects of BPM and SOA. She is a researcher at the University of Ljubljana.

Recommended Book

Learn how to model business processes in an SOA-compliant approach using BPMN, translate them into BPEL and execute them on the SOA platform. A practical guide with real-world examples illustrating all key concepts. This book is for CIOs, executives, SOA project managers, business process analysts, BPM and SOA architects, who are responsible for improving the efficiency of business processes through IT, or for designing SOA. It provides a high-level coverage of business process modeling, but it also gives practical development examples on how to move from model to execution. We expect the readers to be familiar with the basics of SOA.

---

BUY NOW

books.dzone.com/books/bpmn_bpm