Is there a class to capture data flows between enterprise applications (f.i. a goods receipt entered in a warehouse management system to be transferred to an accounting system) or between external bodies and enterprise applications (f.i EDI invoices) ?
Thanks in advance.
Modelling data flows between applications
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
Hi Eric,
Thanks for your post.
Yes, there are classes to capture how information is exchanged between application things. I'm going to set out some options for how to do this, depending on what you are actually trying to capture.
1. Application Service / Application Provider Dynamic Architectures
For the most detailed and accurate representation of what the application systems are doing, this is available at 2 different levels of abstraction in the Logical Application Layer - Application Services and Application Providers.
Application Services are used to represent your 'ideal' or logical applications - e.g. as you described, Warehouse Management System, Accounting System and if you have a service-based / service oriented application architecture represent your services. We might have several actual applications providing these services (Application Providers) but we'll come back to them in a minute.
Each Application Service can have Application Functions which represent the behaviour of the service. Each of these Functions can take Information Views as an input and return Information Views as an output. i.e. what do you need to supply to the function for it to be done - e.g. 'Enter Goods Receipt' on the Warehouse Management System - and what you get back when it's done.
We can then define a Dynamic Application Service Architecture for that Application Function to capture what happens in terms of other functions being invoked on Services when that Application Function operates. We use a sort of Collaboration Diagram approach to this, so you can define sequence numbers etc. to clearly define the flow. Each arc on this diagram can capture the information sent and received in that step of the flow.
Integration solutions, e.g. the integration that takes the receipt from the WMS to the accounting system, are captured as application things, as they are just a special type of application.
At a lower level of abstraction, Application Providers represent the actual systems in your organisation, e.g. your implementation of SAP FI/CO that provides your Accounting System Application Service. It's possible that you have multiple Providers for a Service, e.g. you might also have an implementation of CODA as an accounting system. In an analogous way to the Application Service, each Application Provider has Application Function Implementations that are used to capture how the Application Functions are provided. Typically, these would be the transaction / API call / screen / function in the packaged application that performs that behaviour.
Each Application Function Implementation has a CRUD section to capture the Information Representations that are created, read, updated, deleted by the function implementation.
These function implementations can also have Dynamic Application Function Implementation Architectures define which capture the dynamic behaviour (flow) of what happens when that function runs. Again, each arc on the diagram can capture the information that is sent and received.
Have a look at the sample repository at the Application Service, Application Function, Application Provider and Application Function Implementations for some examples. Sadly, I don't think there are any example Dynamic models in there.
Note that there are 2 different types of arc that you can define in the dynamic models.
Another, simpler alternative for understanding the flow of data is to define the process flow for what the applications are doing. Each arc on the process flow can capture the information that is sent to the next step. I appreciate that this probably doesn't get close enough to the applications for your requirements
3. Static Application Service / Application Provider Architectures
In addition to the dynamic models for the functions, a higher level static architecture can be defined for each Application Service and Application Provider. There are some examples of these in the sample repository.
These are used to capture - at a coarse grain - the dependencies between applications (at either the service or provider level of abstraction). However, currently, the arcs on these models do not provide an attribute to capture the Information that is exchanged in the dependency.
The background to why this is the case is that potentially each would have to capture all the Information Views/Representations that are exchanged between the applications but there would be no context as to when a certain View is exchanged but another is not, for example. This is exactly what the dynamic models in section 1 do provide. If we have them in the static models as well, then we are potentially duplicating knowledge about the applications and could provide inconsistent information in the Essential Viewer reports.
Hopefully this rather long explanation helps. I think the answer is really in the Dynamic models. Please don't hesitate to post back if you have any further queries or issues with this.
Jonathan
Thanks for your post.
Yes, there are classes to capture how information is exchanged between application things. I'm going to set out some options for how to do this, depending on what you are actually trying to capture.
1. Application Service / Application Provider Dynamic Architectures
For the most detailed and accurate representation of what the application systems are doing, this is available at 2 different levels of abstraction in the Logical Application Layer - Application Services and Application Providers.
Application Services are used to represent your 'ideal' or logical applications - e.g. as you described, Warehouse Management System, Accounting System and if you have a service-based / service oriented application architecture represent your services. We might have several actual applications providing these services (Application Providers) but we'll come back to them in a minute.
Each Application Service can have Application Functions which represent the behaviour of the service. Each of these Functions can take Information Views as an input and return Information Views as an output. i.e. what do you need to supply to the function for it to be done - e.g. 'Enter Goods Receipt' on the Warehouse Management System - and what you get back when it's done.
We can then define a Dynamic Application Service Architecture for that Application Function to capture what happens in terms of other functions being invoked on Services when that Application Function operates. We use a sort of Collaboration Diagram approach to this, so you can define sequence numbers etc. to clearly define the flow. Each arc on this diagram can capture the information sent and received in that step of the flow.
Integration solutions, e.g. the integration that takes the receipt from the WMS to the accounting system, are captured as application things, as they are just a special type of application.
At a lower level of abstraction, Application Providers represent the actual systems in your organisation, e.g. your implementation of SAP FI/CO that provides your Accounting System Application Service. It's possible that you have multiple Providers for a Service, e.g. you might also have an implementation of CODA as an accounting system. In an analogous way to the Application Service, each Application Provider has Application Function Implementations that are used to capture how the Application Functions are provided. Typically, these would be the transaction / API call / screen / function in the packaged application that performs that behaviour.
Each Application Function Implementation has a CRUD section to capture the Information Representations that are created, read, updated, deleted by the function implementation.
These function implementations can also have Dynamic Application Function Implementation Architectures define which capture the dynamic behaviour (flow) of what happens when that function runs. Again, each arc on the diagram can capture the information that is sent and received.
Have a look at the sample repository at the Application Service, Application Function, Application Provider and Application Function Implementations for some examples. Sadly, I don't think there are any example Dynamic models in there.
Note that there are 2 different types of arc that you can define in the dynamic models.
- From the application [provider/service] to the function, which shows an application calling a function and exchanging information
- From the function to the application [provider/service], which shows that this function is being provided by the application
Another, simpler alternative for understanding the flow of data is to define the process flow for what the applications are doing. Each arc on the process flow can capture the information that is sent to the next step. I appreciate that this probably doesn't get close enough to the applications for your requirements
3. Static Application Service / Application Provider Architectures
In addition to the dynamic models for the functions, a higher level static architecture can be defined for each Application Service and Application Provider. There are some examples of these in the sample repository.
These are used to capture - at a coarse grain - the dependencies between applications (at either the service or provider level of abstraction). However, currently, the arcs on these models do not provide an attribute to capture the Information that is exchanged in the dependency.
The background to why this is the case is that potentially each would have to capture all the Information Views/Representations that are exchanged between the applications but there would be no context as to when a certain View is exchanged but another is not, for example. This is exactly what the dynamic models in section 1 do provide. If we have them in the static models as well, then we are potentially duplicating knowledge about the applications and could provide inconsistent information in the Essential Viewer reports.
Hopefully this rather long explanation helps. I think the answer is really in the Dynamic models. Please don't hesitate to post back if you have any further queries or issues with this.
Jonathan
Essential Project Team
