Merge "Editing Methodology section"
This commit is contained in:
commit
1e74d7f01d
@ -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
|
||||
|
Loading…
Reference in New Issue
Block a user