In the first blog of this series I described the positioning of Business Logic in CORA 1.0. where business logic is present in several layers and in several elements but with a different perspective and purpose. I showed that a clear definition of business logic is important, to make a proper mapping between the CORA elements and layers. In this blog I use the IPhone example of Wilco and Maarten (Part I and Part II) to discuss this further, but first I want to elaborate on the way the CORA model is used in this example.
CORA model dimensions
The CORA model is designed to be used as a layered model for an IT landscape AND/OR for a system. So if we look at an IPhone application, we can not only use CORA to position the IPhone application on the IT Landscape (e.g. in the Channel layer) but also to position it on the application/IPhone itself!
In the figure in the blog of Wilco and Maarten I see both dimensions in one view. This could be splitted first and then shown as two different CORA mappings (IT landscape, System) next to each other with a communication line between. So in the first (IT landscape/CORA) view the IPhone is positioned onto the Channel layer within the IT landscape where Channels are only positioned and described to facilitate the information flow between a stakeholder and the IT landscape. In the second (application/CORA) view the IPhone is positioned on several layers depending on the architecture of the application itself.
The application has at least a Presentation Layer, Application Layer, and Data Layer and is using an Integration Layer (to the outside world) probably provided by an IPhone Operating System integration component. It can also only be a Presentation Layer which calls business logic services somewhere else by using the Integration Layer on the IPhone.
Now let’s take a look at the IPhone example to see where the business logic is positioned. In the example they want to create a relationship between recipe ingredients and actual products in stock, and combine allergy information on personal basis. Both the recipes and the product information are systems in the Application Layer, so that is good. But the recipes could also come from an external service, which is integrated in the Integration layer. The allergy information is stored on the Iphone.
A huge challenge in this scenario is the mapping between these three types of information. Do the recipe ingredients match with the product information? How is the allergy information linked to the products and ingredients (or only to one?). Usually there are two options:
- create and maintain the relationship, this will create a new ‘Make’ application and database. Although it introduces integration of updates from the source systems to this new application, it is not recommended to store this information within one of the source systems because of dependencies;
- use of industry standards. If there is a standard on product identifiers which is used in SAP, the recipes and with allergy information, the chances would be much higher to not have to develop a separate relationship store.
Two other subjects I like to mention:
- It is no problem for a supermarket to manage 20K products. Most large supermarkets do this, and have an actual overview of products in stock. The challenge would be to build a platform to provide this data to many many users…
- The authors describe that ‘there is nothing SOA about this scenario’. I do not agree about that. SOA is an architectural style to identify elementary IT functionality, separation of concerns, separation of layers, using standard protocols (vendor neutral), etc. A SOA does not have to be implemented with an Enterprise Service Bus! From a solution perspective, this solution is full of SOA.
- One of the aims of CORA 2.0 is to include the business and social networks in the Cloud. This service, providing mappings between recipes and a product stock system, could also be provided by a Cloud service. This service could be run for many different supermarkets.
I hope this starts a further discussion.
About the author
Joost van der Vlies is one of the co-authors of the CORA Model. He is working at Hewlett Packard in Shanghai, China. The views of this blog are his own and are not related to his employer or its affiliates.