REFERENCE TEXTCoding the Architecture by Simon Brown: http://www.codingthearchitecture.com/pages/book/just-enough-architecture.html“At one end of the scale you have waterfall that, in it's typical form, suggests big design up front. And at the other end you have the agile methods that, on the face of it, shy away from doing architecture. At this point it's worth saying that this isn't actually true. Agile doesn't say "don't do architecture", just as it doesn't say "don't produce any documentation". Agile is about sufficiency, moving fast, embracing change and delivering value. But since agile methods and proponents don't put much emphasis on the architectural aspects of agile projects, many people have misinterpreted this to mean "agile says don't do any architecture".Sitting between the ends of the scale is the Rational Unified Process (RUP). Many RUP implementations are heavyweight monsters that have more in common with waterfall than they do with other iterative and incremental methods, but RUP can be scaled down to exhibit characteristics that let it take the centre ground on the scale. At its heart, RUP is a risk-driven methodology that basically says, "gather the majority of the key requirements, get the risky stuff out of the way, then iterate and increment". Done right, RUP projects can have a nice balance of up front design and evolutionary architecture.”
REFERENCE TEXTDefinitions of Design Thinking by Tim Brown (http://designthinking.ideo.com/?p=49)Design Thinking by Tim Brown (http://hbr.org/2008/06/design-thinking/ar/1)Design ... Design Thinking by NitjyotSaroan (http://blog.emerson.edu/integrated_marketing_communication/2009/10/design-design-thinking.html)“Design thinking can be described as a discipline that uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.”
How to we adapt and scale the RHUL Project Governance Framework so it is suitable for all kinds of IT development work (projects, application and annual lifecycle maintenance, work requests and product management)?
How to we make governance processes simple, easy to understand and easy to use?
SIMPLE ADAPTIVE DEVELOPMENT PROCESS and GOVERNANCEUsing simple project stages and ‘design thinking gateways’.
PROJECT STAGES and DELIVERABLESReferencesAdapted from Project Enterprise Architecture Toolkit (PEAT) Navigator: Essentials and Key Concepts Modulehttp://www.exeter.ac.uk/value/casestudies/enterprisearchitecture/resources/
Transcript of "Rethinking the development process"
Development “the change needed to improve a service by innovating*”Idea!Problem! Realised Benef Innovation Improvement *innovation = the use of a new idea or method.
Development in the Large: Solutions and Services not(just) Software • technology demonstration, advocacy and training • improving processes, procedures and standards • bulk data transformation • automating a regular task • configuring a system • coding or installing software • experimenting with technology capabilities
Principle: Elastic Governance.A single model; shared standards; multiplepatterns.Adapt the model to fit the work.Plan and measure work at the highest levelpossible to complete the right work to therequired level of quality.
Principle: Embedded GovernanceGovernance is about guidance not control.Make it harder to avoidprocedures, guidelines and standards thanit is to use them.Encourage innovators withoutcompromising service reliability or userexperience.Coach and advise.
BenefitsWhat did we Business Casegain/learn? Is it desirable? 5 1 Propose 0 Plan Review Backlog of Solution Design 2 Ideas and Is it feasible? Issues Release PlanService OperationIs it ready? 4 Implement 3 Service Delivery Is it viable?
Common / Key End RHUL Project GovernanceStages Simple Project Simple SDLC Deliverables Milestones FrameworkStart Up Project Proposal M1 Gateway 0 ProposeJustification Detailed Business Case M2 Gateway 1Initiation PID M3 RequirementsRequirements Definition Requirements BlueprintM4Architecture & Feasibility Architecture Model M5 Plan Gateway 2Detailed Design Design Blueprint M6 Design Gateway 3Buy/Build Development Plan M7 BuildTesting Test Plan; Detailed Test M8 Plan; Test Results ImplementIntegration Integration Plan; M9 Accept Reference ArchitectureInstallation & Verification Installation Plan and M10 Deployment Package; User Documentation DeployTransition Planning & Validation Release Plan; Service M11 Gateway 4 Model ReleaseOperation Service Operation Form M12 and Support PackageMaintenance Change Request M13 Process TransitionReview Lessons Learned M14 Gateway 5 ReviewClosure Project Closure Report M15
Rethinking the Development ProcessInformation Technology This slide deck is licensed under a Creative CommonsRoyal Holloway, University of London Attribution-NonCommercial-ShareAlike 3.0 UnportedOctober 2012 LicenseAuthor: Alison Pope, firstname.lastname@example.orgContributors: Alison PopeVersion: 1 Revision: 4
References• Geek and Poke http://geekandpoke.typepad.com/geekandpoke/2012/01/simply- explained-dp.html• Coding the Architecture by Simon Brown: http://www.codingthearchitecture.com/pages/book/just-enough- architecture.html• Definitions of Design Thinking by Tim Brown (http://designthinking.ideo.com/?p=49)• Design Thinking by Tim Brown (http://hbr.org/2008/06/design-thinking/ar/1)• Design ... Design Thinking by Nitjyot Saroan (http://blog.emerson.edu/integrated_marketing_communication/2009/10/design- design-thinking.html)• Project Enterprise Architecture Toolkit (PEAT) Navigator: Essentials and Key Concepts Module http://www.exeter.ac.uk/value/casestudies/enterprisearchitecture/resources/