Merge "Editing Methodology section"

This commit is contained in:
Jenkins 2015-08-14 00:59:28 +00:00 committed by Gerrit Code Review
commit 1e74d7f01d

View File

@ -9,110 +9,29 @@
version="5.0"
xml:id="methodology">
<title>Methodology</title>
<para>The magic of the cloud is that it can do anything. It is both robust
and flexible, the best of both worlds. Yes, the cloud is highly flexible
and it can do almost anything, but to get the most out of a cloud
investment, it is important to define how the cloud will be used by
creating and testing use cases. This is the chapter that describes the
thought process behind how to design a cloud architecture that best
suits the intended use.</para>
<mediaobject>
<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
<para>
Creating and testing use cases is the best way to design a cloud
architecture that best suits your needs.</para>
<para>
For example, if your goal is to develop a cloud for your company's e-commerce
website, you need to plan 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
method for testing the assumptions.</para>
<formalpara>
<title>Develop functional user scenarios</title>
<para>
Develop functional user scenarios that can be used to develop
test cases that can be used to measure overall project
trajectory. If the organization is not ready to commit to an
application or applications that can be used to develop user
requirements, it needs to create requirements to build valid
test harnesses and develop usable meters. Once the meters
are established, as requirements change, it is easier to
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>
Functional user scenarios are used to develop test cases to measure overall
project trajectory. If you do not want to use an application to develop user
requirements automatically, you will need to create requirements to build
test harnesses and develop usable meters. Once the meters are established you
can respond to changes quickly without having to set the exact requirements
in advance. This creates ways to configure the system, rather than redesigning
it every time there is a requirements change.</para>
<para>
Create requirements that address the pain points but keep the
core design of OpenStack. The requirement to build OpenStack,
only better, is self-defeating. It is important to limit scope
creep by concentrating on developing a platform that will
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>
It is important to limit scope creep. Ensure you address tool limitations
for the requirements, but do not recreate the entire suite of tools. Work
with technical product owners to establish critical features that are needed
for a successful cloud deployment.</para>
<section xml:id="application-cloud-readiness-methods">
<title>Application cloud readiness</title>
<para>Although the cloud is designed to make things easier, it is