Month: August 2010

Three challenges of BPMN 2.0

There are three major challenges in using BPMN 2.0 as a holistic (360°) approach to Business Process Management (BPM):

  1. Semantic Alignment
    BPMN like all other high-level process languages is context agnostic. This is good, as it allows a wide adoption throughout the industry. On the other hand it means that it does not explicitly express concepts found in business contexts, such as customer, accounts, discounts etc. As people from business and IT often have a very different view on certain business aspects, it is essential that they share the same semantic context in order to understand each other. If not, a process designed by a business person will not be understandable by an IT person and vice versa. In case BPMN is applied in combination with an outsourcing approach things get even worse.
  2. Level of Details
    BPMN2.0 is designed for automatic execution on a process engine. The goal is to have one process model from analysis to execution. But people from business and IT require different very levels of detail in their process descriptions. This is why a processes created by business people are usually not detailed enough for IT people. IT processes are usually full of technical information required for automation, rendering the process almost useless for business people.
  3. Portability
    The BPMN standard introduces several conformance levels (modeling, execution, BPEL, choreography). This is good as it fosters reusability of BPMN diagrams amongst different tools. At the same time the standard explicitly allows model extensions, “to satisfy a specific need, such as the unique requirements of a vertical domain” (quote from the spec). Thus, to avoid vendor lock-in, one at least has to be very careful in choosing the right model elements.

BPMN 2.0 should not be applied naively. Unfortunately this is often happens, especially when the standards are young. To be successful with BPMN 2.0 one has to find the right mixture of standards, design principles and methods.
For instance the semantic aligment problem can be mitigated by applying Scrum for analysis and process development. A multi-layer process design can help to address the level of detail problem. And choosing the the right product can increase portability.
This is nothing that comes for free by just using BPMN 2.0. It is rather something that needs to be actively managed by experienced engineers.

Definition of Done – Never without

One of the keys to success in agile projects is a proper Definition of Done (DoD). Only if everybody knows what has to be produced in order to complete a sprint, the goal can be achieved. 

The ideal outcome of a sprint is a product increment that is potentially shippable. To achieve that, all necessary actions to create a high quality product, such as writing documentation and thorough testing, have to be carried out within a sprint.  

In order to be really sure whether a an artifact is done, acceptance criteria are needed. Otherwise “done” would not be measurable. The criteria depends on the produced artifact. 

Software-Artifacts 

Software products usually comprise the following: 

  • Database structures (tables, stored procedures, triggers, …)
  • Application (user interfaces, Services, …)
  • Interfaces to external systems
  • Data (probably migrated from older data, …)
  • User documentation (online help, …)
  • Installer

    • Acceptance criteria 

    In order to prove that the above artifacts are really done, they need to be tested. Because the amount of test grows for each sprint, there is no way around automated regression testing. Therefore a continuous build,test and integration system, such as Team Foundation Server or Hudson, is essential for agile projects. The following tasks should be automated (in the brackets you can see an example of acceptance criteria for each task).

    • Unit testing  (error ratio maximum=10%, code coverage minimum=60%)
    • Load + Performance testing (concurrent users=20)
    • User acceptance testing, UI tests (error ratio maximum = 15%)
    • Integration (successful installation and availability)
    • Code quality checks (warnings maximum = 20)

    Some tests, such as UI tests, might be difficult to automate. But if you do it, you team will be rewarded with a highly accepted software product at the end of each sprint. As you can see the acceptance criteria is not 0% errors or 100% coverage, because this would not be realistic.

    Concept-Artifacts 

    Some projects develop their concepts using Scrum as well. Something that I would encourage to do. Although in Scrum the amount of written documents is greatly reduced, concepts are often helpful and required. For instance to refine coarse grained user stories from the product backlog or if the implementation of an idea can not be realised immediately. Concepts can be written in many ways as long as they clearly describe the idea down to a level that is sufficient for the implementation. For instance text documents, wiki pages, prototypes or design sketches. 

    Acceptance criteria 

    How can a concept be defined as done in terms of a DoD? As always! Conduct a review with people from within the team or other stakeholders from within the organization. When a concept is successfully reviewed, it is done.

    Summary

    Having a proper Definition of Done which clearly lists the required artifacts and acceptance critera is essential for successful Scrum projects. It creates a common understanding of what “done” actually means and is a key artifact to deliver high quality software in agile projects.

    Forms Over Data vs. Domain Driven Design

    A common challenge in Service-oriented architecture (SOA) is the design of service contracts. Beside many variations we see two basic types of contracts.

    Forms over data (FOD) is an approach in which the forms in the user interface directly reflects the data structures in a database. The service-layer, if present, primarily offers create, read, update and delete (CRUD) operations for the individual database entities.

    FOD is fostered by technologies such as Microsoft Access, Oracle Forms, .NET RIA Services. In JEE it is recognized as an anti pattern addressed by design (anti-)patterns such as Face Off or Session Facade.
    FOD is tempting because large parts of the service-layer can be generated from an existing data model. By using the right tools, developing an FOD-application can be quick and easy.

    Domain driven design (DDD) is an approach that utilizes a service-layer whose data objects are inspired by the business domain. The database structures are hidden behind a service-layer and not known by the service consumer, for instance the user interface. The domain model is usually modeled using XML Schema. DDD is typically used in SOA environments.

    DDD-Pros

    1. Portable domain model – If modeled in XML-Schema the domain object can be generated on JEE, .NET and other platforms.
    2. Business alignment – A business oriented domain model can be better understood by business users, thus increasing agility.
    3. Higher degree of reusability – Services representing business concepts are more likely to be reused, for instance in BPM environments.
    4. Decoupling of user interface and database – Data structures can be changed (up to a certain degree, of course) without affecting the clients. Changes can be handled in the service layer.
    5. Maintenance – Proper domain driven services are designed to last. Paired with a versioning approach service maintenance can be simplified.

    FOD-Pros

    1. Development effort – FOD is often supported out-of-the-box in many products, so that no using it would require more knowledge and development effort.

    Although there are always areas in which one or the other approach makes more sense, you can clearly see my preference. I think forms over data can be particularly useful for small applications and prototypes. Especially with existing database models. For large enterprise applications one should prefer a domain driven service design in combination with a sound SOA approach.