Enterprise Software as a Service : DrupalCon 2017 GovSummit

Editor's Notes

• #2: Thank you for joining me today!
• #3: My name is Kendra, and I work for the state of Georgia in our digital services team. As Director of Product, I manage the roadmap for our enterprise Drupal 7 CMS. That means I keep the pulse of the whole system, plan maintenance, enhancements, training and support, etc. More importantly, it means making sure the CMS we provide meets the needs of our agencies and citizens. I’ve been with this team for a very long time now, so previously I’ve done the front-end development, design, testing, customer support, training, account management, and governance for our platform - so I have a good idea of how all the pieces come together.
• #4: First, how many of you are: Federal? State? Local? Who maintains ONE site? More than one, but less than ten? 10 to 25? More than 25? Who are our developers? Frontend? Business / Management? If you maintain multiple sites, are they under the same codebase? Multisite? Another way to manage them together?
• #5: My goal today is to shine some light on how we handle our Drupal websites within the state, and give you some food for thought on how it may apply to your organizations. I’m going to try to cover a lot of ground in a short period of time - and I’ll be more than happy to dig into any at length after the session.
• #6: Just in case you haven’t heard that term before, SaaS = Software as a Service. Georgia’s had an enterprise web service since 2001 - it’s been a Drupal-based solution since 2012. We have a Drupal multisite environment that we offer to state agencies. It’s a proven model that works. And it’s a model we’ve iterated on and expanded on it quite a bit since it’s inception. So when I say we have a SaaS, what does that mean? First, an illustration. Think back to the internet 20 yrs ago...
• #7: In the beginning, there was HTML. We had static HTML pages, and GeoCities provided a way for anyone to build their own bit of cyber real estate - with a bit of bravery to learn markup. It was the wild west- anything goes. And also, anyone who wanted a bit of space had to learn how to maintain it, or let it languish.
• #17: Why do we edge towards the “managed” side of the spectrum? As you all know, maintaining website services requires a lot of resources and expertise. traditional models - each agency has their own individual IT/Web department to support their website, OR hire an external vendor to build & maintain for them (with CONTENT being the area where each agency is the subject matter expert.)
• #18: this becomes a huge duplication of efforts when spread out across each agency IT is not most agencies’ area of expertise, so strategy and usability often takes a back burner.
• #19: This is where we come in. by consolidating the IT technology and skillset into a central platform cost savings by Meeting shared needs central governance & best practice (strategy) agencies focus on their area of expertise - their content Think of it as squarespace for a specific audience. Our audience is Government. We’re finding those common needs across agencies, and meeting all those shared needs with one codebase.
• #20: high level view of how our platform is set up. We maintain an enterprise web content management system based on the open source CMS - Drupal 7. Drupal is highly flexible and highly customizable, but isn’t very useful “out of the box” - it requires a lot of customization to really start meeting needs. So on top of the core Drupal 7 code, we use a distribution of Drupal called Open Public, which was developed to servegovernment website needs On top of that we have our own customizations to better provide for our agency customers. Then we get to how the sites LOOK - we have a base theme that controls the general structure of the sites And custom theming - customized styles, fonts, and colors - that each agency can choose from.We have 13 of those custom themes. Then each site has its own CONTENT - informational pages that take a lot of different forms. We have 76 sites altogether.
• #21: The Open Source community controls the code for base Drupal and the Open Public distribution Each individual agency controls their own content. Where we have our sphere of influence is with our custom code and the themes - so that’s where we can focus our efforts for improvement We’ve identified key needs (types of content, branding, display functionality) that are shared across agencies, and provide those. Improvements to one page type, then, benefits every page across the platform that uses that page type. And improvement to a theme benefits all the sites that use that theme.
• #22: this model speeds innovation we can prioritize an enhancement roadmap and do it ONCE to serve all these customers more recent initiatives include…
• #23: cloud hosting and open source solutions take it a step further. It furthers our cost savings, taps into community expertise, and allows us to react more quickly to security risks, changes in technology and innovation. We don’t have to have teams of experts managing everything - we’re focused on scale and shared expertise in both hardware and software.
• #24: But here’s a key thing to keep in mind with this centralized model. We do not outsource strategy and planning to a vendor. Our team doesn’t have to focus on a bottom line of making money. Our motivating factor is serving our agencies and - most importantly - all Georgians. We don’t have to say “yes” to every expensive, outlandish request just to make money.
• #26: Enterprise strategy is realizing that you can’t - nor should you - build everything that comes around. This may be obvious, but it means planning a way forward keeping in mind how that will impact multiple agencies at multiple levels. You need a framework around how you prioritize your roadmap.
• #30: As we complete initiatives, we build those principles into all future development.
• #31: Roadmap of completed initiatives (as our platform has grown in sites and needs). Completed initiatives become part of our core requirements going forward.
• #32: This requires intentionality at every stage - requirements, design, development, testing, content They’re not part of a default mindset - if we don’t keep up on them at the development and requirements level, they’ll be forgotten.
• #34: There are limitation to sharing a codebase because updates have implications across sites. Individual agencies have to give up some autonomy to reap the benefits of a platform
• #35: To quote Mick Jagger and Keith Richards, with enterprise software, you can’t always get what you want. Sometimes we have to say no to feature requests that would be a huge lift for minimal benefit.
• #36: We trade off momentary whims and fancies in exchange for Making sure the audience has what it needs to access key information / services
• #38: It’s important for us to approach our enhancements with a problem-first mindset, not solution first. We seek solutions to agency problems. Not “what module does this” but “what’s the best way to meet this goal?” Example - agency keeps asking for an automated “last edited” timestamp on every page. They’re asking for a solution. We ask what the problem is - the problem is a small handful of pages that specific subgroups look to and need to know when they’ve been revised. The solution they proposed isn’t the most effective (cost, time, effort) way to address their problem. Example - agency says “we need to see all your themes,” or “we need a new website design.” But the problem is that they are overwhelmed by the amount of outdated content on their website - content that they manage. The solution is a content audit and content cleanup - not a new theme or new website.
• #40: So we can’t (nor should we) add every feature any tenant requests. This is where governance comes in - figuring out what guardrails we put around our system - from the beginning - to keep it from becoming unweildy. We start with that user-first focus - we’re building this for people who need access to government services, not to scratch the itch of a commissioner or an IT team. Depending on the size and structure of a team will dictate how much flexibility you can offer in your governance model. What works for us may not be what’s best for you.
• #41: I look at it as three basic models - again, they’re all going to look a little different, but here’s some basics to start thinking about.
• #42: Our model - tight governance at the top. We decide what gets developed, we do the development. Everything gets shared across - though sometimes we keep features disabled until requested. SaaS Note that each version considered central hosting management. Once agencies are hosting their own, you’re just back to normal open source.
• #43: Agencies can request new features, which may or may not be selected for development.
• #44: With distributed development, you’re setting up methods for agencies to contribute their own code back, as well. They’re making those mature decisions of what is worth building, and making sure it meets standards. Then they contribute that back to the codebase, and central management audits the code to determine whether or not it should be folded back in and shared out. (govCMS in Australia follows a model similar to this)
• #45: When you distribute management on the same hosting, this is more of a Platform as a Service model. The distro is built and maintained, but anyone can take it and customize, and maintain their own version of it. Everyone may fork off from the same beginning distribution, and they may even contribute back updates to the core distro, but aside from that everyone maintains control of their own version of it. You’ve lost a lot of the benefits of central hosting (speed of innovation for the whole, lower dev costs, etc), but the groups that really need that unique snowflake treatment can control their experience just as they want it.
• #47: Whatever your model, communication with your tenants becomes key. We have to keep a pulse on what they need and make sure they know what we’re doing. It’s hard for some agencies to let go of full control - if we keep communication with them it lessens that pain.
• #49: Provide options for more open partnerships and code ownership for agencies that want it.  Not everyone can or will host with us - loosen our model to allow more code sharing outside the central model. Our themes have gotten too limited - we’re looking to pattern libraries and more flexible layout and theme solutions. Think outside the browser. (plug Nik’s talk) https://events.drupal.org/baltimore2017/sessions/cultivating-digital-ecosystem-do-you-have-holistic-digital-strategy
• #50: We also need to think outside the browser. If we’re only developing with “websites” in mind, we won’t meet our audience where they are.
• #51: We need to be thinking about our holistic strategy. Mobile, but also conversation and chatbot. Content APIs instead of content living only on a website - or even worse, different answers to the same question living in a dozen different locations within an agency’s disparate systems. We need to build integrated digital ecosystems.
• #52: https://events.drupal.org/baltimore2017/sessions/cultivating-digital-ecosystem-do-you-have-holistic-digital-strategy
• #53: Finally, as we look ahead to future goals, we want to collaborate more with you. Other states, other gov’t entities have similar challenges and needs, too. How can we work together?
• #54: I could talk about any one piece of this all day. If there’s anything that struck a chord, let’s chat. Particularly if you want to find places where we can collaborate, or are working on your own sharing models.