The other day I heard Thomas Kurian talking about the future of the Oracle technology stack. Among other things, he mentioned the Oracle BPA Suite and the Oracle BPM Suite (fka BEA AquaLogic BPM). According to Thomas, the "structured" BPA Suite aims at rigorous process modeling and simulation, where the "agile" BPM Suite aims at iterative process modeling.
Methodological me tended to hear that he was saying that the BPA Suite was more suited for plan-based development, where the BPM Suite would better support agile development. Knowing both of these tools, I found that a somewhat rigorous statement by itself, so I dug into the subject somewhat more.
Yes, the Oracle BPA Suite has a huge amount of modelers and an astronomical amount of symbols. And yes, being able to use the tool to its full extend requires a learning curve that looks the inverse of the stock markets of these days. But does that mean you cannot use it in an agile way? Not really, because being agile is less about how long it takes to learn something, but more about being able to apply it to create new or change existing software.
On the other hand, would the Oracle BPM Suite not be suitable for rigorous process modeling and simulation? Again I don't see why. You could easily have a very rigorous way of developing systems with strict procedures to follow, including an extensive QA process and still use a tool like the BPM suite.
Maybe we need to have a look at the subject from a different angle. Let's start with a limited feature comparison. Limited in that I restrict it to a development environment based upon a SOA with a focus on the high level topics of the models that are supported, how Governance can be enforced, and the type of systems that you can build.
Models and Governance
In a nutshell, with the BPA Suite you can start by defining business processes from a high-level context diagram up to a detailed design. At the higher levels you can use Value (Added) Chain Diagrams, or VACD's for short, that at a specific point map on BPMN diagrams. Those BPMN diagrams can then be transformed into a BPEL design, which finally can be implemented using JDeveloper. The higher-level modeling can be done by Business Analysts while the detailed BPMN model typically will be done by someone with a developers background.
With the BPA Suite you can define roles and restrict access to specific modelers of the tool. This allows you to implement a rigorous Governance model you might have, where the responsibilities for the different roles are well supported by the tooling.
With the BPM Suite you can define processes using BPMN (or similar notation, each being just another view on the same source). Next to that three different "profiles" are supported: Business Analyst, Business Architect, and Developer. The only difference being that a Business Analysts sees the least and a Developer the most details of the same process.
Unless you start doing really fancy things, the BPM Suite does not support a rigorous Governance model as far as responsibilities are concerned, as nothing prevents a Business Analyst from changing his profile to developer to see what has been coded under the hood and even change that.
So the BPA Suite supports a rigorous enforcement of Governance and capturing of requirements, where the Suite BPM supports that hardly if at all. But as such I don't want to call that an "agile" aspect of the BPM Suite.
Regarding Governance, there is one other significant difference. The BPA Suite itself does not result in an executable model. BPMN can be transformed to BPEL, but that is only a blueprint. After sharing the blueprint with development (as it called), a developer picks up the BPEL blueprint and implements it.
The BPM Suite leverages XPDL which provides a means to draw business process models, but also is an executable model. So for the BPA Suite you could say there is a strict hand-over from design to implementation, where with the BPM Suite there is no such thing.
Type of Systems
Currently the BPM Suite clearly is coupled to BPEL. In our practice BPEL is heavily used to integrate systems, with little to no human workflow involved. But that does not mean that you cannot use it for processes that almost completely involve human interaction, and in practice it probably will.
Although at first sight the BPM Suite primarily seems to target processes that involve human interaction, nothing will keep you from developing processes that are fully automated. BPM processes can be deployed as services with a WSDL interface, and call other services, allowing it to be used for service orchestration only.
My conclusion is that regarding the type of system you can build, there is not really a significant difference between the two. Although with the BPM Suite it is much easier to create a user interface than with the BPEL human workflow. But are processes with a lot of human interaction agile and processes that are not rigorous?
Conclusion
When talking about rigorous versus agile and iterative, the significant difference I see is that with BPM it is hard if not impossible to build a solid wall between analysts and developers. And yes, it is true that agile development methodologies do promote breaking down that wall wherever possible.
By the way did I already say sorry for the lack of pictures this time? No? Sorry!
Friday, October 24, 2008
Thursday, October 09, 2008
AIA & Canonicals, Just Good Friends?
Last time I talked about the Canonical Data Model (CDM) pattern. What I haven't discussed yet, is how this pattern is implemented in the Oracle SOA Suite.
Actually the SOA Suite itself does not explicitly support this pattern, simply because enforcing any specific data model should not be seen as the task of any infrastructure tooling, including the SOA Suite. Nevertheless, the concept of a common data model can very well be implemented for specific industries. The goal being that parties in that industry can communicate more easily because by using a CDM they actually talk a common language, at least to some extend.
This concept already is being used in various "industries". Examples are CDM's for governments allowing central and local governments to exchange information with each other about their citizens. CDM's in the health care industry allow doctors, insurance companies and other stakeholders to exchange information about patients.
More recently, Oracle introduced the Application Implementation Architecture or AIA for short. As in the communication about it the focus seems to be on the common process aspect perhaps a little bit of a hidden feature of AIA, but the industry foundation packs of AIA could not exist without the CMD's they are based upon. Perhaps the common data model is of even greater value than the common process.
Once defined a CDM should be accessible by every process that is making use of it, preferably by means of XML schemas. In case of the SOA Suite, rather than importing (and with that copying) the schemas in each and every BPEL project, a way to do this is by including all coherent XML schemas of a CDM in one single, dummy BPEL process, as explained by Marc Kelderman.
Actually the SOA Suite itself does not explicitly support this pattern, simply because enforcing any specific data model should not be seen as the task of any infrastructure tooling, including the SOA Suite. Nevertheless, the concept of a common data model can very well be implemented for specific industries. The goal being that parties in that industry can communicate more easily because by using a CDM they actually talk a common language, at least to some extend.
This concept already is being used in various "industries". Examples are CDM's for governments allowing central and local governments to exchange information with each other about their citizens. CDM's in the health care industry allow doctors, insurance companies and other stakeholders to exchange information about patients.
More recently, Oracle introduced the Application Implementation Architecture or AIA for short. As in the communication about it the focus seems to be on the common process aspect perhaps a little bit of a hidden feature of AIA, but the industry foundation packs of AIA could not exist without the CMD's they are based upon. Perhaps the common data model is of even greater value than the common process.
Once defined a CDM should be accessible by every process that is making use of it, preferably by means of XML schemas. In case of the SOA Suite, rather than importing (and with that copying) the schemas in each and every BPEL project, a way to do this is by including all coherent XML schemas of a CDM in one single, dummy BPEL process, as explained by Marc Kelderman.
Monday, October 06, 2008
The Case for Canonicals
You might have heard people talking about a "Canonical Data Model" or CDM for short. You might have even heard the rumour that having a CDM is critical success factor in achieving the true benefits of a Service Oriented Architecture. But in the meantime you still have to encounter the first situation in which it actually is being used. Is a CDM really a must-have or just another buzzword?
First let me try to explain what a CDM actually is, apart from just being one of the integration design patterns. In short you could say that a canonical data model provides a generic view on the structure of data that systems deal with, like for example a generic concept of what a Customer is, what attributes it should have and the data types and formats of those attributes are.
It might surprise you that having a common view of an entity like "Customer" often is far from common practice. Imagine a big organization like a bank having many systems with different purposes, because of merges often from different companies. Such an organization can easily have as many definitions in their data dictionary of "Customer" as they have systems that deal with customers.
Now what if such an organization needs to integrate all these systems with SOA using XLM transformations for that? If there are N systems to integrate, than in principle there are N * (N - 1) mappings possible for each type of Customer. In case of 4 systems that need to exchange customer data, that already means 12 mappings, as you can see in the following picture. But if you define one generic definition and map to and from that definition, than the maximum number of mappings are 2 * N. In case of 4 systems that means only 8.
A larger bank easily has hundreds of applications with dozens of different definitions of "Customer", let's say 30. Then the difference is 870 versus 60! And that is only for Customer, and there are plenty of other entity types that needs to be exchanged as well, like Account, Address, etc. You get the picture?
So the incentive to use the Canonical Data Model design pattern, is to reduce the number of mappings and with that the inter-dependency between systems, the complexity of the overall integration and, last but not least, the maintenance of all that. For larger organizations this can make a huge difference.
Having said all this, it probably never is the case that all systems need to integrate to each other, let alone that this all the time requires a two-way mapping of every entity involved. To know if an entity should have a definition in a CDM, it depends in how many mappings it will be involved in. When there are more than three systems that all need to exchange an entity in a bi-directional way, than a canonical definition of the entity starts to make sense.
The case against canonicals is that in some organizations it might prove to be far from trivial to get a common view of how the generic definition of a specific entity should look like.
First let me try to explain what a CDM actually is, apart from just being one of the integration design patterns. In short you could say that a canonical data model provides a generic view on the structure of data that systems deal with, like for example a generic concept of what a Customer is, what attributes it should have and the data types and formats of those attributes are.
It might surprise you that having a common view of an entity like "Customer" often is far from common practice. Imagine a big organization like a bank having many systems with different purposes, because of merges often from different companies. Such an organization can easily have as many definitions in their data dictionary of "Customer" as they have systems that deal with customers.
Now what if such an organization needs to integrate all these systems with SOA using XLM transformations for that? If there are N systems to integrate, than in principle there are N * (N - 1) mappings possible for each type of Customer. In case of 4 systems that need to exchange customer data, that already means 12 mappings, as you can see in the following picture. But if you define one generic definition and map to and from that definition, than the maximum number of mappings are 2 * N. In case of 4 systems that means only 8.
A larger bank easily has hundreds of applications with dozens of different definitions of "Customer", let's say 30. Then the difference is 870 versus 60! And that is only for Customer, and there are plenty of other entity types that needs to be exchanged as well, like Account, Address, etc. You get the picture?
So the incentive to use the Canonical Data Model design pattern, is to reduce the number of mappings and with that the inter-dependency between systems, the complexity of the overall integration and, last but not least, the maintenance of all that. For larger organizations this can make a huge difference.
Having said all this, it probably never is the case that all systems need to integrate to each other, let alone that this all the time requires a two-way mapping of every entity involved. To know if an entity should have a definition in a CDM, it depends in how many mappings it will be involved in. When there are more than three systems that all need to exchange an entity in a bi-directional way, than a canonical definition of the entity starts to make sense.
The case against canonicals is that in some organizations it might prove to be far from trivial to get a common view of how the generic definition of a specific entity should look like.
Subscribe to:
Posts (Atom)
