I'm having some confusion over the difference between these two models and when they're used. The tutorial indicates that applications should be modeled under Application_Provider and that Application should be used to group together providers (such as multiple modules within SAP). I'm cool with that part and the tutorial and example repository seem to indicate that having an Application instance is optional.
I'm running into confusion modeling from the business to application layer that I don't understand and need help. The Business_Capability links to the Business_Process (a Business_Process_Type) - no problem here. The Business_Process_Type links to the Application (via APP_APP_TO_BUS_RELATION). But unless I populate an instance of Application for each Application_Provider this Application data does not exist. It seems like a lot of extra work to create Application instances when they don't seen necessary in most cases. I'm wondering if the Application object should be moved under the Application_Provider_Type object and APP_APP_TO_BUSINESS_RELATION should link Application_Provider_Type to the Business_Process. That way I could like the business process to either the application or the application provider.
I may be looking at this totally wrong and there is another linkage I should be using instead.
Application vs Application Provider
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
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:
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
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
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
Essential Project Team
Thanks for the reply - it was very helpful.
The approach I'm taking so far has been to batch load the Level 1 and 2 APQC process as Business Capabilities. I've them loaded the APQC Level 3 processes as [logical] Business Processes linked to the capabilities. It's going to take me a long time to discover the physical processes so I also loaded the level 3 processes as physical processes (linked to the logical process) to make the model work. I can replace them as I discover the actual business processes used.
I do have a pretty good portfolio inventory and intend to load them as Application Providers. I believe I can then begin to construct the Application Services and link them to the placeholder business processes. I do have a pretty good idea for what each application is used for today. I should be able to get some useful reporting out at this point.
When I get that far; I plan on updating the Physical Business Processes and Application Services as I discover them. I can also turn loose the technology guys to enter their models (deployments and technology stacks).
I still think the two reports provided (Bus Cap Supported by App Services & Bus Cap Implemented by Business Processes) are inconsistent. One uses processes at the logical and the other at the physical. I'll go back and reread you pose a couple more times to see if the light bulb comes on.
Thanks
The approach I'm taking so far has been to batch load the Level 1 and 2 APQC process as Business Capabilities. I've them loaded the APQC Level 3 processes as [logical] Business Processes linked to the capabilities. It's going to take me a long time to discover the physical processes so I also loaded the level 3 processes as physical processes (linked to the logical process) to make the model work. I can replace them as I discover the actual business processes used.
I do have a pretty good portfolio inventory and intend to load them as Application Providers. I believe I can then begin to construct the Application Services and link them to the placeholder business processes. I do have a pretty good idea for what each application is used for today. I should be able to get some useful reporting out at this point.
When I get that far; I plan on updating the Physical Business Processes and Application Services as I discover them. I can also turn loose the technology guys to enter their models (deployments and technology stacks).
I still think the two reports provided (Bus Cap Supported by App Services & Bus Cap Implemented by Business Processes) are inconsistent. One uses processes at the logical and the other at the physical. I'll go back and reread you pose a couple more times to see if the light bulb comes on.
Thanks
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
Hi Gary,
Great to hear about how you're using Essential. All sounds good.
On the inconsistency you mention between those 2 reports, they are providing two different perspectives on how Business Capabilities - WHAT the business does / needs to do, not how.
The Business Capabilities implemented by business processes, shows HOW the business capabilities are implemented in the organisation by the business processes. Having established the supporting processes, the report then navigates through the relationships that we discussed the other day to show the Application Providers that support each process and the Technology that is used to deliver those Applications.
The idea is to give a more business process oriented view of how the business does what it needs to, with a view to the applications that are required.
The Business Capabilities Supported by Application Services follows the same navigation from Business Capabilities, through how they are implemented by processes and but presents the Application Services that are required to support the processes that implement the Capabilities. The Application Providers that implement each relevant Service are then shown.
The idea with this report is to take a more 'Application' perspective on how the Business Capabilities are supported.
Both reports use the same instances and navigate the same relationships, but provide a slightly different lens onto the knowledge base. The Business Capabilities provide a high level context as to which parts of the business are affected.
I realise that at first glance, these two might look confusing or extremely similar. They were created in response to specific request from an Essential client who wanted to be able to show different navigations through the business and application architectures.
Hope this helps
Keep in touch with how things are going
Jonathan
Great to hear about how you're using Essential. All sounds good.
On the inconsistency you mention between those 2 reports, they are providing two different perspectives on how Business Capabilities - WHAT the business does / needs to do, not how.
The Business Capabilities implemented by business processes, shows HOW the business capabilities are implemented in the organisation by the business processes. Having established the supporting processes, the report then navigates through the relationships that we discussed the other day to show the Application Providers that support each process and the Technology that is used to deliver those Applications.
The idea is to give a more business process oriented view of how the business does what it needs to, with a view to the applications that are required.
The Business Capabilities Supported by Application Services follows the same navigation from Business Capabilities, through how they are implemented by processes and but presents the Application Services that are required to support the processes that implement the Capabilities. The Application Providers that implement each relevant Service are then shown.
The idea with this report is to take a more 'Application' perspective on how the Business Capabilities are supported.
Both reports use the same instances and navigate the same relationships, but provide a slightly different lens onto the knowledge base. The Business Capabilities provide a high level context as to which parts of the business are affected.
I realise that at first glance, these two might look confusing or extremely similar. They were created in response to specific request from an Essential client who wanted to be able to show different navigations through the business and application architectures.
Hope this helps
Keep in touch with how things are going
Jonathan
Essential Project Team
