openstack/openstack-manuals
Code Issues Proposed changes

Editing Methodology section

Browse Source 
Edited the top part of the Methodology section.

Change-Id: Id575a606ad7b641e5f88f9b16d7db5a4ffe56210
Implements: blueprint arch-guide
This commit is contained in:
loquacity 2015-08-13 16:31:02 +10:00
parent 79d32c6607
commit 6f6defd062
1 changed files with 20 additions and 101 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

119
doc/arch-design/introduction/section_methodology.xml
View File

@ -9,110 +9,29 @@
version="5.0" version="5.0"
xml:id="methodology"> xml:id="methodology">
<title>Methodology</title> <title>Methodology</title>
<para>The magic of the cloud is that it can do anything. It is both robust <para>
and flexible, the best of both worlds. Yes, the cloud is highly flexible Creating and testing use cases is the best way to design a cloud
and it can do almost anything, but to get the most out of a cloud architecture that best suits your needs.</para>
investment, it is important to define how the cloud will be used by <para>
creating and testing use cases. This is the chapter that describes the For example, if your goal is to develop a cloud for your company's e-commerce
thought process behind how to design a cloud architecture that best website, you need to plan for applications that will support thousands of
suits the intended use.</para> sessions per second, variable workloads, and lots of complex and changing data.
<mediaobject> By identifying the key meters, such as number of concurrent transactions
<imageobject>
<imagedata contentwidth="4in" fileref="../figures/Methodology.png"/>
</imageobject>
</mediaobject>
<para>The diagram shows at a very abstract level the process for capturing
requirements and building use cases. Once a set of use cases has been
defined, it can then be used to design the cloud architecture.</para>
<para>Use case planning can seem counter-intuitive. After all, it takes
about five minutes to sign up for a server with Amazon. Amazon does not
know in advance what any given user is planning on doing with it, right?
Wrong. Amazon's product management department spends plenty of time
figuring out exactly what would be attractive to their typical customer
and honing the service to deliver it. For the enterprise, the planning
process is no different, but instead of planning for an external paying
customer, for example, the use could be for internal application
developers or a web portal. The following is a list of the high level
objectives that need to be incorporated into the thinking about creating
a use case.</para>
<para>Overall business objectives</para>
<itemizedlist>
<listitem>
<para>Develop clear definition of business goals and requirements
</para>
</listitem>
<listitem>
<para>Increase project support and engagement with business,
customers and end users.</para>
</listitem>
</itemizedlist>
<para>Technology</para>
<itemizedlist>
<listitem>
<para>Coordinate the OpenStack architecture across the project and
leverage OpenStack community efforts more effectively.</para>
</listitem>
<listitem>
<para>Architect for automation as much as possible to speed
development and deployment.</para>
</listitem>
<listitem>
<para>Use the appropriate tools for the development effort.</para>
</listitem>
<listitem>
<para>Create better and more test meters and test harnesses to
support continuous and integrated development, test processes
and automation.</para>
</listitem>
</itemizedlist>
<para>Organization</para>
<itemizedlist>
<listitem>
<para>Better messaging of management support of team efforts</para>
</listitem>
<listitem>
<para>Develop better cultural understanding of Open Source, cloud
architectures, Agile methodologies, continuous development, test
and integration, overall development concepts in general</para>
</listitem>
</itemizedlist>
<para>As an example of how this works, consider a business goal of using the
cloud for the company's E-commerce website. This goal means planning for
applications that will support thousands of sessions per second,
variable workloads, and lots of complex and changing data. By
identifying the key meters, such as number of concurrent transactions
per second, size of database, and so on, it is possible to then build a per second, size of database, and so on, it is possible to then build a
method for testing the assumptions.</para> method for testing the assumptions.</para>
<formalpara>
<title>Develop functional user scenarios</title>
<para> <para>
Develop functional user scenarios that can be used to develop Functional user scenarios are used to develop test cases to measure overall
test cases that can be used to measure overall project project trajectory. If you do not want to use an application to develop user
trajectory. If the organization is not ready to commit to an requirements automatically, you will need to create requirements to build
application or applications that can be used to develop user test harnesses and develop usable meters. Once the meters are established you
requirements, it needs to create requirements to build valid can respond to changes quickly without having to set the exact requirements
test harnesses and develop usable meters. Once the meters in advance. This creates ways to configure the system, rather than redesigning
are established, as requirements change, it is easier to it every time there is a requirements change.</para>
respond to the changes quickly without having to worry overly
much about setting the exact requirements in advance. Think of
this as creating ways to configure the system, rather than
redesigning it every time there is a requirements
change.
</para>
</formalpara>
<formalpara>
<title>Limit cloud feature set</title>
<para> <para>
Create requirements that address the pain points but keep the It is important to limit scope creep. Ensure you address tool limitations
core design of OpenStack. The requirement to build OpenStack, for the requirements, but do not recreate the entire suite of tools. Work
only better, is self-defeating. It is important to limit scope with technical product owners to establish critical features that are needed
creep by concentrating on developing a platform that will for a successful cloud deployment.</para>
address tool limitations for the requirements, but not
recreating the entire suite of tools. Work with technical
product owners to establish critical features that are needed
for a successful cloud deployment.
</para>
</formalpara>
<section xml:id="application-cloud-readiness-methods"> <section xml:id="application-cloud-readiness-methods">
<title>Application cloud readiness</title> <title>Application cloud readiness</title>
<para>Although the cloud is designed to make things easier, it is <para>Although the cloud is designed to make things easier, it is