Hi Gary,
Apologies for taking so long to get back to you.
You're right, the purpose of the Application class is really just to group Application Providers that are know by some sort of collective name. For example, I've used this to group different Application Providers that are functional variations (e.g. for different divisions of an organisation) of what is essentially the same solution. In my case, there were actually now, 2 different codebases. However, in the organisation, they both known by the same name. So, I grouped the 2 variations in an Application instance and gave that Application the name that everyone knew.
OK, to clarify the business process to application relationships - and you are not far off.
I can see why you've gone for the relationship between the process and the Application (Groups) and I think I need to provide some more background to how the Business Process Layer relates to the Application Layer.
I'll start by taking a little step back and describing some of the principles that we've included in the meta model. In terms of how Business Processes relate to Applications, we relate Business Processes - which are logical designs of how a process is to be performed - to Application Services (and related Application Functions at a finer grained level of detail). This means that we relate, for example, the 'Take Telesales Order' process with the 'CRM System' and 'Order Management' system (both Application Services) rather than directly to the Providers of those Services (e.g. 'Our Siebel' and 'Our SAP' respectively).
The relationships between the processes and the application providers is done at the Physical Process level. This enables us to be clear about which team performing a [logical] Business Process are supported by which Application Provider.
We can, of course, then report on any inconsistency in the 'implementation' of our application architecture, e.g. in my example 'Team X' performing the 'Take Telesales Order' only use 'Our Siebel' and do not use 'Our SAP'. How are the orders taken?
Part of the motivation for this approach is to instil some element of the 'separation of concerns' between the Business Process and the Application parts of the architecture. If the [logical] Business Process is a specification or a design of how a process is to be performed, we need to map this to a similar level of abstraction in the Application layer. i.e. Application Service, which define our logical Application Architecture in terms of the types of Application that we need to have in order to support our processes. We then buy or build Application Providers to provide these Application Services. At the Physical Process level, we need to decide which application a particular team is going to use, so we relate that to the Application Provider. Note, that Application Providers can then be related to [physical] Application Deployments to reflect things like Production/Test/Development instances etc.
Finally on this, we found that we needed to take this approach so that we could accurately and un-ambiguously model the difference between a shared application (2 teams using the same application but each with their own instance of it to manage - with all the potential for local customisation etc.) and a shared application INSTANCE (2 teams both accessing exactly the same instance of an application).
In the Essential Viewer the analysis reports traverse these relationships to show how - for example a Business Process is actually supported by 2 different Applications [Providers] that might be both doing the same thing (and could be candidates for some rationalisation or standardisation etc.)
Hopefully this gives a bit more insight into why the relationships are setup as they are in the meta model. In summary:
- Business Process <-> Application Service
- Physical Process <-> Application Provider
- Application Service <-> Application Provider
The relationship to the Application Group in the Business Process remains and could be used for things like helping further refine the application architecture but doesn't have the semantics that we require to more accurately capture and report on the architecture. That is where we need the Application Services and the Application Providers.
I don't think you'll have to do too much rework - especially if you are coming at this from the Process end rather than the Application end. Create a simple Application Service (you don't need to define all the relationships) for each of the classes of application that you require, things like CRM System, Order Management System, Financial Accounting System. Then map these to your Application Providers, if you already have them. If you don't, from a process perspective, you won't need the Providers until you capture the Physical Processes.
We find that this approach works really nicely, however, please let us know if you don't agree and we can develop this to meet everyone's needs.
Hope this helps to make things a bit clearer - maybe we need to document some clearer guidelines on how the Application, Application Service and Application Provider classes work.
Jonathan