IT Directions« What good are "business processes" and "business services" that bear no true relation to the real world? | Main | A new framework for 21st century business technology »
October 09, 2006Can a business based just on activity sequences survive?
My post last week, on "business processes" and "business services" that bear no true relation to the real world, attracted a good deal of comment - not just to the blog itself but also on the leading SOA mailing list, on which an excerpt from the article was republished by the moderator.
This is exactly what I had hoped would happen. Many readers of this blog, and people on the SOA list, are in a position to offer software users something better, so I am trying to get the message across to at least some of these vendors and standards committee members.
However, the comments showed that many people misunderstood what I was trying to say. Mea culpa, of course - I should have explained myself better. So here is an extended discussion, that I hope will make things clearer.
If you are a user or developer of BPM/SOA tools:
- First read the original article, if you haven't done so already
- Then follow the discussion below.
In a year or two, the impacts of the new tools you are currently implementing or building will start to make themselves felt. And this may well make the difference between success and failure for your organization as a whole.
BASING PROCESSES AND SERVICES ON BUSINESS OBJECTS
It is quite extraordinary that, despite the advances of the last 20 years in management theory, so many people in the IT community still feel that business reality can be expressed as a set of activity sequences. A typical outlook is that a business is comprised of what Hammer and Champy termed "functional silos": Finance, Manufacturing, Sales, Servicing, and so on.
This description of business operations is what enlightened management consultants have been trying to change since the late 1980s - trying to move business people to a more useful perspective based on processes. And a process architecture is not a value "stream" or "chain" - what author Martyn Ould derides as the 5-bite kebab:
Martyn Ould's "5-Bite Kebab" - (c) Venice Consulting Ltd 2006
Rather, as Martyn points out, a process architecture is a network of objects and interactions: different for every type of organization.
The real world isn't sequential at all. Processes or services may often be treated as activity sequences, in the belief that this is a useful abstraction from reality: a simplification of reality in order to get a handle on it. However, as abstractions go, it is a very dangerous one. The sequential approach may be easy to implement for vendors, especially those with legacy products to repurpose, but it is highly inaccurate. Treating processes or services as objects is a much more helpful and valid abstraction of organizational life.
For example, in real life a customer has a relationship with a supplier that is not simply defined by a sequence of ordering, shipping and payment activities, but encompasses more complex things such as having an account (which may include standard requirements, payment options, etc.), making overlapping requests (the output of which may be delivered together), specifying delivery details (which may be to a third party), and so on.
In fact, it is fair to say that activity sequences are "more abstract" than objects. In other words, they are an abstraction that is further from reality. They are so far from business reality that, used as a high-level modelling technique, they present a serious risk to organizational health.
IT people are well-versed in object-based techniques, and current IT tools do use them - but only behind the scenes, for implementation of the process and services that users are forced to design as activity sequences. But there is no reason at all to restrict the use of an object-based abstraction to programmers! All vendors have accomplished by forcing sequential tools onto business people is to make them think that such tools are poorly designed. I deal with a lot of non-technical business people (users and consultants in particular) and they almost all feel that BPM/SOA tools bear no reality to the world they know. They use these tools because (and only when) they have to, not because they want to.
This is because business people naturally conceive of their organization very differently to a set of activity sequences. Just ask any CEO about the long-term relationships (s)he is trying to build with customers. So what we need is to provide business people with tools that let them model the world the way they truly understand it. It's no use saying that behind the scenes everything is object-based - that doesn't help the business at all. The issue here is not about implementation of software tooling, but about the design tools presented to users - which is all that business people see. Designing processes or services as activity sequences does not ring true with business people - and they're right to be suspicious of it, since in real life very little happens in this way.
IT people tend to think that business people are incapable of understanding objects. Well, in my experience it's the other way around. Business people naturally understand the world as a dynamic, evolving, adaptive network of interconnected things - but IT people naturally retreat to sequential design techniques, probably since tools are easier to build if constructed along these lines (especially if you are a software vendor with a back catalog to leverage). It's the IT community who don't "get" the value of object-based design in this space - not the business community.
Further, it makes no difference whether processes or services are to be implemented from scratch, or via reuse of legacy applications. A main aim of both BPM and SOA is to make the implementation of processes and services completely transparent to users. It is user-facing design tools, not software implementation techniques, that we are discussing here - and it is important to understand the type of design in question. There's a difference between physical design (how to go about the nuts and bolts implementation of software code) and conceptual (aka logical) design. Conceptual design is what, with BPM and SOA, users see - and it is the basis not only for their interaction with IT, but also for how they make use of computer systems, and and how they re-shape their business operations around those computer systems. It's very important to have both sorts of design, and not to confuse them.
It might be that the physical design is based closely on the conceptual design. If so, software tools could be used to help generate one from the other semi-automatically. Alternatively, the conceptual design might be so high-level that there are several layers between it and any physical design that is used to generate software code: the physical design might include several existing packaged applications, for example. In this case tooling may not be able to do quite as much for the user.
However, such questions are not my main subject here. What I am saying now is that a set of activity sequences is a very poor basis for conceptual design. A much better approach would be to allow users to define the business objects in which they are interested. This does not mean exposing a horribly complex set of object models to users - programmers might need such models to build the underlying code, but users should be protected from these gory details. Rather, we need to provide BPM/SOA users with design tools that let them capture and visualize, in a simple way, the business objects with which their organization is concerned.
What I am talking about is a better way to conceptualize business process and business services - a way that matches more closely the reality of organizational operations. So that you know I practise what I preach, in my own work I am trying to provide free software tools that do this for human collaboration - "human-driven" work processes. What I am calling for here is for similar tools to be made available for "mechanistic" BPM and SOA - business operations that are automated, or in which human involvement is limited to key decision and data entry points.
TAKE AWAY
The BPR disaster of the 1990s may well be happening all over again for organizations investing in BPM and SOA, as they invest heavily in a simplistic, inflexible approach to business operations.
Yet basing the design of processes and services on business objects is not more complex than basing it on activity sequences - it is easier! For business people, object-based design is how they naturally think: about assets, staff, product catalog, inventory, customers, and so on. All these are objects, not functions. Trying to get business people to categorize their world as a bunch of functions is forcing a square peg into a round hole.
Further, I'm not arguing that existing BPM/SOA techniques should be abolished (in most cases, anyway). What I am suggesting is that there is an entire layer missing - an object-based modelling layer. Unless this is put in place, BPM/SOA will end up like BPR - an approach on which the next generation pours scorn, wondering how its practitioners can have been so incredibly short-sighted.
There is still time to turn things around. I am not proposing taking very much away, but rather, adding something new - a higher-level modelling layer via which business people can, with the support of IT people, describe the objects that are of interest to their organization. If you want the current generation of software tools to work to your advantage, you need this layer, and you need it soon.
Posted by keithhb in
Business Process Management
• Management
• Service-Orientated Architecture
|
Digg This|
Add to del.icio.us
My first idea about business objects was that it is not really something new, because SAP had this already some time ago.
My other thought was that a service is not a function. Instead, a service represents an entity, which can be accessed through a well defined interface. Therefore, I think service and object are not so far off from each-other.
On the other hand, if you have a very automatic process not requiring human interaction, using activity sequences for modelling might be enough. Imagine for example the process started after your order at an online store was confirmed. It must first get the product from the warehouse, put it into a nice package and hand it over to UPS. Such processes exist and are not only a minor thing. But of course, you won't find such processes in a consulting company, but in production industry for sure.
Posted by: Sebastian Stein at October 9, 2006 02:39 PM
Sebastian
You are right that business objects are nothing new - for example, in the 1990s IBM made a well-publicized attempt at providing a set of "reusable, object-oriented business components for commercial applications" in their San Francisco Framework. However, these were code artefacts - software components - not high-level conceptual model elements of the kind I am proposing are necessary.
With regard to your other point, this is mixing up design and implementation. Behind the scenes, a service may in fact be implemented via an object - but even if so, this should be entirely concealed from the business layer. A key aim of both BPM and SOA is to enable the implementation layer to be rejigged as and when necessary - for example, to replace or repurpose legacy systems - without noticeable impact on the business.
Posted by: Keith Harrison-Broninski at October 9, 2006 05:29 PM
About mixing implementation/design: No, I'm not mixing it up :-) On an abstract view you access an object through a well-defined interface. You do the same with a service. Currently, we use functions of services to define a business process. You say that you want to have something like a business object. But than again, you would connect a set of objects by the functions provided through an interface. This is similar, so that's why I think your business object idea is not so far off from what we do today with services.
Posted by: Sebastian Stein at October 10, 2006 05:27 AM
I assume by "functions of services" you mean something like the "operations" provided in a WSDL specification of a SOAP service?
If so, you are presumably suggesting that a WSDL service is effectively a business object. I disagree. And this is very far off from what I am suggesting.
Why? Because there is no reason for services in the WSDL/SOAP sense to relate to any particular group of real-world entities. A WSDL service can, and often is, simply a set of functions related by no more than their implementation being via a specific software application. There is certainly no reason to suppose that, taken together, the operations provided by a specific WSDL service provide all the functionality of a certain type that one might require.
I'm afraid that you are mixing up implementation and design.
Posted by: Keith Harrison-Broninski at October 10, 2006 09:11 AM
Keith, very nice post.
How do you see traditional BPMS vendors supporting a more object-based process management approach? Which tools are more "object-friendly" now and which do you guess will follow that path in the near future?
Posted by: Luis Bender at November 8, 2006 09:16 AM
Thanks Luis.
I have to be honest, and say that I have not seen any BPM tool for support of "mechanistic" processes that allows the user to define a high-level, object-based process architecture and use this as a starting point for process modelling and execution.
I think this is because BPM software is, in general, an evolution of workflow software and has inherited the same approach, i.e., to define what Computer Scientists call "automata". What I am trying to say in these posts is that:
- Automata are very useful - in their place. But real organizations are a lot more than a collection of automata!
- Therefore, if we wish to realize the potential of technologies like SOA and BPM, we need a new tool layer.
Posted by: Keith Harrison-Broninski ![[TypeKey Profile Page]](http://www.ebizq.net/blogs/it_directions/nav-commenters.gif)
at November 8, 2006 11:28 AM
Keith,
The guys from inStream are developing a very interesting toolset (http://www.instream.co.uk/instream/products.jsp) to fully support Martyn Ould's RIVA method. Have you already checked it?
Posted by: Luis Bender at November 13, 2006 07:57 AM
Martyn pointed me at it a while ago. Yes, inStream are building Riva-based tools, but their tools do not provide process execution in "BPM style", i.e., the process description itself cannot be used to drive execution. Rather, you have to use their "Automator" tool to export an inStream model into a separate toolset of your choice, in which software developers then need to complete, compile and deploy an executable version. This is all quite old-fashioned, really - and probably not what people expect from a modern process support solution!
Posted by: Keith Harrison-Broninski at November 13, 2006 08:25 AM
I wonder how big is the problem raised here for current "automata" support being offerend by BPM tool. My understanding is that the value that Riva' process architecture add is "deteterministic" way for defining high-level process view of the organisation paying special attention to process interactions. This is a real benefit over hierarchy based process architecturs which suffer from lack of "hooks" that modeling team can handle when trying to find a starting points. Of course there's nothing "for free". Another problem of fining ebe's, dbe's, uow's arises...but at the end the balance is "in plus" (in my opinion, at least). But when we go from architecture to process descriptions, I feel it is possible to use current BPMS to some extend to support non-sequential process architectures, assuming at the very early stages of process threads modeling that the organisation is more event-driven that control-flow-driven. BPMN offers quite good support for managing events and except lack of support for "explicit communication" that RAD offers most of the constructs can be modelled using the modeling language that BPMS tools "understand".
My experience in modelin these event-driven organisation using Catalyst notation (which is much more ascetic comparing to BPMN and thus required a lot of our own conventions) shows that the models can be constructed this way without loosing the process-interaction features.
This leads me to the conclussion that Riva & HMI adds value to current BPM practices (when I read Riva book I concluded I am not alone here and my suspection and practices that were always against what consultants from well-known consultancy factories claimed can be right; or not-so-wrong) but they do not revolutionize the approach.
If I lost with my conclusions & suspection I'd welcome any comments.
Posted by: Artur Kasprzyk at January 4, 2007 05:41 AM
Artur
It's important to distinguish various things:
- The process architecture aspects of Riva. These are also used in Human Interaction Management (HIM).
- The process modelling aspects of Riva. These are not used in HIM, since as you say they offer only marginal value-add to current BPM practices based (say) on BPMN.
- The process modelling aspects of HIM. Lie Riva, these use Role Activity Diagramming (RAD). However, in HIM the diagramming technique is radically modified to deal with "human-driven" (rather than "mechanistic" processes), to the point where some symbols look similar but it is effectively a new notation. HIM process modelling, like other HIM principles and patterns, really is a step change from conventional BPM practice. HIM offers new solutions, for problems that are not addressed by conventional BPM techniques and tools.
Posted by: Keith Harrison-Broninski at January 4, 2007 06:24 AM
Thank you, Keith, for your comments. While I've read Riva book few times, as in my opinion it is the very first book on BPM that not only say "how good it is to have good process model" but also "how to achieve this nirvana", I met with your approach yesterday and based my conclussions regarding Riva-HIM equivalence only on documents I found on the Internet. It looks I'll have to read HIM book to fully understand your thesis; however it'll take weeks before the book comes to Poland. Is there any place in the Internet that publishes the most important differences between HIM approach and other BPM methodologies/notations that I can read before my fingers touch the book ?
Posted by: Artur Kasprzyk at January 4, 2007 06:40 AM
The best place is the HIM Web site, which includes links to many online articles.
Posted by: Keith Harrison-Broninski at January 4, 2007 07:03 AM
