The Decorator – enabling Structured and Unstructured processes

In the past year on of the hottest topics is ACM: the possibility of dynamically define a process, implement and execute it. The dynamic feature applies in every phase, instance, whatever.

This something that knowledge workers where wishing vis-à-vis with the structured process world, tied to it’s imagination to execute.

It’s also true that defenders of ACM say that ACM is not BPM, it’s other thing, it’s a spin off, because BPM philosophy is only prepared to by the book process execution. As told before, I totally disagree this approach in this post: ACM under BPM umbrella .

Sandy Kemsley posted <this> awesome post that combines the possibility of structured and unstructured execution.  This post points clearly that it’s impossible to separate ACM from BPM, because they blend together and most important if this kind of blended processes are the core of an enterprise it’s translates the way business occurs , it’s key of differentiation against competition, meaning they need to be managed, data must be collected in order to improvement takes place. Thus, without any kind of doubt ACM is a process type (unstructured) that belongs to the enterprise process environment, controlled, managed like any old school structured process. It’s BPM.

The aim of this post it’s however to unleash the foundation of structured and unstructured processes blending (like wine varieties).

For that I’m going to lend the good services of the Decorator!

The Decorator is a object oriented structural pattern, invented by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides.

I’m not going to explain the Decorator in terms of the object world, but to translate it to the business world.

One note: A pattern it’s not a template. It’s a way to implement a solution in a abstract way. For more references on this, please read this <book>.

The Decorator is a pattern that can add additional responsibilities to a process in a dynamic way. Decorators provide an agile way for extending functionality.

In order to understand how Decorator works I’m going to introduce a very insightful real world example from an architecture engineering lecture:  Coffee shop transaction.

Imagine you are in a Coffee shop and you have zillions of possibilities to drink a coffee drink.

  • Espresso;
  • Double espresso;
  • Espresso with milk;
  • Espresso with milk and cream;
  • Espresso with milk and cream and chocolate;
  • Milk with cream and chocolate;
  • Milk;
  • Lo fat milk.
  • Lo fat milk with espresso, and cream!

How to assemble this?

It’s impossible to build all the combinations, to create a bill of materials, a tree, because the outcome (what customers want) is dynamically build.

How a Decorator enables this complexity?

Copyright: Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides

In Coffee shop environment we have:

Translated to the process world:

Crazy isn’t it? No. It’s the new process reality. It translates the agility companies need to embrace.

Companies cannot rely anymore in process frameworks like TOGAF, UBPF, e-TOM, because mangers need to understand that the need to adapt on real time to the outcomes customers are expecting. A process framework does not translate the unique business processes a company needs to execute to differentiate from competition.

Looking form the above example companies need to design, implement, execute and control on real time.

Imagine this example:

An Airline company detects a customer complaining about a damaged luggage on twitter and it’s words are spreading killing the airline reputation.

The contact center detects the negative feedback automatically starts a complain handling request: seeks in their system if there is a already a record of the complain and if not, opens a new one (note: the customer can complain to the luggage handler, that it’s ultimately responsible for it, but it’s the Airline image that it’s being damaged, and somewhere the handler complain must be integrated in the Airline’s complains process).

The Contact Center speaks with the customer, collect the data and locate a luggage shop at customer’s location.

At the city where the customer is (temporally or not) the shop can or cannot belong to the Airline partner’s network. If it is, authorize the customer to drop by and collect a new suitcase. If it isn’t it need to get approval to provide a once in a lifetime bank transfer to the shop, explain it and get engagement with the shop that never had any kind of transaction with the Airline and send the customer to collect the new case.

In the meantime it should attach the information from the handler to separable process but in a integrated manner to this process instance.

In the end the contact center confirms if everything is ok and it tries to sell a luggage insurance in a smart way. Maybe the customer buys it.

As we can understand on this small example there are structured, unstructured, process composition, starting from complains and ending is cross sell. This is true BPM, this is agility, the decorator is just a front end possibility, a solution, not a template to execute some many different but integrated processes.

