OK, I'll try to explain the thing that is running in my mind.
I have one common tech infrastructure so suppliers, products and so on are all common, but different "customer/product line".
Is it possible to separate different business stuff for different customers having a common Tech Layer and different Business or Application?.
Thanks
separating stuff and auth
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
Yes, it is.
You can define technology architectures to capture your common technology layer. Technology Component Architecture is used to capture the logical technology components (types of technology, e.g. application server, relational database management system). You then use a Technology Product Build to define the actual Technology Products that you use to implement the component architecture. In here, you would define things like MySQL as the RDBMS, Tomcat as the Application Server etc.
Once you've defined this Technology Product Build - which is still a logical thing - it's a design - you can use this as the Technology Architecture for Applications, which we capture using the Application Provider class.
Many Applications can use the same Technology Architecture - which is, I think, what you need to model.
You can then define the relationships to these Application Providers from Business Processes. At this level, we use Physical Business Processes so that we can identify which team/organisation/customer is using that Application.
In this way, you can even have applications that are sharing a common technology platform, and are being shared by several customers. Or you can capture that each customer has their own application that is using a common technology platform (and even include any variant applications that have a different technology platform).
All this is at the logical level. You can then go to the physical level (where you start to get into a large number of instances of classes) to understand the actual deployments of each application, e.g. production, test, development, the different technology platforms that each of those deployments might have (e.g. the development environment might be using a smaller capacity server).
With both these logical and physical architectures, you can capture all the dependencies between the artefacts - even being specific about things like database instance X depends on server A, while database instance Y depends on server B.
We're almost there in producing the example repositories that should make this sort of thing clearer but hopefully this has given you some more background. Please let me know if you are having any problems with specific things.
Jonathan
You can define technology architectures to capture your common technology layer. Technology Component Architecture is used to capture the logical technology components (types of technology, e.g. application server, relational database management system). You then use a Technology Product Build to define the actual Technology Products that you use to implement the component architecture. In here, you would define things like MySQL as the RDBMS, Tomcat as the Application Server etc.
Once you've defined this Technology Product Build - which is still a logical thing - it's a design - you can use this as the Technology Architecture for Applications, which we capture using the Application Provider class.
Many Applications can use the same Technology Architecture - which is, I think, what you need to model.
You can then define the relationships to these Application Providers from Business Processes. At this level, we use Physical Business Processes so that we can identify which team/organisation/customer is using that Application.
In this way, you can even have applications that are sharing a common technology platform, and are being shared by several customers. Or you can capture that each customer has their own application that is using a common technology platform (and even include any variant applications that have a different technology platform).
All this is at the logical level. You can then go to the physical level (where you start to get into a large number of instances of classes) to understand the actual deployments of each application, e.g. production, test, development, the different technology platforms that each of those deployments might have (e.g. the development environment might be using a smaller capacity server).
With both these logical and physical architectures, you can capture all the dependencies between the artefacts - even being specific about things like database instance X depends on server A, while database instance Y depends on server B.
We're almost there in producing the example repositories that should make this sort of thing clearer but hopefully this has given you some more background. Please let me know if you are having any problems with specific things.
Jonathan
Essential Project Team
Is it possible to define ACL to users so that one can modify (read or write in the protege sense) just things on a layer and/or on a customer line.
Lets say Architects define tech layer, PMs_customer1 business Layer for customer1, PMs_customer2 business layer for customer2?
Should I need to split the essential_baseline into different files and create a project for each with different access permissions?
Luca
Lets say Architects define tech layer, PMs_customer1 business Layer for customer1, PMs_customer2 business layer for customer2?
Should I need to split the essential_baseline into different files and create a project for each with different access permissions?
Luca
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
Good question.
Access control to the repository is all provided by Protege.
Having had another read through the Protege documentation of How Policies Work, to see what might be new with version 3.4, it looks like the answer is "no".
User access policies operate at either the project or server level. So, if you can write an instance of a class in a project, then you can write instances of all classes in that project.
Typically, we've found that there is a group of architects in the organisation who update the project (and they all have read and write access) and then we publish to the Essential Viewer environment to the wider community who cannot update the model directly.
It's great that you've identified that different users may focus on different areas of the model. However, sometimes users may find that they need to briefly work at a very coarse grain in another area - e.g. to identify that there is a process being supported by an application but leaving the details of that process for someone else to complete.
When we're working in Essential Architecture Manager ourselves, we make a lot of use of this idea of identifying "black-boxed" artefacts that we know are there but currently don't know any more details about. When we (or someone else in the team) knows these details, the black-boxed artefact can be enriched with the details but all the relationships that we have already defined are preserved.
In such circumstances could an ACL enforced by the tool actually become too constraining?
I agree with the idea of applying discipline to how the model is updated but for now, this is something that we would manage manually, e.g. through process, between the group of users working on the model.
Jonathan
Access control to the repository is all provided by Protege.
Having had another read through the Protege documentation of How Policies Work, to see what might be new with version 3.4, it looks like the answer is "no".
User access policies operate at either the project or server level. So, if you can write an instance of a class in a project, then you can write instances of all classes in that project.
Typically, we've found that there is a group of architects in the organisation who update the project (and they all have read and write access) and then we publish to the Essential Viewer environment to the wider community who cannot update the model directly.
It's great that you've identified that different users may focus on different areas of the model. However, sometimes users may find that they need to briefly work at a very coarse grain in another area - e.g. to identify that there is a process being supported by an application but leaving the details of that process for someone else to complete.
When we're working in Essential Architecture Manager ourselves, we make a lot of use of this idea of identifying "black-boxed" artefacts that we know are there but currently don't know any more details about. When we (or someone else in the team) knows these details, the black-boxed artefact can be enriched with the details but all the relationships that we have already defined are preserved.
In such circumstances could an ACL enforced by the tool actually become too constraining?
I agree with the idea of applying discipline to how the model is updated but for now, this is something that we would manage manually, e.g. through process, between the group of users working on the model.
Jonathan
Essential Project Team
My case is based on customer so both the visibility of the report and the input of part of the data should be filtered.
If in the case of input of data people are from the service provider company and there might be just good internal policy.
The reports must be filtered out for customer since is not "nice" to give visib ility to customer A of the overall architecture and business of customer B.
Duplicating the project can be done, but since the service provider is the same and the tech layer is the same (even if not used in the same way by different customers: lets say cust A has windows Desktop, and cust B ubuntu).
I've not jet looked at reports, but expect to be able to have a report for lets say sunset tech/products/applications etc.
These are reports architects or business people wuill use to discuss with customer and is not good to have stuff not belonging to him.
Obviously we are in the case of the EA managed not by the owner, but managed by a service provider.
If is possible to create reports that join filter like sunset AND customer (not yet found customer around the model, but ... is a big model
) I'm happy.
Luca
If in the case of input of data people are from the service provider company and there might be just good internal policy.
The reports must be filtered out for customer since is not "nice" to give visib ility to customer A of the overall architecture and business of customer B.
Duplicating the project can be done, but since the service provider is the same and the tech layer is the same (even if not used in the same way by different customers: lets say cust A has windows Desktop, and cust B ubuntu).
I've not jet looked at reports, but expect to be able to have a report for lets say sunset tech/products/applications etc.
These are reports architects or business people wuill use to discuss with customer and is not good to have stuff not belonging to him.
Obviously we are in the case of the EA managed not by the owner, but managed by a service provider.
If is possible to create reports that join filter like sunset AND customer (not yet found customer around the model, but ... is a big model
) I'm happy.Luca
-
jason.powell
- Posts: 32
- Joined: 04 Feb 2009, 15:01
We would agree that if you wish to have a common, shared repository for all customers, then you will need to adopt processes to restrict input of data to the service provider's people.
With regard to filtering reports by Customer (along with other attributes), this is indeed supported by the base meta-model and is a scenario that we have been asked about a number of times now. For this reason, we have decided to publish a detailed tutorial that provides an example of how this is achieved.
In brief terms, what you do is create a Group_Business_Role named "Service Provider Customer" and then map this new role to instances of Group_Actor; one for each of the service provider's customers whose architecture is being managed. Application, Information and Technology elements can then be mapped to one or more of these Group Actors as required.
With these relationships in place, reports can be created that present a list of Group Actors that play the role of Service Provider Customer. Then, the person viewing the report can select one to be used as a filter for what is presented.
We will let you know as soon as the full tutorial for modelling architectures in this scenario is available (should be very soon).
Jason
(Essential Project Team)
With regard to filtering reports by Customer (along with other attributes), this is indeed supported by the base meta-model and is a scenario that we have been asked about a number of times now. For this reason, we have decided to publish a detailed tutorial that provides an example of how this is achieved.
In brief terms, what you do is create a Group_Business_Role named "Service Provider Customer" and then map this new role to instances of Group_Actor; one for each of the service provider's customers whose architecture is being managed. Application, Information and Technology elements can then be mapped to one or more of these Group Actors as required.
With these relationships in place, reports can be created that present a list of Group Actors that play the role of Service Provider Customer. Then, the person viewing the report can select one to be used as a filter for what is presented.
We will let you know as soon as the full tutorial for modelling architectures in this scenario is available (should be very soon).
Jason
(Essential Project Team)
Essential Project Team
