From 6f6defd0620bf1cb026d89d459346e8d2327a8a2 Mon Sep 17 00:00:00 2001 From: loquacity Date: Thu, 13 Aug 2015 16:31:02 +1000 Subject: [PATCH] Editing Methodology section Edited the top part of the Methodology section. Change-Id: Id575a606ad7b641e5f88f9b16d7db5a4ffe56210 Implements: blueprint arch-guide --- .../introduction/section_methodology.xml | 121 +++--------------- 1 file changed, 20 insertions(+), 101 deletions(-) diff --git a/doc/arch-design/introduction/section_methodology.xml b/doc/arch-design/introduction/section_methodology.xml index c2ae3f10a1..76e4751452 100644 --- a/doc/arch-design/introduction/section_methodology.xml +++ b/doc/arch-design/introduction/section_methodology.xml @@ -9,110 +9,29 @@ version="5.0" xml:id="methodology"> Methodology - 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. - - - - - - 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. - 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. - Overall business objectives - - - Develop clear definition of business goals and requirements - - - - Increase project support and engagement with business, - customers and end users. - - - Technology - - - Coordinate the OpenStack architecture across the project and - leverage OpenStack community efforts more effectively. - - - Architect for automation as much as possible to speed - development and deployment. - - - Use the appropriate tools for the development effort. - - - Create better and more test meters and test harnesses to - support continuous and integrated development, test processes - and automation. - - - Organization - - - Better messaging of management support of team efforts - - - Develop better cultural understanding of Open Source, cloud - architectures, Agile methodologies, continuous development, test - and integration, overall development concepts in general - - - 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 + + Creating and testing use cases is the best way to design a cloud + architecture that best suits your needs. + + 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. - - Develop functional user scenarios + + 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. - 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. - - - - Limit cloud feature set - - 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. - - + 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.
Application cloud readiness Although the cloud is designed to make things easier, it is