This is what companies need to understand. Now.

15 thoughts on “The Decorator – enabling Structured and Unstructured processes

  1. Hi Alberto,

    Good addition to the conversation started on Sandy’s site. If you read the thread you know we’ve provided an integrative approach for years ( We don’t follow the Decorator per se, but we do have generalized metamodels for interactions that allow for exactly the type of dynamic constructions you describe. We take this beyond process, to provide a custom response for every interaction – there is no hard code or static process models, simply interaction context and the policies that apply to circumstances.

    ACM and BPMS have their successful case studies, but in the end, for us knowledge-workers, there is no such physical boundary between the structured and the unstructured. In fact, they don’t exist as absolutes at all, there is simply work, which, based on its circumstances is more or less procedural in nature.

    Support for such emergent processes improves the business relevance of human-computer interactions, providing more responsiveness and the agility you describe.

    It also has important implications for software architecture as well as a generalized model eliminates the challenges of managing cross-cutting concerns that adds so much overhead to SOA and OO implementations.

    I’m glad you called out the value and future role of abstraction in process.


  2. Pingback: BPM Quotes of the week « Adam Deane

  3. Alberto, thanks for picking this up. ACM does lack an agreed definition, which is why simply call it ADAPTIVE Process to avaoid the acronym hick-hack.

    I do absolutely agree with you that adaptability applies to structured (fully defined a priori) and unstructured (evolve while being executed) processes. Adaptability is not just about being flexible or making dynamic changes, but about using knowledge from execution to modify process templates for future use.

    I defined in 2009 that ADAPTIVE includes structured and unstructured processes:

    A year ago I presented a process spectrum graphic in a reponse to Gartners process trends paper: similar to the one Sandy presented now.

    Re: The Decorator
    The Decorator is a practical OO-pattern if you use hard-coded process models. There are however many ways to solve this and they don’t need a decorator. A usual case management solution can simply use a custom folder to add content to ad-hoc tasks.

    The REAL-WORLD question is: How do you interact with those (decorated) entities, their data, staes and properties? How can one write rules pertaining to those and how can you present them to the user in meaningful ways? How do you expose and control properties of ad-hoc created entities? How does one move ad-hoc changes into templates? Hwo do you make automated recommendations based on past results? That’s how adaptability really happens …

    • Hi Max:

      Thanks for your comments.

      The idea of this post is not how to put in practice the pattern in a system, but to create an abstract model how to bring structured and unstructured process fusion, regarding that some system marketeers say this is impossible because somehow they need to create some kind of differentiation proposition.

      Regarding the second question I see clearly:

      Through semantics: helping people in the front end discovering the real meaning of the concepts they are using in a dynamic way. This is very important because if a end user is building a process grabbing pieces of activities, data, business rules that are going to be executed and somehow are going to use web services (without the user knowing it) with no semantic support, the end result can lead to chaotic data management, due to synonym, homonym and abstraction conflicts, simply because sometimes people does not use the same “artifact” with the same definition. For example imagine that user works in a insurance company and is executing an ad-hoc C level hiring process. At some point a new activity is going to be performed, lets call it “Perform Assessment”. Unfortunately this activity means in the business context two more things: a risk assessment when a customer wants to buy an insurance product, and carry out damage assessment of a claim. Without semantic support, probably the user is going to pick the first option available, resulting in data meaning destruction, creating confusion and data quality problems if we want to perform analysis later for performance proposes. It not worth having flows and properties definitions windows, because with no semantic support people continue to create duplicate definitions without knowing what its precise meaning resulting in conflicts mentioned above.

      Semantics can provide automatic recommendations when people are looking, discovering “artifacts” like the same way it supports web service discovery when the process enters in execution mode and automatically the enterprise service bus – ESB seeks for the services necessary to transfer data between systems. It’s no longer needed to explicitly look for and let the ESB do their job of finding the services needed for the invocation requested on execution mode, regarding process instances that are being executed by the process participant in the system.

      Still one challenge remains: integrating new definitions when such does not exist in the knowledge repository. I mean imagine that “Perform Assessment” activity never existed. The user need to use it and it cannot wait until some committee approve it. Thus systems need so support some transient intelligence, letting the process participant use that personal definition (the user cannot way 2 months for a formal approved definition), until the company decide what the truly meaning is. If somehow the name formerly used needs to be changed it’s necessary to updated it in a meaningful way to the user itself, otherwise he will continue to think that “Perform Assessment” is still valid. This is tricky, but it’s needed.

      I hope this example makes people think that there are risks in adopting tools that promise agile and dynamic processes composition but with no semantic support will have serious problems of data quality and knowledge management.

      Using the Decorator by it self providing an end user to compose a process with part structured (from a template) and with other part unstructured is already available is some systems. The mechanism is hidden from the user, but the thing is make people believe that they can DO both at the same time, thus there is no separated worlds: structured and unstructured process anymore.

  4. Max – I agree that Decorator doesn’t in and of itself serve adaptation, but to be fair that’s not it’s purpose nor was it the subject of Alberto’s post. We don’t use Decorator and I likewise agree with your more general point that static hard coded models resist change.

    Given we are talking about enterprise software though, I’m not sure it’s a great idea, conceptually speaking, to make every user their own ‘Decorator’ without mind to business rules or enterprise policy. Adapting solely based on user practice tends towards paving cow paths of convenience (least resistance) rather than any sense of best practice.

    It’s hard to imagine that everyone would define their own invoice template without some input from finance, nor would it be likely that users would be allowed to exempt themselves from regulatory compliance processes at will.

    The ability to modify is an important, but separate issue based on authority that is best left up to the business owners. Promoting options that have been successful in like/similar circumstances is yet another good capability.

    The most important thing is that interactions are responsive and flexible to provide for engaging user-experiences and informed decisions, to promote better outcomes.

  5. I am not disputing the possible benefits of a ‘Decorator model’ at all. It just does not answer the questions related to ‘user adaptation’. I also did not see how it provides adaptable, unstructured processes which is the subject of the post. Adaptable means to change templates, not just the current instance.

    Adaption through user empowerment does not imply anarchy! First there are business rules and user authority that govern also adaptive processes. Second, there will be guidance by the process owner. Third there ought to be coaching that will recommend best practice where they aren’t seen or accepted by the performer. In any case, least resistance means least effort which isn’t necessarily bad as long as it fulfills the goals.

    Overall the process adaptation follows a set of common templates that restrict the freedom to modify and adapt in implicit boundaries.

  6. Max – If authority and rules determine who can modify what, when and how – we agree, that is not anarchy. Such controls were not mentioned in your initial post, that’s why I made the comment.

    Regarding paving cow paths, I’m just saying ‘least effort’ (efficiency) cannot be presumed to be best effort or ‘doing things right’ (Drucker). The question becomes one of oversight, when and by whom.

    Regarding adaption, I can see the value of recommending successful process ‘templates’, though I’d simply add for optimal adaptability that the evaluation be more granular than that – step by step, rather than by process fragments. Your model likely supports this decomposition too.

    Alberto – I’m not sure what vendor you were implying, but your points re: limitations of semantics are sound. Inference is fine for discovery not enough to bind a process formally.

  7. Pingback: Decorator Pattern for BPM » Process for the Enterprise

  8. I think we need to describe our we embrace being adaptive within solutions that span an enterprise potentially. The decorator is a nice way of doing this and its something (conceptually in anycase) we have been looking at with our implementation of APG.

    I really like this post and I think it hits the nail on the head, lets not digress from what the actual post is trying to say by moving into other discussion areas….Greet post

  9. Pingback: A Process Mining Project « End to End BPM

  10. Pingback: Process Paths « End to End BPM

  11. Pingback: Semantic BPM – epilogue « End to End BPM

  12. Pingback: New Killer Star « End to End BPM

  13. Pingback: How Adaptive Case Management can be deceiving | End to End BPM

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s