Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Architecting govCMS: Australian Government as a Service -

640 views

Published on

The Australian Federal Government has taken the revolutionary step of standardising on Drupal in public cloud. govCMS is a 'Whole of Government' solution that any federal or state level agency can join, leveraging the infrastructure, knowledge and experience of the collective government.

By pioneering this solution, the Australian Government are putting a stake in the ground and challenging the traditional private, proprietary, closed source approaches taken in the past. This opens up new possibilities for governments around the World in their search for an ideal platform to interact with their citizens.

Published in: Government & Nonprofit
  • Be the first to comment

  • Be the first to like this

Architecting govCMS: Australian Government as a Service -

  1. 1. Australia - govCMS Government as a Service NYC Camp 2015
  2. 2. David Peterson Senior Solution Architect Asia Pacific & Japan, Acquia @davidseth #govCMS
  3. 3. What is govCMS Why Open Source Best Practices What we have Learned Future
  4. 4. govCMS is a whole of gov re-think about online, agile, accessibility, procurement, security, support and open source. Not just code.
  5. 5. • What is govCMS • Aims • Why did it come about The govCMS Program
  6. 6. govCMS SaaS Platform govCMS Distribution govCMS Deed Professional Services
  7. 7. • Drupal • Security • Public Cloud • Deed • Agile • Design Standards / Accessibility • Services govCMS
  8. 8. • Disparate technologies • Costly hosting and software maintenance • Substantial staff overhead to keep websites online and secure • Difficulty complying with gov standards: design, accessibility, privacy & security • Limited number of staff within agency with appropriate skills to manage the website govCMS What Problems does govCMS Solve
  9. 9. • Reduced time for procurement • Improved mobile delivery • Cost savings related to sharing of code between agencies • Better portability of websites during MoG changes • Reduced stand-up time for new websites Benefits
  10. 10. • Portability of talent as people move between agencies • Increased desire to upskill with Drupal • Encouraged to share code and be part of community Benefits Total Reinvention of Skills and Sharing
  11. 11. How did it come about
  12. 12. • Policy for eGovernment and the Digital Economy [let’s go online] • AU gov’s Open Source Policy [share code and functionality] • AU gov’s Cloud Computing Policy (v3) [save costs, ensure security] • Best practise service design — DTO [accessibility & easier to use] Modern Approach to Tech
  13. 13. Open Source
  14. 14. • Security • You can look at the code • You can diff the code • Many eyes - Community • Roadmap • Community Open Source Why is it Dominating in Australian Government?
  15. 15. • Roadmap • Community • Broader adoption by Aussie companies • Shared code, create once use many Open Source Why is it Dominating in Australian Government?
  16. 16. Principle 3 of the Australian Government Open Source Software Policy: “Australian Government agencies will actively participate in open source software communities and contribute back where appropriate” Functionality created by one agency can be made available for all Open Source Why is it Dominating in Australian Government?
  17. 17. • Must be *truly* Open Source • Must not be .Net or Ruby • Resulted in 18 systems • 3 finalists: Magnolia, Liferay, Drupal Open Source Australian Government Criteria for CMS
  18. 18. • Largest community • Largest number of companies in AU • Largest number of freelancers • Extensibility of module system Open Source Why Drupal was Selected
  19. 19. • govCMS distribution available on d.o and github • https://drupal.org/project/govcms • https://github.com/govCMS/govCMS/ • IRAP assessment against the ISM (used FedRAMP mapping) • Always updated for security and feature enhancements govCMS Distribution
  20. 20. Dependancies: git$&$composer :$git$clone$git@github.com:govCMS/govCMS.git$ :$cd$govCMS$ :$composer$install$<<prefer<dist$<<working<dir=build$ :$build/bin/phing$<f$build/phing/build.xml$build govCMS Distribution Phing for build Behat for testing Travis CI used for test runner
  21. 21. Drupal Code Security Skills Cloud Best Practices
  22. 22. • Saves an agency time • Compliance ticks out of the box: • Public cloud • Open Source • IRAP assessed • Alignment to the ISM Best Practices Drupal > OOTB
  23. 23. • Continuously improved • Security maintained and the distribution regularly updated • Meta data standard minimums adhered to • Can just get on with maintaining the sites content Best Practices Drupal > OOTB
  24. 24. • Really limit number of Drupal modules • No module creep • Limitation was the best part • Learning to use drupal • Finding the balance to what the client *thinks* they need vs what they actually need Best Practices Drupal > Distribution
  25. 25. • 85% of functionality, give up some functionality for stability & security • Frame limitations as a feature, don't start with can't do this, can't do that • Start with Security, Stability and Performance • It's about the efficiencies, they don’t have to think about it, they know they are getting value for money • Really it is more than the distro. Whole is greater than the parts. • Don’t code your way out of every Drupal problem. Use Drupal. Best Practices Drupal > Site Building
  26. 26. • Governance is key • Thoroughly documenting the procedures allows for security accreditation, who's responsible, owning the roadmap, ensuring stability • Preference for secure, stable code over "there's a module for that". • Initially a "hard sell" but as soon as the positives are discussed quickly dissolves Best Practices Code > Governance
  27. 27. • Requests for new functionality follow a prescribed process: d.o issue, reviewed by gOps team, • Don't ask for a specific module, propose a problem • "I would like an email sent out when a content item needs approval" • gOps team will look into potential reusability across other govCMS sites as well as best implementation • Automated testing is crucial Best Practices Code > Adding new Functionality
  28. 28. • Every site is secure by default (even the forgotten ones) • https everywhere • Locked down protected Drupal paths • No storage of PII information (yet) • Antivirus • Best practise platform, configuration, DNS management • Expert DDOS & CDN Security
  29. 29. • AWS Sydney Region across both Availability Zones • Acquia Cloud Site Factory • Constant monitoring • Over engineer your security stack • Disaster Recovery • Offsite archival backup 7 years • Offsite Log storage 7 years Cloud
  30. 30. • Less is more •Keep modules to a minimum, every single one needs to be updated tested. Gets even more critical when running 100’s of sites •Have a process to get new functionality included into govCMS • Jumpstarts to enable teams • Get beginners up and running quickly • Agile training • Support What we have Learned
  31. 31. • Massive amount of interest from agencies large and small. Four of the largest largest AU agencies are all building sites on govCMS, one launched so far. • Larger Agencies want to be part of the platform strategy • Agencies are happy to share back functionality to govCMS distro • Much wider impact on other State and Local gov • schoolCMS • councilCMS What we have Learned Uptake
  32. 32. • Pattern 1 — basic site, good fit for govCMS • Pattern 2 — bit more complex, “may” need some additions to govCMS • Pattern 3 — a lot of extra functionality, needs some additions to govCMS What we have Learned Build Patterns
  33. 33. • Build pattern sites that can be cloned • Set of configuration all bundled up in a site that no one will run in production but can be used for a starter site • I've got limited budget, what is the best way to get going? • Sub theme, change colours, replace content and they go. One week later • And these sites are rock solid secure, DDOS, updated with security patches What we have Learned Build Patterns
  34. 34. Skill Sets Low Complexity Medium Complexity High Complexity
  35. 35. Expected Project Uptake
  36. 36. • Cloud Security best practices • Code Security best practices • Automated testing best practise • Drupal distro Sharing
  37. 37. • Expanded functionality • Platforms for • School • Local Government • Councils • DTO —Digital Transformation Office •Government as an API Future
  38. 38. Questions? @davidseth #govCMS

×