View
295
Download
1
Embed Size (px)
DESCRIPTION
Demys&fying Cloud Security J o u r n e y f r o m P r o j e c t t o P a t e n t t o P u b l i c C o n s u m p & o n Platform as a Service Software as a Service Database as a Service Load Balancing as a Service Monitoring as a Service Central Access Control as a Service Infrastructure as a Service Notification as a Service Validation as a Service Health Information Exchange as a Service
Citation preview
Demys&fying Cloud Security J o u r n e y f r o m P r o j e c t t o P a t e n t t o P u b l i c C o n s u m p & o n By Ben Clay and Rob Morrow
Platform as a Service
Software as a ServiceDatabase as a Service Load Balancing as a Service
Monitoring as a Service
Central Access Control as a ServiceInfrastructure as a Service
Notification as a Service
Validation as a Service
Health Information Exchange as a Service
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay
Cloud compu&ng is virtualized resources served up as services in the web.
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
Objec&ves
• Public facing web applica&on for consumer product consump&on
• House consumer credit card informa&on • Process credit cards for payment • Mine the credit card informa&on and purchases
• Finish in six (6) months or less – Five (5) Web applica&ons – Four (4) mobile applica&ons
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
Timeline and Release Schedule Twenty-‐One (21) Business Day Sprint Dura&on
1st Module Create/write the following: • Func&onal decomposi&on • Wireframes • User Stories • Database schema • UX/UI • Cloud infrastructure
• QA • DEV • Staging • Local DEV
Month 1
Month 2 Develop, skin, QA and deploy produc&on ready 1st module to staging. 2nd Module Create/write the following: • Func&onal decomposi&on • Wireframes • User Stories • Add tables to DB • UX/UI
Develop, skin, QA and deploy produc&on ready 2nd module to staging. 3rd Module Create/write the following: • Func&onal
decomposi&on • Wireframes • User Stories • Add tables to DB • UX/UI
Month 3
Month 4 Develop, skin, QA and deploy produc&on ready 3rd module to staging. 4th Module Create/write the following: • Func&onal decomposi&on • Wireframes • User Stories • Add tables to DB • UX/UI
Develop, skin, QA and deploy produc&on ready 4th module to staging. 5th Module Create/write the following: • Func&onal
decomposi&on • Wireframes • User Stories • Add tables to DB • UX/UI
Month 5
Month 6 Develop, skin, QA and deploy produc&on ready 5th module to staging. Mobile Applica9ons Create/write the following: • Func&onal decomposi&on • Wireframes • User Stories • Add tables to DB • UX/UI
Mobile Applica9ons Develop, skin, QA and deploy produc&on ready mobile applica&ons to staging, apple store and android market. Launch everything May 1
Month 7
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay
Agile Project Management Flow Chart Practical Scrum Adaptive PMLC Work Flow
Benjamin F Clay © 2012
= Adaptive Project Management Life Cycle Equivalent
Product Backlog
Grooming 24/7
PreSprint Plan(Plan Cycle)
Sprint Plan(Plan Cycle)
Release Plan(Plan Cycle)
Sprint Showcase(Close Cycle)
Release Backlog(Scope and Plan Cycle)
YesNext Sprint(Next Cycle)
Close Project
No
Product Backlog(Scope and Plan Cycle)
Based on need. I
schedule once a week reoccurring
Once every week
Every 24 hours
Meta Scrum
Daily Scrum
Scrum of Scrum
Sprint(Execute Iteration,
Monitor & Control and Launch Cycle)
Start Here
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay
Why this project was different
• We would be the first documented PCI compliant Cloud environment – Securing personal and credit card informa&on in a cloud environment • processing • mining and more
• No documented cases – No blueprint – No prac&cal guide – No how to
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
Our Actual Team Venn Diagrams
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay
Ideal Scrum TeamsDaily Scrum StandupsMeeting room: Conference roomRemote: Conference/Video- Team number @ Time CST- Team number @ Time CST
Scrum Master Business Analyst Product Owner
Product Manager
DevelopersFront-End Dev, Back-End Dev
Quality Assurance
Feature/Product Team 1
RULES• No more than 15 minutes in length• Traditionally a stand-up meeting• Not for problem solving• Whole world is invited • Only team members, Scrum Master, and product owner can
speak • Each team member answers 3 questions (signifies commitment
in front of team)• What did you do since the last meeting to help the team accomplish
their goals and/or deadlines?• What are you going to help the team work on today to accomplish
their goals and/or deadline?• Is anything preventing you from accomplishing your goal(s)?• Each member only speaks 60 seconds or less.
March 10, 2011Created by: Ben Clay CSM, [email protected] - mobileBenjamin F Clay © 2012
Chief Infrastructure
Engineer
Lead Automation Engineer
Chief Architect orLead Developer
Senior Product Manager
Leadership Team
Senior Product Marketing Manager
Scrum of Scrums MasterBusiness Analyst, CBAP
Lead DBA Creative Director
Scrum Master Business Analyst Product Owner
Product Manager
DevelopersFront-End Dev, Back-End Dev
Quality Assurance
Scrum Master Business Analyst Product Owner
Product Manager
DevelopersFront-End Dev, Back-End Dev
Quality Assurance
Scrum Master Business Analyst Product Owner
Product Manager
DevelopersFront-End Dev, Back-End Dev
Quality Assurance
Feature/Product Team 2
Feature/Product Team 4
Feature/Product Team 3
Contributor Types • EVP Product Management
– Product Owners (IIBA’s) • Lead IT Porgolio Manager
– ScrumMasters • Chief architect
– Lead Infrastructure Engineer • Suppor&ng IT staff
– Developers – UI/UX Expert – QA Staff – UAT (CEO, CFO, subsidiary and Focus Groups)
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
Risk
• Comple&ng everything in six (6) months – Development and deploy all apps to produc&on
• iOS apps to the apple store • Droid apps to the android market
• Securing credit card data in the cloud
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
Problem/Resolu&on
• Problem – Securing data in the cloud
• Resolu&on – Hybrid Cloud
• Public and private side
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
• Keeping credit card data on file
Use Case 1
XXXXXXXXXXCardholder Name:
XXXSecurity Code:
XXXX"XXXX"XXXX"X123Card Number:
Credit card Information
Expiration Date:
Telephone: XXX - XXX - XXXX
201412
XXXXXXX - State - XXXXXCity, State, Postal Code:
VisaCard*Type
Payment(Informa-on
XXXXXXXXXXAddress*Line*1:
Billing*Address*associated*with*this*card
Address*Line*2:
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
• Housing and sharing pa&ent data for various purposes, but especially an HIE (Health Informa&on Exchange)
Use Case 2
Virtual DB
DBDB
DB ApplicationServer
Hospital
DB ApplicationServer
Hospital
DB ApplicationServer
Hospital
DB ApplicationServer
Hospital
DB ApplicationServer
Hospital
DB ApplicationServer
Hospital
DB ApplicationServer
Hospital
DB ApplicationServer
Hospital
Clinic Clinic
ClinicClinic
Clinic
Clinic
Clinic
Clinic
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay
• IaaS -‐ Work environments for different purposes – Development environment – QA environment – Staging Environment – Sales Demo environment
Use Case 3
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
Financial Institutions
Browser
Web Application
Auxiliary Services
Virtual DB
TransactionServer
AuxillaryApplication
DB
Comm Network
Computer
PhysicalComputingServices
Cloud ComputingService
PCI Compliant Public Hybrid Cloud Overview
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
The Need and Benefit
• Cloud compu&ng offers the following: – No massive equipment purchase – Lower Total Cost of Ownership (TCO) – Remote management with ease – Increased speed to market – Greater efficiency
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
The Need and Benefit Con&nued
– Scalability – Faster and easier development – Ease of produc&on deployment – Plagorms for modular development – Unmatched flexibility – Infrastructure as a service
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
What is inside the Cloud?
• Encapsulated complexi&es of the infrastructure that normally would be in a server room are now virtualized
• No need to see and/or know what exactly is in your cloud only the services it delivers
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
Why a Hybrid Cloud?
• Combina&on of applica&on, sonware and hardware for PCI compliance
• Private secure Cloud for the PCI data – Security is the main concern.
• Public Cloud for consumer facing applica&ons
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
PCI Compliant Hybrid Cloud
• Combina&on of a public and private cloud • Private cloud secure for storing credit card processing data
• Public cloud for allowing access to consumer facing web applica&on(s)
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
PCI Compliant Hybrid Cloud Produc&on Diagram
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
PCI Compliant Hybrid Cloud Patent Process
• Func&onal decomposi&ons • Sequence Diagrams • Flow Charts • Network diagrams • Fully documented process and patent applica&on
• Demo fully func&onal PCI Compliant Hybrid Cloud in produc&on
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
Non Provisional Patent Applica&on Filed
Hos9ng E-‐Commerce Based on Cloud Compu9ng CROSS-‐REFERENCE TO RELATED APPLICATIONS The instant applica&on claims priority to and incorporates by reference for all purposes United States provisional patent applica&on number 61/471,666 filed April 4, 2011, en&tled “Hos&ng E-‐Commerce Based on Cloud Compu&ng,” by Benjamin Franklin Clay, et al.
[0001]
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
Future for the Cloud
• Endless possibili&es – Next most important is GHIE
• Global Health Informa&on Exchange
– Global Financial Informa&on Exchange (GFIE) – Global Intelligence Informa&on Exchange (GIIE) – Global ANY KIND OF Informa&on Exchange
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
Q&A
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay and Rob Morrow
Contact Info
Ben Clay [email protected] Linkedin hEp://www.linkedin.com/profile/view?id=49080988&trk=tab_pro
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay
Bonus Slide 1
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay
24/7
No YesHave you groomed the product backlog?
PreSprint Plan(Sprint 0.x)
Groom the Product Backlog
Don't expect the Team to read your mind!
Sprint Plan
Release Plan
Have you broken user stories into high level
task?
Yes
Have you estimated all the tasks & rolled them up into one estimate total?
No
No
YesHave you finished the Sprint
No
Sprint Showcase
Was the Product accepted by the Product Owner?
Yes
Practical Scrum Work FlowBenjamin F Clay © 2012
Yes
No
Have you added up the totals and calculated the end dates of each sprint?
No
Release Backlog
Yes
Start Here
Based on need. I
schedule once a week
reoccurring
Every 24 hours
Daily Scrum
Sprint
Meta Scrum
If not accepted
then the team
didn't do all the
user stories
committed to
PreRelease Planning (What the business would like to have)
Once every week
Scrum of Scrum
Release BSchedule(add shippable
product)
Time Range Es&ma&on Bonus Slide 2
TIME RANGE ESTIMATION CHAPTER 4 FIBONACCI TIME RANGE ESTIMATION SEQUENCE Each team member will give a number to weight each task with a total weight for each story known as story points. This is based off of an eight (8) hour business workday. 1,2,3 and 5 are the numbers to be used. 1=easy,.30–4hours 2 = easy &me consuming, 4.5 – 8 hours 3 = medium 8.5 – 16 hours 5 = advanced, 16.5 – 24 hours No story point shall be greater than 5. If it is determined to be greater than 5, the task shall be broken down into smaller tasks. ESTIMATING THE TASK If a team member thinks the task will take four (4) hours and ten (10) minutes then you assign two (2) story points to that task. By assigning two (2) story points to this task you have effec&vely stated that this task could take four and a half (4.5) to eight (8) hours to complete. This covers most anomalies and/or scope creep that might arise for that task. Always round up ensuring that you aEempt to cover anomalies and/or scope creep. If a team member es&mates it will take four (4) hours to complete a task you also assign two (2) story points to that task. Always round up to the next increment. Following this method for all the tasks it takes to create all user stories allows for managing scope creep by automa&cally buffering the &me range es&ma&on allowing room for a certain amount of addi&onal and/or development changes. Obviously it isn’t meant to be a way for business to force the team to do more work, but rather enough buffer to catch a certain amount of incidentals only. You will s&ll need to manage this, but at least you will have some wiggle room.
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay
Time Range Es&ma&on Bonus Slide 3
TIME RANGE ESTIMATION CHAPTER 4 DAILY WORK LOGS A team member should always log the actual work not the es&mated work. The actual work may have taken less or more &me than es&mated and by logging and/or recording the actual &me it took to complete, the data is referenceable and can be used to compare against similar task in the future. This data will also help the team become more accurate and/or efficient with &me range es&ma&on allowing for the Scrum Master to more effec&vely forecast anything from story points to produc&on deployable dates. There are a lot of scenarios I could talk about here concerning miss logged work, but I will talk about only two of them. Scenario 1. An inexperienced team member is not accurately es&ma&ng the task logging more points than es&mated. May need some remedial task &me range es&ma&on from the team lead and/or help breaking down and es&ma&ng their future task. Scenario 2. An experienced team member es&ma&ng more &me than it should take and logging those points for the purpose of appearing to do more work than they really are. If a team member is always logging as many points as they es&mate have that team member pair es&mate with the team lead and/or a senior developer. I’m sure if you have problems like the above or more your team will let you know. No one likes to take up the slack while others are sliding by. There are a lot of reason why es&ma&ng like this won’t work, but there are a lot of reasons why it will. More than that you can use just the &me range es&ma&on should you want to not use story points.
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay
Time Range Es&ma&on Bonus Slide 4
TIME RANGE ESTIMATION CHAPTER 4 Establishing Team and/or Individual Veloci9es From this point it is easy to show the es&mated team velocity prior to the sprint start date and then monitor the actual team velocity during and/or aner the sprint. This also makes it easy to manage scope creep as long as the work logs are entered daily or at least semi daily. Establishing any velocity has some kind of monetary meaning &ed to it and is why I &tled this sec&on, “Establishing Team and/or Individual Veloci&es”. The fact is someone has to present something to a governing body of one or more people or group such as a board of directors. I have used team veloci&es to assist me in the forecas&ng of break-‐even points, Return On Investment (ROI) and lowering the Total Cost of Ownership (TCO). I have used Individual Veloci&es to show why a company should invest money in a developer and/or any other member of the team by training them, giving spot bonuses, base pay raises and/or any other monetary gain or incen&ve. Combine all this data and you can confidently forecast your team’s velocity from sprint to sprint or even quarter to quarter.
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay
Time Range Es&ma&on Bonus Slide 5
TIME RANGE ESTIMATION CHAPTER 4 TIME RANGE ESTIMATION EXAMPLE Team Es&mated, Actual, Forecasted Es&mate and Forecasted Actual Veloci&es
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay
145
152 156
138
152 154
151 148
125
130
135
140
145
150
155
160
Sprint 1 Sprint 2 Sprint 3 Sprint 4
Team 4 Estimated, Actual, Forcasted Estimate and Forcasted Actual Velocities
Estimated Actual Forcasted Estimate Forcasted Actual Linear (Actual)
Time Range Es&ma&on Bonus Slide 6
Disclaimer All forecas&ng data should be based off the same four series of sprint dura&on, team size, experience level and skillset level. Should any of that change you will need to start over and average out at least three successful sprints. All my data was based off of a twenty-‐one (21)-‐business day sprint cycle.
© 2009 – 2012 WriEen and All Copyrights reserved by: Ben Clay