[My new column on BPMInstitute.org]
Lacking support for fundamental concepts like human tasks and subprocesses, BPEL has become a favorite whipping boy of BPM vendors and consultants. But for all its faults, BPEL enjoys something that BPMN advocates can only dream about: an XML storage and interchange format that makes sense. It?s often said that BPEL is an XML language not a graphical notation, but the reality is that graphical BPEL design tools all use more or less the same notation, based on a simple mapping to native BPEL language constructs: Receive, Reply, Invoke, etc. BPMN has a standard notation, but still lacks a standard storage and interchange format consistent with the fundamental goals of BPMN itself.
I?ve been thinking about this recently with the announcement from OMG that the ?official? XML format for BPMN, based on OMG?s new Business Process Definition Metamodel (BPDM), is in its final stages of ratification. Besides BPDM, Intalio has developed an alternative XML format for BPMN and has contributed it to the Eclipse Foundation. And let?s not forget XPDL 2.0, the Workflow Management Coalition?s reworking of its old process interchange warhorse to encompass various pieces of the BPMN spec. But to me, none of these proposals is as satisfying as BPEL?s approach, which makes the XML format closely match the terminology and semantics of the process constructs, their target audience, and business purpose.
One possible reason for this is that BPEL is considered a ?language? while BPMN just a ?notation,? i.e. a drawing format. But any student of my BPMN training (www.bpmessentials.com) ? or anyone who has glanced at the BPMN spec ? can tell you that BPMN is far more than a Visio stencil. The various shapes and lines have specific meanings and rules behind them, and both the shapes and the rules were developed for the purposes of process modeling, independent of an underlying execution language for implementation. (BPMN does assume the runtime engine can support events that interrupt tasks and subprocesses, a natural feature of SOA-era engines missing in some traditional workflow engines.)
Process modeling is inherently a business function that does not require understanding of the technical detail of the implementation. In order to be universally understood by business process analysts, BPMN has only three basic shapes ? activity (a step in the process that performs work), gateway (routing control logic), and event (a signal that something has ?happened?). That?s it, just three. But with a few standard subtypes of these three basic shapes, BPMN is also precise enough to support detailed simulation analysis, and in tools like Appian, Lombardi, Savvion, or Intalio, the front end of executable design as well.
Much of the energy behind adoption of BPMN as a standard is in fact uptake by the BPM suite vendors as a design front end. Its advantage is that it supports a new rapid iterative implementation style based on continuous business/IT collaboration, instead of the alternative ?handoff? style in which changes made in the executable design environment can get out of sync with the model (the notorious ?round-tripping? problem). But we should not lose sight of the fact that BPMN is first and foremost a modeling notation, intended for use by business.
What?s always been missing in BPMN has been portability, the simple idea that a valid model drawn in tool A can be imported into tool B with the assurance that it will still ?work?. To me that means two things we don?t yet have: 1) a specified subset of the BPMN shapes (including subtypes and their attributes) that must be supported; and 2) a unique and unambiguous mapping from the diagram to XML. With BPEL we have neither of these problems. You need to support all of it to be compliant, and BPEL itself defines the XML. In other words, BPEL is a ?language.? (The penalty BPEL pays for this is that the language does not include everything you need, but that?s another story.)
So what would BPMN as a language look like? The logical thing would be to have, underneath the process element, things like activity, gateway, and event. Also, you would need elements like pool, sequenceFlow, and messageFlow, other core BPMN concepts. The mapping between the graphics and the XML would be simple and unambiguous. The metamodel, or interrelationship of these concepts, is already defined in the BPMN 1.0 spec narrative, which is essentially unchanged in three years. The detailed semantics of that metamodel, while perhaps not something you can plug into a developer tool like Eclipse, is precise enough to serve BPMN?s primary purpose, which is process modeling by business. More precise semantics required for detailed process execution or model-driven architecture, could be layered on afterward in the design environment.
The benefits of treating BPMN as a language would be twofold. The first benefit is guaranteed portability of models. This is so absolutely fundamental it?s amazing that BPMN has gotten as far as it has without it. The second benefit is reinforcing to process modelers that there are precise semantics and rules behind the BPMN shapes. People naturally accept there is some rigorous structure behind a language, but somehow think that graphics can mean whatever you want them to mean. The language would not impose constraints such as BPEL?s block-oriented structures on the process modeler ? you can still freely connect anything to anything (more or less) ? but users might be more inclined to learn the rules, and tools would provide validators that make it easier to follow them.
My problem with both BPDM and the Intalio efforts to date are that they are not designed for process modelers, but for developers using Eclipse. Both complicate the modeling ?language? with artifacts of Eclipse?s inherently non-business-friendly model-driven architecture, called EMF. In other words, the XML schema for BPMN is not designed to be a simple tool-independent reflection of the ?language?, but instead something that an Eclipse-based BPMN tool can leverage, along with EMF, to generate executable code. That?s a different purpose entirely.
How does this ?pollute? the schema? Well, for instance, instead of having separate activity, gateway, and event datatypes, the Eclipse Foundation schema includes them all in a single element called vertices. Why? Because each XML element type in the schema generates 15 Java classes using Eclipse MDA, and if you had a ?sensible? schema the implementation code would be too unwieldy. In other words, the Java tail is wagging the BPMN dog. I suspect the BPDM serialization will be even worse from a business modeling perspective. So far the schema they have published is not even valid per the XML schema language, and contains no root elements, something needed by any XML tool (but maybe not by Eclipse).
XPDL 2.0, on the other hand, is based on ?real? XML, but it does not use the language of BPMN. Recall that XPDL originally was intended as a generic interchange format between 100 proprietary workflow tools. To support BPMN, XPDL 2.0 essentially enlarged it to 101. In other words, XPDL guarantees there is a place to stuff any BPMN shape, line, or attribute, but the schema does not reflect the BPMN metamodel, terminology, or semantics. This still might be the best option, but with so many different places to stuff the info, it?s not clear that the BPMN-to-XPDL mapping is unique, i.e. portability without a side agreement between tool vendors may not be assured.
A commonly accepted portability standard for BPMN is still just out of reach. To be fair, both BPDM and the Intalio efforts are still work in progress, and WfMC could always tweak XPDL if they sense an opportunity. I think if we began to think about BPMN as a language instead of just a drawing format, it might show a clearer path to the desired end result.
Tags: BPMN
I have been using BPMN to model business processes for about 2 years and has proven to be a much better tool than a basic process flow diagram or a UML activity diagram. BPMN defines a variety of symbols which are ubiquitous – this ensures that the meaning intended by the modeler is clearly communicated to the reader.
Bruce,
What’s your definition on portability? does it mean making it machine-readable or human-readable? I know that XML by definition aims to both targets, but I’m not sure why would we have to come up with an XML schema understandable enough for our end users, the process modelers, if the ultimate goal is to enable portability among tools. If these are mature enough, who will ever need to open XMLSpy and look at the mumbo jumbo code? I think even a pretty xml file will look weird to the eyes of a business analyst. That’s why I wouldn’t hesitate on relying on EMF to produce a schema (or shall we say, a metamodel) for BPMN.
Bruce,
The difficulty with making BPMN a language is to define exact execution semantics. I think that the BPM industry is not yet able to handle the dual nature of BPM. See also The Schizofrenic Nature of BPM. Much focus goes to the non tech business analysts. They describe a business process graphically. From their point of view, they are create a description of how they see people and systems work together. Tools like visio, ARIS (without an execution engine coupled to it) or BPMN can give the ultimate modelling freedom to the analysts.
IMO, things get very different if 1 diagram has to serve both as the analyst description and as the basis for the implementation of a software system. That is where currently the technical aspects of making business processes executable are completely ignored. Describing a process is not the same as implementing software support for that process. In some cases, there can be 1 diagram to support both. But from the moment that 1 diagram supports both analysis and implementation, there are restrictions on both sides. The analysts will not have complete modelling freedom any more. They will (also) have to think about the runtime behaviour when they are modelling. On the other hand, to make processes executable, developers should be able to add technical details, preferrably, without impacting the diagram representation of the process.
I don’t think the software industry is waiting for the ultimate process language. The ongoing divergence is to me a big indication that such a language will not be possible.
What we DO need is a common model for all those process languages. Just like the relational databases have a common model that every developer knows with tables, columns, primary keys, foreign keys, join queries and so on.
Such a model must take into account the dual nature of BPM Systems: Graphical diagram representation for the business analyst on the one hand and technical details for the developer to make processes executable on the other hand.
Both MS with their Windows Workflow Foundation and we at jBPM with ‘The Process Virtual Machine’ have come independantly to a *very* similar model: a framework in which the process constructs are pluggable programmable components. It provides with a common model that is easy to understand (in essense: a process is a graph and an execution is a pointer to where you are in the graph). Process languages can be build on such a model as a set of node construct implementations. This also makes it much easier to integrate process technology in software development projects, whereas now BPM technology is mostly considered a stand-alone technology.
I believe that such a model will be key to taking BPM technologies to the next level of adoption. The current fragmentation and confusion can only be adressed by a common understanding of what BPM is by the majority of software developers. Currently I’m in the process of simplifying and revamping the concepts of ‘Graph Oriented Programming’ into a new article called ‘The Process Virtual Machine’.
Portability in the BPM world seems to mean different things to different people.
On one hand there is portability of the model. I model my process in one tool and bring it up in another without any loss in translation and with support for round trippping (e.g. BPMN + BPDM or BPMN + XPDL? etc.). While this is great to visually represent and understand the process, the reason BPM tools exist is not just to visually represent processes, it is to also execute processes. End of the day if you are not going to model a process, execute it, understand bottlenecks, KPIs, reengineer it etc. then you are missing out on the real value of BPMS.
So, another expectation of portability is that I don’t care about the modeling aspect as long as I can execute it in different engines (e.g. BPEL).
The ideal expectation of portability is true end to end portability. The ability to take a process modeled in one tool, view it in another, make changes and execute it in a 3rd with round tripping. If we really want portability that is practical then this is the level of portability we should expect.
This being the case for true portability one needs the ability not just be able to port the models but also the additions made to the code to make it execution ready. If we look at how BPM vendors approach this today (especially the ones that promote XPDL), once the process has been modeled they add the integration code, forms, conditions, rules etc. so that the XPDL now generated (with proprietary extensions) can be executed in their XPDL engines. Since there is no execution language for XPDL, there is no standard based XPDL engine a model that started out as being portable is very quickly reduced to being vendor specific once we add all the execution specific constructs to the model.
The alternative seems to be BPEL (with BPMN?). With BPEL 2.0 now ratified there seems to be renewed buzz about BPEL. Now that it is a standard, there seems to be this expectation that it will support portability. The ability to take a BPEL process modeled in one tool and execute it on another. IMO this combination seems to be the one that comes closest to offering any hope of end to end portability.
Where this falls apart is in two places -
1. lack of human interaction, subprocess support, ability to orchestrate more than just web services etc. To overcome these limitations, vendors create extensions so that BPEL can be used as a practical BPM solution, thus ending any hope of portability.
2. Lack of specific implementation details in the BPEL spec where it is left up to the vendor to implement certain aspects of the spec. For example, how should state be maintained? Now this might not affect portability but the chances that a vendor has implemented something a certain way that will not allow portability is pretty high.
This being the case, why is there so much buzz about portability? Why do customers look for portability? What do they think this will get them?
- Vendor independence ?
- Reuse without any rework?
Are either of these realistic expectations? Should we settle for model portability only?
To me the SQL analogy of standards makes a lot more sense. The reasons these standards exist is so that there is knowledge portability. I know how to write SQL and can pretty much be productive in any RDBMS but I cannot take my code and port it. It also helps that there are only a few database vendors around. Similarly knowing BPMN means I can understand a process and model it in any tool.
At this point of time, knowledge portability seems to be a more reasonable expectation. It does seem like BPEL has a better shot in the long term of getting to this nirvana of portability since it at least defines an execution language.
David,
I agree portability, which is the top goal, has nothing to do with whether the schema is human-readable. But when you call a schema “mumbo-jumbo code” you betray your own bias. XMLSpy (or pick XML tool of your choice) was not created so that fuzzy-headed business types could gaze longingly at their XML. A schema provides the basic structure of the serialization. The fact that BPDM still cannot produce a valid one or an instance document is a problem. The fact that neither BPDM nor the Eclipse Foundation schemas contain a root element — something needed by XML tools to create an instance from the schema, to create a mapping for the schema, to create a rendition via xsl of an instance document — that seems to me like a problem as well. Is making BPMN dependent on Eclipse really the best way to define a standard for process modeling?
Tom,
Good points, but I am thinking about BPMN as a “modeling language” not an “execution language.” While many others have expressed similar thoughts that business-oriented modelers don’t want to be constrained by anything at all, the beginnings of success of BPMN is proving that wrong. BPMN has lots of constraints — not as stifling as BPEL, but many constraints and rules nonetheless. Vague as it is in spots, the BPMN 1.0 spec expresses the rules fairly clearly, but even the tool vendors routinely break them. I think if there were a standard serialization clearly mapped to the “metamodel” in the spec narrative, they wouldn’t, and we would also have automated tool-based validation based on BPMN (rather than on the constraints of the simulation engine, BPEL engine, or other downstream processor of the BPMN).
marvrik_eka,
We seem to have a trend going here, i.e. there is no need for portability of business process models since the only thing that counts is the implementation. This is one view, but I would say not the predominant one in the BPM community. I do a lot of speaking at BPM conferences where to most attendees (and speakers), BPM is mostly a management discipline supported by modeling tools. The implementation could be Java or no implementation at all, just a “process-centric view of the business.” That’s not my own perspective, but without accepting that a model can exist and have value independent of an executable implementation you would stand outside of the mainstream of BPM.
Bruce,
So basically you’re view is that BPMN is a modelling language with precise semantics so that the diagrams are more expressive for people that understand the language. Is that right ?
In that case the point of adding a storage and interchange format of BPMN is to check validation and sharing a BPMN model between different modelling tools.
If the complete use case is limited to modeling only, then I’m with you. In that case BPMN should have its own xml schema or something like that.
But in that view and with the current perception of mapping BPMN to executable process languages can only be a one way operation. Once a modeling process is transformed into an executable process, the analyst cannot keep on modeling as free as before. After a process becomes executable, changes to the model should always be done in collaboration with the developer that needs to monitor wether the software will still behave as expected.
So that is why I have a problem with the mappings between BPMN and the executable languages as it is presented now. It gives people the impression that analysts can just model free and the mapping will just automagically generate the desired software for that. While process models can give a skeleton for the software support for business processes, implementing the details is still a necessity.
In that view I see 2 kinds of approaches emerging:
1) The modelling only approach, in which tools like aris and bpmn modellers are used as drawing tools with precise semantics for expressive diagrams. In this approach, there is no automatic coupling between the process models and a software implementation (if there is one). Afaik, still to date, this is by far the main approach of managing business processes.
2) The executable approach. In that case, the process models will be made executable and executed on a BPMS. In this approach, I see the initial diagram input being sketched by the business analyst. Then the developer makes this process executable with the most suitable process language (should be the developer’s choice). The goal is of course that the diagram of the executable process looks as close as possible to the initial input of the analyst. After that, the diagram of the executable process serves as the common language between the analyst and the developer. So that they can point with their finger in the diagram to show what part of the process they are discussing.
regards, tom.
Focusing on model portability is one key aspect. Focusing on portability from an implementation standpoint is another aspect. I am not saying one is more important than the other. As you have stated there are strong reasons to focus on model portability.
That being said, I was wondering if true end to end portability – model + implementation would ever be a reality and if yes what would that look like in the future. With BPEL 2.0 being ratified there seems to be a lot of talk around interoperability and portability of processes as a key advantage. The fact that XPDL is not / does not have an execution language puts it at a disadvantage.
Obviously for customers who want management discipline around their processes this is not relevant but for all the customers buying BPMS tools from IBM, Oracle, BEA, Savvion, Lombardi, Pega, TIBCO etc. where the focus is on modeling and implementation there is some confusion.
From an end to end portability standpoint, is BPMN + XPDL a better long term viable option or is BPMN + BPEL + Extensions (human interaction, subprocesses, WSIF, BPEL4J etc.) a more viable option? In both these cases, would we get round tripping once we take a model and add implementation specific stuff around it? Would we be able to model in one tool, add implementation specific stuff in another, bring it back to the modeling tool and make changes and then execute all without any loss in translation?
Or is end to end portability a pipe dream that will never be achieved and we need to accept that.
Tom,
Your note is very encouraging… the first one that indicates anyone has some idea of what I’m talking about. Yes, portability of process models (as opposed to execulabble designs) is what I’m talking about. But the bit about analysts drawing doodles and expecting some implementation to result is a familiar straw man. I think it’s just false. Many business analysts dont even understand the idea of BPM as a process automation and monitoring platform, i.e. they do not even have the concept of an “executable model.” The ones that do accept (today at least) that the implementation is BPMS-specific, even with BPMN-based tools, like Appian, Tibco, Lombardi, Savvion, Intalio… Still, most of those tools keep the BPMN view in sync with the implementation. What they don’t do is let another tool’s BPMN view stay in sync with their implementation. If the goal of BPDM or the Intalio/Eclipse Foundation efforts is to standardize BPMN at the executable level, that’s interesting but in my opinion not really the primary need of the mainstream BPM community today.
If there were such a pure modeling-focused schema and validation ruleset in existience, I have no doubt it could be unambiguously mapped to BPDM for implemenattion. Any process modeler understands that the implementation platform is going to impose more precise semantics on the model than that modeler had in mind… or, more likely, has any interest in at all.
I got your point now, and the importance on the portability remarks. Mavrik_eka couldn’t do better the wishlist for a BPM modeler.
Yes, I agree a standard can’t be defined based on a particular implementation of a modeling facility, as great as EMF can be. Intalio did propose a schema, but not a standard, which we are still lacking of. Sure they got a really cool BPMS around, but it won’t guarantee that I’ll need to load the models somewhere else to add implementation information and then bring it back.
We have to realize that the OMG created a standard to create modeling standards (intended word repetition), which is MOF (Meta Object Facility). This is what allowed UML to be serialized and hence made XMI possible, letting us exchange models between CASE tools. It did work but not entirely, and still they want to repeat the same story again with business processes. They made BPMN theirs, and now they are building the MOF based BPDM, to allow us (among many other promised features) exchange BPMN models. It’s just that they haven’t published the XML schema (a genius OMG specification reader should be able to put it together by looking at the MOF diagrams in the spec).
An idea that I’m having is to grab Intalio’s schema and rebuild it not on Ecore (which is Eclipse’s MOF reference implementation) but on pure MOF, using pencil and paper if you will. Then you will have a true pure metamodel, and from there on, the standard XML schema is just steps away. Of course, maybe with BPDM’s XML schema this won’t be necessary, so we’ll just have to wait and see. Course of things is getting more and more interesting.
-Juan
Hi All,
I’m a bit puzzled with all this discussion! Firs of all, I’m not used with all these BPEL, MOF and BPDM stuff. I’m currently using BPMN to document Business processes from a business point of view which is I think one of the usages BPMN stands for. Secondly, for me the borderline between process modeling and implementation is not clear and this leads to that schizofrenic perception we can have while tryi!ng to use BPMN.
Currently, I’m struggling with a project where I have to define the requirements to implement a process and I’m coming with this simple example. (Sorry Can’t paste a schema in the comments)
1) Let imagine that within my process I have a task “Define activity planning”. From a business perspective, all I need to know is that a start and an end date will be defined for an activity. Maybe in some simulator I want to be able to define that this task will not last more than 1 hour, will not take too much ressources, …
2) Now from an implementation point of view, I can tell that the start date will either be defined by the end date of some predecessor or that the user will type it in. For the End date, I can say that it will either be calculated from the start date plus the duration or that the user will type it in, the duration being calculated from the two dates.
So far it’s kind of easy!
But looking at the implementation of the start date, I’m now digging back into my process and asking myself what should happen if the predecessor is not defined and trying to model this requirement one way or another! But here the model I have to come with is not that much related to my business but to implementation!
So IMHO, defining a standard and portable XML structure should first bring clarity and specification on the borderline between process modeling and implementation and make it clear I’m documenting from a business perspective or from an implementation perspective.
Thanks and have anice day,
Patrice
Patrice,
In a way your example is a good illustration of the difference between a model and an implementation. As a model, all you might need to record for the task in BPMN is its name and resource. How the calculation of the activity start and end dates is done is an implementation issue; BPMN has no place to store that information anyway. The purpose of the process model is to put that task and resource assignment in context with other tasks, gateways, events, etc in the end-to-end process… independent of those details.
–Bruce
Bruce,
But still my process end user may still define requirements on what they are willing to perform manually and what they expect the tool will compute for them even at this level of details.
And as I can draw a valid BPMN schema for both representations of my example, it is not easy to define where the bordeline is lying.
I’m am kind of fighting with business analysts to have them focusing on the E2E process and not on the implementation of the tool that will support the process. However, at the end we should deliver the requirements for the tool implementation. In this situation it’s a bit me who’s going schizophrenic ;o)
And I guess that at the end, every business analyst as to deliver a diagram that will support/define his requirements on the tool he wants to support his process.
Currently, I’m telling my business analyst to focus on the WHAT (meaning the E2E process) and not on the HOW (meaning implementation) and if such specific constraints are required on the implementation , I ask them to put them in the task documentation.
When you say BPMN has no place to store that kind of information, IMHO, it should to deserve that dubbel vision it supports.
Patrice
Patrice,
You make a good point, that business analysts should be able to put such details in the model. I don’t disagree with that. The problem is that these details are the part that is hard to make portable across tools, unless you are willing to make them essentially text annotations. I said that BPMN has no place to put implementation details. Actually it does provide many attributes for that purpose, including data parameters, messages, etc., nominally for BPEL generation, although the BPMN tools frequently ignore those attributes in their BPEL mappings, and they generally don’t follow the naming conventions used by the BPEL tools, either. Actually, there is no common naming convention across tools. I think what I am trying to argue is that just because BPMN cannot support such implementation detail in a portable way does not negate the need for portability at the abstract model level.
–Bruce
Bruce,
If i’m understanding you well, you say that on one hand portability will be hard to reach regarding implementation model and on the other hand that you look for portability of the abstract model level.
I fully agree with you and would also at least expect that level of portability at Modelling level.
My point is that in today’s communication around BPMN is not that obvious on the goals BPMN tries to achieve often the text talk about implementation while examples are abstract models.
I think it can deserve both puposes but it would help having some guidance on which properties do I need to fill in case of modelling and which in case of implementation.
I will take another example i’m facing. Let say I have to close an activity once it has been performed. That closure will defined a closure code stating whether the activity has been successfull or not. According to BPMN the message is not represented by the event. Saying so, in my process I have one end event (type Message) that will notify the end of my activity process, the message linked to that event containing the status code. While looking for implementation, It appears that in case of success I will apply one type of message while in case of failure I will apply another type of message. As in my tool I can link only one type of message to the end event I’m facing the fact that I need to have a gateway before the end event and then two separate end events to show that implementation.
As a conclusion I would say that there are two different usages of BPMN and the two don’t follow the same “rules” and use the same properties. And so we should first define what kind of usage and then define what kind of portability we expect for that usage.
Patrice
Patrice,
I agree with you that BPMN spec does not do a good job separating attributes needed for execution from attributes needed for modeling. In fact, there are rules that specify certain attributes that I consider implementation-related MUST be populated if some diagram element is drawn. I don’t agree, but see my recent post about IDS Scheer and BPMN — they consider it an executable design notation not a modeling notation.
As for your example, I think you point out an area where implementation detail pollutes the model. It is of course possible to have one message end event representing two different possible messages, one success message and one fail message. At the abstract level, what is to prevent this? When you attach a message attribute to the event, in the case of BPEL generation you might specify a wsdl messageType. Even so, a single messageType could be used for both success and failure messages (as long as they both used the same schema). But if success and fail messages are different messageTypes, then I suppose you would need a gateway and two different end events. This is an example of the kind of implementation-specific restrictions that I think have no place in process modeling. They are strictly design issues, because a different execution language might have different rules. Besides, your BPMN tool’s BPEL generator probably ignores those attributes anyway… all that worrying for nothing!
–Bruce
Patrice, Bruce
If you want to read some “stories from the trenches” on the differences between process models at the level of the “business analyst”, at the solution architect’s level, and at the software developer’s level, I recommend the following experience report from a guy at Danske Bank:
http://www1.itu.dk/graphics/IT.....007-96.pdf
In particular, I like the three types of typical mismatches that he identifies between the “analyst” process models, the “architect” models and the “developer” models:
1) Lack of details about exceptions: “During the initial unit test of the workflow, it turned out that the solution model [given by the architect] only considered the ?main? road of the process, i.e. the process of handling a customer package when everything was as expected. Many exceptions and special cases were not covered.”
2) Activities not broken down sufficiently: ??an activity was described as ?create all cards?. When the developer should implement such an activity, he had to consider if a new service should be developed to create a bunch of cards, if an existing service for creating one card should be called several times in a loop structure, and what should be done in case of failures when creating the cards? Such decisions are not implementation issues; it is decisions that should have been modeled in details in the [high-level] model.?
3) Underspecified dependencies between activities: ?Activities in a process may depend on each other. For instance, an account must be created before creating a card. Such dependencies were not always described explicitly and the developer had to figure out how to organize the control flow. These dependencies should have been described in the [high-level] model.?
4) Missing data (data that is needed but not gathered anywhere): “The architect had not considered which data to use when defining service invocations or user interface based activities. Both activity types may require data that is not present and that has to be retrieved from somewhere else.?