Merge "Edits to Personas Document"
This commit is contained in:
Jenkins
Gerrit Code Review
commit
ca831d3c43
Binary file not shown.
|
Before Width: | Height: | Size: 113 KiB After Width: | Height: | Size: 53 KiB |
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 27 KiB |
@ -1,32 +1,19 @@
|
||||
.. _ux-personas:
|
||||
|
||||
===========================
|
||||
Meet the OpenStack personas
|
||||
===========================
|
||||
==================
|
||||
OpenStack personas
|
||||
==================
|
||||
|
||||
In order to share the knowledge about the target users, we have created these
|
||||
representations of our key audience segments based on qualitative and
|
||||
quantitative user research. The goals are to create more empathy for our
|
||||
customers and to better display the different types of customers performing
|
||||
different jobs.
|
||||
|
||||
We have identified five personas:
|
||||
|
||||
* Adrian - Infrastructure Architect
|
||||
* Rey - Cloud Operator
|
||||
* Taylor - Domain Operator
|
||||
* Wei - Project Owner
|
||||
* Quinn - App Developer
|
||||
|
||||
These personas are based on model companies and user ecosystems. Each
|
||||
persona takes part in different cloud adoption stages and can assume multiple
|
||||
roles within each company.
|
||||
|
||||
The personas
|
||||
~~~~~~~~~~~~
|
||||
|
||||
The personas fall into different phases of the cloud adoption workflow based
|
||||
on their specific contribution.
|
||||
We created personas to help you better define the OpenStack end-users who
|
||||
benefit from your OpenStack contributions. After much qualitative
|
||||
and quantitative research, we identified five personas that embody the most
|
||||
common roles performed by OpenStack users. We also considered where these
|
||||
personas fit into the cloud adoption workflow and how their roles may change
|
||||
depending on the size and user ecosystem of their company. You can utilize
|
||||
these personas in the design and development stage to help ensure user-centric
|
||||
contributions and well defined use cases. When used consistently, personas
|
||||
can help ensure your contributions lead to a positive user experience for
|
||||
OpenStack adopters.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
@ -36,6 +23,37 @@ on their specific contribution.
|
||||
ux-personas/domain-operator.rst
|
||||
ux-personas/project-owner.rst
|
||||
ux-personas/app-developer.rst
|
||||
ux-personas/model-companies.rst
|
||||
|
||||
Meet the personas
|
||||
-----------------
|
||||
|
||||
:ref:`infrastructure-arch`
|
||||
Adrian is responsible for the strategy and road-map for his company’s
|
||||
cloud and identifies reasons to compel management to adopt OpenStack for
|
||||
production environments.
|
||||
:ref:`cloud-ops`
|
||||
Rey is involved in installing, operating, using, and updating the
|
||||
OpenStack cloud services.
|
||||
:ref:`domain-operator`
|
||||
Taylor manages the relationship with the cloud services provider. This
|
||||
includes managing quotas, number of users, applicable policies, and
|
||||
support tickets.
|
||||
:ref:`project-owner`
|
||||
Wei manages projects by adding or removing project members’ access to
|
||||
the cloud instance. Wei’s main concern is to have enough resources
|
||||
available to support Wei’s projects.
|
||||
:ref:`app-developer`
|
||||
Quinn develops and deploys cloud applications but does not necessarily
|
||||
know much about the underlying infrastructure of the cloud.
|
||||
|
||||
Role ecosystem
|
||||
--------------
|
||||
|
||||
To better understand each persona role, see the following overall role
|
||||
ecosystem, which is based on levels of abstraction from hardware to
|
||||
application level. Within this ecosystem, we can see the current
|
||||
personas as well as candidates for future personas.
|
||||
|
||||
.. The original SVG copy of this figure is available in
|
||||
in the same directory.
|
||||
@ -44,109 +62,28 @@ on their specific contribution.
|
||||
:align: center
|
||||
:width: 100%
|
||||
|
||||
The model companies
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
The personas in the above ecosystem fall into different phases of the cloud
|
||||
adoption workflow and are seen as separate and distinct from one another.
|
||||
Although it is advantageous to separate the personas based on typical users,
|
||||
some people, whom the personas represent, can assume multiple roles
|
||||
depending on their workplace and company responsibilities. To appreciate
|
||||
the personas in a different role ecosystem, see the following
|
||||
:ref:`model-companies`:
|
||||
|
||||
We have identified three organizational models that best exemplify the roles
|
||||
that the personas assume depending on their ecosystems.
|
||||
:ref:`Nikishi-University` - Academic/Nonprofit
|
||||
Wants to provide cloud services to their internal labs and have bare metal.
|
||||
Do not want to hire resources internally to deploy trunk.
|
||||
|
||||
.. important::
|
||||
:ref:`CNBB-Securities` - Enterprise
|
||||
Wants to provide cloud services to internal customers for applications that
|
||||
are not customers facing. Has both bare metal and operations.
|
||||
|
||||
The institutions described in this document are fictitious and serve only
|
||||
as representations of different organizational models.
|
||||
:ref:`Rifkom` - Service provider
|
||||
Wants to provide services to external customers that do not want or have
|
||||
internal resources. Has both bare metal and operations resources internally.
|
||||
|
||||
Nikishi University - research
|
||||
-----------------------------
|
||||
:ref:`MOI` - Small/medium business
|
||||
Wants to deploy customer-facing applications, but do not have bare metal or
|
||||
a budget for operations resources.
|
||||
|
||||
At Nikishi university, each cloud user can potentially assume all personas'
|
||||
roles. Although typically each individual specializes in two or more of the
|
||||
roles. The Infrastructure Architect and the Cloud Operator roles
|
||||
could be assumed by a single individual. Similarly, the Domain Operations and
|
||||
Project Owner roles could be merged. This organizational model has a low
|
||||
staffing budget and is concerned with capital expenditure causing them to
|
||||
create their own implementation.
|
||||
|
||||
.. list-table:: **Nikishi University - Key Info**
|
||||
:widths: 15 15 15 15
|
||||
:header-rows: 1
|
||||
|
||||
* - Adoption model
|
||||
- Process and compliance
|
||||
- Skill depth
|
||||
- Number of users
|
||||
* - Roll your own
|
||||
- Minimal
|
||||
- Deep
|
||||
- 100 to 999 users
|
||||
|
||||
CNBB Securities - large enterprise
|
||||
----------------------------------
|
||||
|
||||
At CNBB Securities, the company's large organization chart represents each of
|
||||
the personas. Depending on the company's culture of collaboration, the
|
||||
personas could interact as if they were part of a single entity. However,
|
||||
usually the Cloud Operator and the Infrastructure Architect interact as
|
||||
service providers with the other personas. The personas within CNBB
|
||||
Securities look for a fast implementation and are responsible for the
|
||||
operations capital expenditure. The implementation has no customization and
|
||||
the organization usually outsources its support.
|
||||
|
||||
.. list-table:: **CNBB Securities - Key Info**
|
||||
:widths: 15 15 15 15
|
||||
:header-rows: 1
|
||||
|
||||
* - Adoption model
|
||||
- Process and compliance
|
||||
- Skill depth
|
||||
- Number of users
|
||||
* - Distribution with professional services
|
||||
- High
|
||||
- Medium
|
||||
- Over 10000 users
|
||||
|
||||
Rifkom - service provider
|
||||
-------------------------
|
||||
|
||||
At Rifkom, employees provide services to external customers that do not want
|
||||
or have the internal resources. Rifkom customizes solutions and
|
||||
prioritizes a flexible approach to architecture. The highly skilled staff
|
||||
represents the largest expenditure for Rifkom. Only Infrastructure Architects
|
||||
and Cloud Operators work at Rifkom since the other personas are their
|
||||
customers at MOI. Customers usually interact with Rifkom employees through a
|
||||
ticket system.
|
||||
|
||||
.. list-table:: **Rifkom - Key Info**
|
||||
:widths: 15 15 15 15
|
||||
:header-rows: 1
|
||||
|
||||
* - Adoption model
|
||||
- Process and compliance
|
||||
- Skill depth
|
||||
- Number of users
|
||||
* - Roll your own
|
||||
- Medium to High (depends on customer)
|
||||
- Deep
|
||||
- 1000 to 9999 users
|
||||
|
||||
MOI - customer
|
||||
--------------
|
||||
|
||||
At MOI, speed and convenience rule. Its staff encompasses the roles of App
|
||||
Developers, Project Owners, and Domain Operations. They do not perform any
|
||||
customization of the cloud and are willing to sacrifice functionality in
|
||||
order to save some costs. They interact with their cloud service provider,
|
||||
Rifkom, through a ticket system in case of problems with their cloud
|
||||
instance.
|
||||
|
||||
.. list-table:: **MOI - Key Info**
|
||||
:widths: 15 15 15 15
|
||||
:header-rows: 1
|
||||
|
||||
* - Adoption model
|
||||
- Process and compliance
|
||||
- Skill depth
|
||||
- Number of users
|
||||
* - Professional services
|
||||
- Medium
|
||||
- Minimal
|
||||
- No OpenStack users
|
||||
|
||||
@ -4,8 +4,12 @@
|
||||
Quinn - application developer
|
||||
=============================
|
||||
|
||||
Quinn develops and deploys cloud applications but does not necessarily know
|
||||
much about the underlying infrastructure of the cloud.
|
||||
Quinn spends very little to no time researching OpenStack. Quinn does not
|
||||
care how the cloud instances used were installed, as long as they work
|
||||
exactly as expected and the needed APIs do not change unexpectedly. Quinn
|
||||
does not control what tool is used to install and maintain the cloud
|
||||
instances. However, Quinn determines the requirements for those cloud
|
||||
instances. Any changes made to the APIs greatly impact Quinn's work.
|
||||
|
||||
Cloud applications are defined as:
|
||||
|
||||
@ -41,28 +45,6 @@ Quinn performs the following tasks frequently:
|
||||
|
||||
* Deployment: Deploys applications to one or multiple cloud instances.
|
||||
|
||||
Key information
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Quinn spends very little to no time researching OpenStack. Quinn does not
|
||||
care how the cloud instances used were installed, as long as they work
|
||||
exactly as expected and the needed APIs do not change unexpectedly. Quinn
|
||||
does not control what tool is used to install and maintain the cloud
|
||||
instances. However, Quinn determines the requirements for those cloud
|
||||
instances. Any changes made to the APIs greatly impact Quinn's work.
|
||||
|
||||
The organizational models
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The tasks that the persona performs within a certain organizational model are
|
||||
important for the usability of your OpenStack development. Within a small
|
||||
organization, such as Rifkom or Nikishi University, Quinn might be required
|
||||
to assume some roles and responsibilities of a Domain Operator or a Cloud
|
||||
Operator. Within a larger organization, like CNBB Securities, Quinn will
|
||||
likely not work alone on an application. Multiple application developers
|
||||
would need to access a single cloud to develop, test, and deploy the same
|
||||
application, making user control a requirement for the cloud.
|
||||
|
||||
Your development
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -78,3 +60,18 @@ resources are missing in such a way, that Quinn can ask a Cloud or Domain
|
||||
operator to add those resources. Quinn will not add the resources.
|
||||
Therefore, ensure that notifications are clear and do not require any
|
||||
advanced knowledge of OpenStack to identify the issues.
|
||||
|
||||
The organizational models
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The tasks that the persona performs within a certain organizational model are
|
||||
important for the usability of your OpenStack development. Within a small
|
||||
organization, such as Rifkom or Nikishi University, Quinn might be required
|
||||
to assume some roles and responsibilities of a Domain Operator or a Cloud
|
||||
Operator. Within a larger organization, like CNBB Securities, Quinn will
|
||||
likely not work alone on an application. Multiple application developers
|
||||
would need to access a single cloud to develop, test, and deploy the same
|
||||
application, making user control a requirement for the cloud. See
|
||||
:ref:`model-companies` for more information on how Quinn fits into different
|
||||
user ecosystems.
|
||||
|
||||
|
||||
@ -1,13 +1,15 @@
|
||||
.. _cloud-ops:
|
||||
|
||||
======================
|
||||
Rey - cloud operations
|
||||
======================
|
||||
====================
|
||||
Rey - cloud operator
|
||||
====================
|
||||
|
||||
Rey is involved in installing, operating, using, and updating the OpenStack
|
||||
cloud services. Rey ensures that the cloud is up and running and must fix any
|
||||
Rey ensures that the cloud is up and running and must fix any
|
||||
issues as soon as possible. Collaborating with unskilled IT personnel is very
|
||||
challenging for Rey.
|
||||
challenging for Rey. Rey spends some time every day searching for information
|
||||
on the OpenStack website, and has attended the OpenStack Summit once. Rey
|
||||
uses any useful tool in operating the cloud. Rey's previous role as a
|
||||
Linux system administrator influenced their decision to use OpenStack.
|
||||
|
||||
Key tasks
|
||||
~~~~~~~~~
|
||||
@ -25,26 +27,6 @@ Rey performs the following tasks very frequently:
|
||||
|
||||
* Update: Performs updates and verification of the OpenStack cloud.
|
||||
|
||||
Key information
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Rey spends some time every day searching for information on the OpenStack
|
||||
website and has attended the OpenStack Summit once. Rey uses any useful tool
|
||||
in operating the cloud. Rey's previous role as a Linux system administrator
|
||||
influenced the decision to use OpenStack.
|
||||
|
||||
The organizational models
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The tasks that the persona performs within a certain organizational model are
|
||||
important for the usability of your OpenStack development. Within a small
|
||||
company, Rey might be required to assume some of the responsibilities of
|
||||
both the Infrastructure Architect and the Domain Operator. Within a larger
|
||||
company, multiple individuals could perform subsets of Rey's tasks. For
|
||||
example, one person could be in charge of installing and updating the cloud
|
||||
instances, while another could be in charge of monitoring operations and
|
||||
usage, and yet another person could be in charge of solving issues. In
|
||||
Rey's organization, Rey is responsible for all of these tasks.
|
||||
|
||||
Your development
|
||||
~~~~~~~~~~~~~~~~
|
||||
@ -102,3 +84,18 @@ anticipate and compensate when preparing a project:
|
||||
|
||||
The scale of quotas presents significant obstacles for operators. Consider
|
||||
that Rey may need to manage over one thousand projects in a deployment.
|
||||
|
||||
The organizational models
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The tasks that the persona performs within a certain organizational model are
|
||||
important for the usability of your OpenStack development. Within a small
|
||||
company, Rey might be required to assume some of the responsibilities of
|
||||
both the Infrastructure Architect and the Domain Operator. Within a larger
|
||||
company, multiple individuals could perform subsets of Rey's tasks. For
|
||||
example, one person could be in charge of installing and updating the cloud
|
||||
instances, while another could be in charge of monitoring operations and
|
||||
usage, and yet another person could be in charge of solving issues. In
|
||||
Rey's organization, Rey is responsible for all of these tasks. For more
|
||||
information on how Rey fits into different user ecosystems, see
|
||||
:ref:`model-companies`.
|
||||
|
||||
@ -4,15 +4,16 @@
|
||||
Taylor - domain operator
|
||||
========================
|
||||
|
||||
Taylor manages the relationship with the cloud services provider. This
|
||||
includes managing quotas, number of users, applicable policies, and support
|
||||
tickets. Taylor does not have any major concerns about the underlying
|
||||
Taylor does not have any major concerns about the underlying
|
||||
infrastructure of the cloud and ensures that the :abbr:`SLA (Service-Level
|
||||
Agreement)` is followed.
|
||||
|
||||
Taylor needs to know about any outages, both scheduled and unscheduled.
|
||||
Unscheduled outages cause a lot of problems for Taylor, as ideally there
|
||||
would never be an unscheduled outage.
|
||||
Taylor spends no time researching OpenStack. It is likely that Taylor does
|
||||
not even know that the cloud service provider uses OpenStack and does not
|
||||
care how the cloud instances are run, as long as they run without unexpected
|
||||
outages. Taylor expects to be provided with adequate monitoring tools. Adding
|
||||
and removing users from the provided cloud services should be as easy as
|
||||
possible, in Taylor's opinion.
|
||||
|
||||
Key tasks
|
||||
~~~~~~~~~
|
||||
@ -30,26 +31,6 @@ Taylor performs the following tasks very frequently:
|
||||
* Ensuring SLA compliance: Monitors the various policies and support tickets
|
||||
to ensure that the agreed terms are being fulfilled.
|
||||
|
||||
Key information
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Taylor spends no time researching OpenStack. It is likely that Taylor does
|
||||
not even know that the cloud service provider uses OpenStack and does not
|
||||
care how the cloud instances are run, as long as they run without unexpected
|
||||
outages. Taylor expects to be provided with adequate monitoring tools. Adding
|
||||
and removing users from the provided cloud services should be as easy as
|
||||
possible, in Taylor's opinion.
|
||||
|
||||
The organizational models
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The tasks that the persona performs within a certain organizational model are
|
||||
important for the usability of your OpenStack development. Within a small
|
||||
organization, such as Rifkom or Nikishi University, Taylor might be required
|
||||
to assume some roles and responsibilities of a Cloud Operator or a Project
|
||||
Owner. Within a larger organization, like CNBB Securities, Taylor's tasks are
|
||||
performed by the team managing the cloud services provider.
|
||||
|
||||
Your development
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -68,3 +49,15 @@ require any advanced knowledge of OpenStack to identify the issues.
|
||||
If your development modifies the user management of the cloud, ensure to take
|
||||
Taylor into consideration. User management should be as simple as possible
|
||||
and it should not require deep knowledge about OpenStack.
|
||||
|
||||
The organizational models
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The tasks that the persona performs within a certain organizational model are
|
||||
important for the usability of your OpenStack development. Within a small
|
||||
organization, such as Rifkom or Nikishi University, Taylor might be required
|
||||
to assume some roles and responsibilities of a Cloud Operator or a Project
|
||||
Owner. Within a larger organization, like CNBB Securities, Taylor's tasks are
|
||||
performed by the team managing the cloud services provider. To see more on
|
||||
how roles change within organizations, see :ref:`model-companies`.
|
||||
|
||||
|
||||
@ -4,13 +4,13 @@
|
||||
Adrian - infrastructure architect
|
||||
=================================
|
||||
|
||||
Adrian is responsible for the strategy and road-map for his company's cloud
|
||||
and identifies reasons to compel management to adopt OpenStack for production
|
||||
environments. The reasons that would deter Adrian from recommending OpenStack
|
||||
are frequent instabilities, non-deterministic errors, the inability to create
|
||||
an environment, and missing documentation. Similarly to the domain operator,
|
||||
Adrian needs to know about any outage conditions that may occur on both
|
||||
testing and production environments.
|
||||
Adrian spends a lot of time reading and researching information about
|
||||
OpenStack and other cloud technologies. Adrian has attended more than one
|
||||
OpenStack summit, and contributes solutions to the community regularly. Adrian
|
||||
values OpenStack and is committed to drive adoption. Adrian's priority,
|
||||
however, is a fully functional and stable cloud that fulfills all of his
|
||||
requirements. Your development affects Adrian if it modifies the scope,
|
||||
implementation, or usage of OpenStack.
|
||||
|
||||
Key tasks
|
||||
~~~~~~~~~
|
||||
@ -31,35 +31,28 @@ Adrian performs the following tasks very frequently:
|
||||
* Cloud planning: Defines and plans the cloud while considering hardware,
|
||||
platform choices, services, and scale.
|
||||
|
||||
Key information
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Adrian spends a lot of time reading and researching information about
|
||||
OpenStack and other cloud technologies. Adrian has attended more than one
|
||||
OpenStack summit and contributes solutions to the community regularly. Adrian
|
||||
values OpenStack and is committed to drive adoption. Adrian's priority,
|
||||
however, is a fully functional and stable cloud that fulfills all of his
|
||||
requirements.
|
||||
|
||||
The organizational models
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The tasks that the persona performs within a certain organizational model are
|
||||
important for the usability of your OpenStack development. Within a small
|
||||
organization, such as Rifkom or Nikishi University, Adrian might be required
|
||||
to assume some roles and responsibilities of a Cloud Operator or, more
|
||||
rarely, a Domain Operator. Within a larger organization, like CNBB
|
||||
Securities, Adrian's tasks are performed by the team planning and implementing
|
||||
the cloud instances.
|
||||
|
||||
Your development
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Adrian's main concern is the cloud's architecture. Adrian interacts directly
|
||||
with OpenStack and has probably developed any pieces that were needed. Your
|
||||
with OpenStack and has probably developed many pieces that were needed. Your
|
||||
development targets Adrian if it makes any changes to the way clouds are
|
||||
implemented and deployed. Any new features, fixes, and limitations are
|
||||
important to Adrian.
|
||||
|
||||
If your development modifies the scope, implementation, and usage of
|
||||
OpenStack ensure to take Adrian into consideration.
|
||||
The reasons that would deter Adrian from recommending OpenStack
|
||||
are frequent instabilities, non-deterministic errors, the inability to create
|
||||
an environment, and missing documentation. Similarly to the domain operator,
|
||||
Adrian needs to know about any outage conditions that may occur on both
|
||||
testing and production environments.
|
||||
|
||||
The organizational models
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Within a small organization, such as Rifkom or Nikishi University,
|
||||
Adrian might be required to assume some roles and responsibilities of a
|
||||
Cloud Operator or, more rarely, a Domain Operator. Within a larger
|
||||
organization, like CNBB Securities, Adrian's tasks are performed by the
|
||||
team planning and implementing the cloud instances. See :ref:`model-companies`
|
||||
for more information on how Adrian fits into different user ecosystems.
|
||||
|
||||
|
||||
@ -0,0 +1,133 @@
|
||||
.. _model-companies:
|
||||
|
||||
===================
|
||||
The model companies
|
||||
===================
|
||||
|
||||
This page allows you to see how different companies and user ecosystems
|
||||
influence a specific persona's role. We have identified four model companies
|
||||
with three organizational models that best exemplify the companies decision
|
||||
to adopt OpenStack. Use these companies to help refine your use cases for a
|
||||
specific type of organizational paradigm. The factors we chose to distinguish
|
||||
the different model companies include the cloud adoption model, operations,
|
||||
security needs, and compliance.
|
||||
|
||||
.. important::
|
||||
|
||||
The institutions described in this document are fictitious and serve only
|
||||
as representations of different organizational models.
|
||||
|
||||
.. _Nikishi-University:
|
||||
|
||||
Nikishi University - research
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
At Nikishi university, each cloud user can potentially assume all persona
|
||||
roles. Although typically each individual specializes in two or more of the
|
||||
roles.
|
||||
|
||||
.. list-table:: **Nikishi University - Key Info**
|
||||
:widths: 15 15 15 15
|
||||
:header-rows: 1
|
||||
|
||||
* - Adoption model
|
||||
- Process and compliance
|
||||
- Skill depth
|
||||
- Number of users
|
||||
* - Roll your own
|
||||
- Minimal
|
||||
- Deep
|
||||
- 100 to 999 users
|
||||
|
||||
* The roles of :ref:`infrastructure-arch` and :ref:`Cloud-Ops`
|
||||
could be assumed by a single individual.
|
||||
* The roles of :ref:`Domain-Operator`, :ref:`Project-Owner`,
|
||||
and :ref:`app-developer` could be merged.
|
||||
|
||||
This organizational model has a low staffing budget and is concerned with
|
||||
capital expenditure, which influenced their decision to create their own
|
||||
implementation.
|
||||
|
||||
.. _CNBB-Securities:
|
||||
|
||||
CNBB Securities - large enterprise
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
At CNBB Securities, the company's large organization chart represents each of
|
||||
the personas. Depending on the company's culture of collaboration, the
|
||||
personas could interact as if they were part of a single entity.
|
||||
|
||||
.. list-table:: **CNBB Securities - Key Info**
|
||||
:widths: 15 15 15 15
|
||||
:header-rows: 1
|
||||
|
||||
* - Adoption model
|
||||
- Process and compliance
|
||||
- Skill depth
|
||||
- Number of users
|
||||
* - Distribution with professional services
|
||||
- High
|
||||
- Medium
|
||||
- Over 10000 users
|
||||
|
||||
* Usually the roles of :ref:`Cloud-Ops` and :ref:`Infrastructure-Arch`
|
||||
interact as service providers with the other personas.
|
||||
|
||||
The personas within CNBB Securities look for a fast implementation and are
|
||||
responsible for the operations capital expenditure. The implementation has no
|
||||
customization and the organization usually outsources its support.
|
||||
|
||||
.. _Rifkom:
|
||||
|
||||
Rifkom - service provider
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
At Rifkom, employees provide services to external customers that do not want
|
||||
or have the internal resources. Rifkom customizes solutions and
|
||||
prioritizes a flexible approach to architecture. The highly skilled staff
|
||||
represents the largest expenditure for Rifkom.
|
||||
|
||||
.. list-table:: **Rifkom - Key Info**
|
||||
:widths: 15 15 15 15
|
||||
:header-rows: 1
|
||||
|
||||
* - Adoption model
|
||||
- Process and compliance
|
||||
- Skill depth
|
||||
- Number of users
|
||||
* - Roll your own
|
||||
- Medium to High (depends on customer)
|
||||
- Deep
|
||||
- 1000 to 9999 users
|
||||
|
||||
* Only the roles of :ref:`Infrastructure-Arch` and :ref:`Cloud-Ops` exist at
|
||||
Rifkom. The other personas are their customers at MOI.
|
||||
|
||||
Customers usually interact with Rifkom employees through a ticket system.
|
||||
|
||||
.. _MOI:
|
||||
|
||||
MOI - customer
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
At MOI, speed and convenience rule. They do not perform any customization of
|
||||
the cloud and are willing to sacrifice functionality in order to save some
|
||||
costs. They interact with their cloud service provider, Rifkom, through a
|
||||
ticket system in case of problems with their cloud instance.
|
||||
|
||||
.. list-table:: **MOI - Key Info**
|
||||
:widths: 15 15 15 15
|
||||
:header-rows: 1
|
||||
|
||||
* - Adoption model
|
||||
- Process and compliance
|
||||
- Skill depth
|
||||
- Number of users
|
||||
* - Professional services
|
||||
- Medium
|
||||
- Minimal
|
||||
- No OpenStack users
|
||||
|
||||
* MOI's staff encompasses the roles of :ref:`App-Developer`,
|
||||
:ref:`Project-Owner`, and :ref:`Domain-Operator`. Other roles are external.
|
||||
|
||||
@ -4,11 +4,13 @@
|
||||
Wei - project owner
|
||||
===================
|
||||
|
||||
Wei manages projects by adding or removing project members' access to the
|
||||
cloud instance. Wei does not know the underlying infrastructure nor the
|
||||
OpenStack projects involved. Wei's main concern is to have enough resources
|
||||
available to support Wei's projects. Therefore, if a project runs out of
|
||||
quota, Wei does not want to have to wait for the operators to raise it.
|
||||
Wei does not know or care about whether OpenStack is being used for the cloud
|
||||
instance that the projects use or not. Wei's concern is to have enough
|
||||
resources whenever they are needed. If Wei's requests for additional
|
||||
resources take too long to be fulfilled, Wei will start looking for
|
||||
alternatives until the project's needs are met.
|
||||
Therefore, if a project runs out of quota, Wei does not want to have to wait
|
||||
for the operators to raise it.
|
||||
|
||||
Key tasks
|
||||
~~~~~~~~~
|
||||
@ -24,14 +26,19 @@ Wei performs the following tasks very frequently:
|
||||
* Managing projects: Coordinates project resources to ensure its success and
|
||||
the OpenStack cloud is another resource among many other.
|
||||
|
||||
Key information
|
||||
~~~~~~~~~~~~~~~
|
||||
Your development
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Wei does not know or care about whether OpenStack is being used for the cloud
|
||||
instance that the projects use or not. Wei's concern is to have enough
|
||||
resources whenever they are needed. If Wei's requests for additional
|
||||
resources take too long to be fulfilled, Wei will start looking for
|
||||
alternatives until the project's needs are met.
|
||||
When your development affects the behavior of the capacity of cloud
|
||||
instances, you should consider Wei as an interested party. Ensuring that
|
||||
changes to the capacity of cloud instances can occur as easily and as quickly
|
||||
as possible certainly has a positive impact on Wei's work, for example.
|
||||
However, Wei does not perform those changes in capacity directly.
|
||||
|
||||
Finally, consider that Wei is a highly skilled developer with little
|
||||
knowledge of OpenStack and with little time for long, complex research.
|
||||
Therefore, your solutions for Wei must be focused on enabling others to
|
||||
provide the needed resources as quickly as possible.
|
||||
|
||||
The organizational models
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@ -49,18 +56,6 @@ owner and the company could have several projects.
|
||||
|
||||
Whatever the case, it is highly likely that Wei is an experienced application
|
||||
developer as well. See the information pertaining to the application
|
||||
developer persona here: :ref:`app-developer`
|
||||
developer persona here: :ref:`app-developer`. To see more on
|
||||
how roles change within organizations, see :ref:`model-companies`.
|
||||
|
||||
Your development
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
When your development affects the behavior of the capacity of cloud
|
||||
instances, you should consider Wei as an interested party. Ensuring that
|
||||
changes to the capacity of cloud instances can occur as easily and as quickly
|
||||
as possible certainly has a positive impact on Wei's work, for example.
|
||||
However, Wei does not perform those changes in capacity directly.
|
||||
|
||||
Finally, consider that Wei is a highly skilled developer with little
|
||||
knowledge of OpenStack and with little time for long, complex research.
|
||||
Therefore, your solutions for Wei must be focused on enabling others to
|
||||
provide the needed resources as quickly as possible.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user