Hello,
we are considering Protégé and Essential metamodel for our EA. Besides EA views we need to include financial view of our architecture too.
We would need to figure out various financial views, e.g. yearly maintenance/support costs of separate server broken down in sw products and also total yearly price for application / system /sw product consisting of various servers. If I understand your metamodel correctly, there are 3 "cost" slots (contract_deal_cost, contract_unit_cost and maintenance_cost) in Contract class and Technology_Product.
For Purchase costs (CAPEX) we would need to make association between Contract and Technology_Product. The problem is that Technology_product is used in various applications and licenses are contracted in different time with different prices. So we cannot directly associate Contract class with Technology_Product (e.g. Technology_product instance is BEA WLS, we have 20 licenses of WLS bought in 4 contracts (=4 different prices). What should be the right class to associate Contract with ?
M&S costs (OPEX) are already included in Technology_Product as maintenance_costs. Currently there is a disconnect from Contract class, where M&S fees are usually figured out so instead of capturing M&S costs directly in Technology_Product, there could be a slot in Technology_Product class referencing instances of Contract class which could contain fees (unit_cost). I suppose that yearly M&S fees are the same for one specific product. Apologizing for weak understanding of Essential metamodel.
Thank you for your help.
Mirek
Where does money go
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
Hi Mirek, thanks for your post.
Sounds like you have a good understanding of the meta model and it is good to see that you have been exploring the Legal and Cost Management extension.
This extension is still in the approval/review phase of the ECP, so it's great to get your feedback.
To answer your questions. You have uncovered a problem with capturing the difference between having, e.g. a contract for 10 licenses of BEA WLS (the logical Technology Product) and the use or application of those licenses to the deployed (physical) instances of WLS that you have in your architecture.
One approach would have been to use the Contract For field to relate the contract to both the Technology Product and the Technology Instances (for WLS, Infrastructure Software Instances) but we think that there's actually a subtly different relationship for the "used" instances of the contract than the one that says my contract is for 10 BEA WLS.
As we are still in the release candidate review stage of this extension to the meta model, I have updated it to include this new relationship. A new update pack (which you can run on top of the last one) is available from the ECP-1 topic and there is an updated sample repository.
One of the points that I think is important is that we've tried avoid implying that there is a low-level computing of the costs of things. Costs are too complex to make assumptions about how they are computed from 'atomic' values. Rather, we feel that providing the components of the costs is more accurate and useful.
On the maintenance and support side, you are right in that there is an inconsistency with the maintenance_cost slot on the Technology Product. This is a legacy slot that will be deprecated once the Cost Management extension has been finalised.
The idea with this extension is that maintenance is captured using Contract Attributes and I've added a demonstration of this to the sample ECP-1 repository.
We've used the contract attributes idea to reflect the wide variation
in how costs, especially things like maintenance fees, are applied to any element of the architecture. Rather than provide a fixed set of fields for maintenance and support, we've provided the contract_attributes that gives you the ability to define whatever aspects of the contract you need to capture.
Finally, you are also correct that there is no 'inverse relation' from the Technology Product to the Contract. This is deliberate to keep the main elements of the architecture as 'clean' as possible. You can apply a Contract to anything in the EA_Class hierarchy, so it can get tricky as to how you manage inverse relationships like this. Rather, the idea is that you define the Contract and then relate the elements (note plural) that the contract covers. When viewing any element in the Essential Viewer, this navigation from Contract to the element will be performed so that contract details (if available) are show in the definition of the element (e.g. the Technology Product details report).
I would be very interested in your comments posted to the ECP-1 topic, please.
Thanks very much
Jonathan
Sounds like you have a good understanding of the meta model and it is good to see that you have been exploring the Legal and Cost Management extension.
This extension is still in the approval/review phase of the ECP, so it's great to get your feedback.
To answer your questions. You have uncovered a problem with capturing the difference between having, e.g. a contract for 10 licenses of BEA WLS (the logical Technology Product) and the use or application of those licenses to the deployed (physical) instances of WLS that you have in your architecture.
One approach would have been to use the Contract For field to relate the contract to both the Technology Product and the Technology Instances (for WLS, Infrastructure Software Instances) but we think that there's actually a subtly different relationship for the "used" instances of the contract than the one that says my contract is for 10 BEA WLS.
As we are still in the release candidate review stage of this extension to the meta model, I have updated it to include this new relationship. A new update pack (which you can run on top of the last one) is available from the ECP-1 topic and there is an updated sample repository.
One of the points that I think is important is that we've tried avoid implying that there is a low-level computing of the costs of things. Costs are too complex to make assumptions about how they are computed from 'atomic' values. Rather, we feel that providing the components of the costs is more accurate and useful.
On the maintenance and support side, you are right in that there is an inconsistency with the maintenance_cost slot on the Technology Product. This is a legacy slot that will be deprecated once the Cost Management extension has been finalised.
The idea with this extension is that maintenance is captured using Contract Attributes and I've added a demonstration of this to the sample ECP-1 repository.
We've used the contract attributes idea to reflect the wide variation
in how costs, especially things like maintenance fees, are applied to any element of the architecture. Rather than provide a fixed set of fields for maintenance and support, we've provided the contract_attributes that gives you the ability to define whatever aspects of the contract you need to capture.
Finally, you are also correct that there is no 'inverse relation' from the Technology Product to the Contract. This is deliberate to keep the main elements of the architecture as 'clean' as possible. You can apply a Contract to anything in the EA_Class hierarchy, so it can get tricky as to how you manage inverse relationships like this. Rather, the idea is that you define the Contract and then relate the elements (note plural) that the contract covers. When viewing any element in the Essential Viewer, this navigation from Contract to the element will be performed so that contract details (if available) are show in the definition of the element (e.g. the Technology Product details report).
I would be very interested in your comments posted to the ECP-1 topic, please.
Thanks very much
Jonathan
Essential Project Team
