Replies: 7 comments 21 replies
-
|
Maybe we make Ops teams a subset of SP, and add a second subset architecture/development? Also, and this might be what operations was, but maybe change that to network operator? as a distinction for a SP specifically. |
Beta Was this translation helpful? Give feedback.
-
|
it was brought to my attention I was not clear thinking something like:
and then the rest the same for now (to include operations in both SP and Ent having the domains you listed). This suggestion is not perfect in its current form, just want the other big network operators that don't necessarily have the specific SP challenges those of us on the provider side do are represented. |
Beta Was this translation helpful? Give feedback.
-
|
Addressed by having actors outside of the groups. |
Beta Was this translation helpful? Give feedback.
-
|
How about this:
Note: the sub groups would be combined with their higher level actor, like:
|
Beta Was this translation helpful? Give feedback.
-
|
I feel a bit uncomfortable with the top level of the tree being things like SP, Vendor, Customer, etc. It implies that there are different rules you should follow based on who's paying your salary. I am afraid this will perpetuate the adversarial approach that existed between SPs and vendors in the past. If you are a developer of apps, I don't think it matters if you work for a SP, Vendor, ISV or whatever. At the end of the day it is best if they all abide by the same rules that will make their app run properly on the cloud infrastructure. Operations personnel may also be employees of a vendor, in case of a BOT type of project. Again, their rules should not differ from the ones applicable to SP organics operations teams.
|
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure if it comes across as different actors/different rules, but we'd definitely want to ensure that was not the case. The goal here should be the opposite, trying to come up with commonalities for all. The main driver I think @taylor was pushing for here is to show the that there are various actors, and each one would have unique motivations and needs to contribute to this effort. From there we could strive to bridge those gaps. |
Beta Was this translation helpful? Give feedback.
-
|
See top of discussion for updated list. I've split the different groups from the actors. The actors can be in any group. When talking about an actor it is probably a good idea to communicate what group they are in or explicitly communicate it is applicable to any group the actor is in. |
Beta Was this translation helpful? Give feedback.
-
|
Time to copy-paste from Slack here:
|
Beta Was this translation helpful? Give feedback.
-
|
Since a lot of conversations is around the fact that these practices will be used for RFP, do we need to add an Actor for CNF Purchaser as a consumer of the "certification"? |
Beta Was this translation helpful? Give feedback.
-
|
Do we also need to consider the role of "System Integrators" or no? |
Beta Was this translation helpful? Give feedback.
-
|
Added to list. See top of discussion |
Beta Was this translation helpful? Give feedback.
-
|
This might be good to add to the introduction that @rabi-abdel is writing in #34 It might be helpful to talk about the unique motivations and needs of each user as @jeffsaelens said above |
Beta Was this translation helpful? Give feedback.
-
|
I think we need to take our user categories and lump them into responsibilities so we have fewer names to deal with in our user stories - whoever is integrating it has an integration role and it doesn't matter if they're a dedicated SI or an SP operator, it's more a question of what they do that matters (which we could define by example). |
Beta Was this translation helpful? Give feedback.
-
|
So just boil it down to the main 4? Architect - Chief Power Point creator Definitions/examples may need some tweaking |
Beta Was this translation helpful? Give feedback.
-
|
I like the focus on the main 4. That would work for me. Now, something else came to my mind: in any sort of transformation (and going CNF is certainly a transformation), you need management support. Isn't this another relevant actor? |
Beta Was this translation helpful? Give feedback.
-
|
I would focus on: Roles:
Then a section per role; and include in that section a discussion of the perspectives the role brings (e.g. reliability, security). That's less fine grained than Taylor has in actors but the perspectives should cover the rest. Then, organisations involved (the dirty reality):
This comes last because it's the one that diverts us from the more technical details. |
Beta Was this translation helpful? Give feedback.
-
|
These actors and roles have to be related with the scope of this group |
Beta Was this translation helpful? Give feedback.
-
The actors (entity playing a specific role) is important to provide context for any best practice proposed. It's important that the CNF WG have a shared definition of each actor. This first description will be updated periodically. Please see the comments for more frequent updates. After there is enough consensus through discussion we will add the information to a more "permanent home" in the repository.
Groups/orgs
Telecom Actors:
Roles
The same or similar actors can be found across the Teleco domain: eg. there may be Infra / app developers in a Vendor org, in an open source project, or at an SP. It's important to communicate where the actor is as their motivations in addition to any shared across groups.
When the context is not immediately apparent by other explicit informations the actors should be combined with the group and any other information. Examples:
Beta Was this translation helpful? Give feedback.
All reactions