Hannah: Today’s webinar is Building a Common Drupal Platform for your Organization Using Drupal 7 with Erik Webb, who is a Sr. Technical Consultant here at Acquia. We’re very excited to have him presenting this topic today. I’m Hannah Corey and I’m a Marketing Specialist here at Acquia.
Erik: Today’s webinar is primarily focused around, really trying to look at this newer model of, especially in distributive organizations where there’s lots of teams, lots of different developers, owners, stakeholders that are really spread out across the company’s organization, and really trying to find a common platform for all of them to work off of.
We would rather this than trying to force everyone to be all together on one site and artificially creating those sorts of barriers or having this really wide open landscape of way too many tools. The management gets really difficult at a certain point. We’re going to talk about some methods to be able to standardize on Drupal, but at the same time also give people the flexibility to extend their own sites in different ways or even take ownership in the needs that they have.
First, I just want to talk about a quick agenda of what to expect here. I want to talk about what is a platform. There’s the platform as a service. There are lots of different definitions of what a platform is these days, but I want to make sure we’re all talking the same terminology and understanding what the word platform means, at least in the context of this particular presentation. We’ll look at some types of platforms. How do these platforms actually work in different ways and what are the strengths and weaknesses of each different form?
Achieving buy-ins. One of the biggest things that a lot of people have difficulty with in platforms and trying to centralize people around one sort of idea, is people are afraid they’re losing control or they’re somehow losing the autonomy that they had previously. I’ll be specifically talking about the main points you can use to sell the story.
The last two things that I want to cover is Leveraging Drupal. What are the main features of Drupal that make this kind of platform attainable and even easier, maybe, than some other tools? Lastly, looking at how Acquia fits into all this. In talking about all these different kinds of platforms, how can you leverage Acquia to take advantage of, not only Drupal, but the hosting packages, the reusable templates? What makes this whole process really accelerate and easier for everyone to manage?
First, let’s talk about what is a platform. I’m sure everyone that’s joined us today. It’s a big buzz word that’s out there that means a lot of different things to a lot of different people. Is this a platform? Sure, it’s a platform. It’s a different world, but it works the same way. Train stations, those are platforms. But, even in the technical world, what’s so funny is there are even discrepancies in the technical world. If you look at PC Magazine, their basic definition looks at the architecture of any sort of generic foundation or base, which is about as generic of a definition as you can get. John C. Dvorak is kind of an internet curmudgeon. For those of you who don’t know who he is, he’s an internet journalist. He looks at platforms as really just something that other people can build other products off of, which I think is a very intelligent way to look at it.
Dr. Jeffrey Jaffe, a CEO of W3C, an organization that standardizes the HTML standards and functionality and some of the other standards that make the internet work. I love this little clip from him that says, “It’s a sandbox to innovate and create the next generation of computing applications.” Again, it’s really a generic sort of definition, but, for him, it’s leading towards where technology is headed. It’s not about reinventing the wheel every time. It’s about having that good, solid base that you can innovate on and create new ideas.
Possibly the best definition of it I’ve seen is from Marc Andreessen. He’s a big PC person out in California. I think this is the definition that fits the most of what we’re talking of with Drupal as a platform. He says, “…it’s adapted to countless needs and niches that the platform’s original developers could not have possibly contemplated.” I think this is where you really see the power of building off of a platform is not only looking at how you know the use cases will work, but giving people the opportunity to create something special out of what you’ve done and benefit the entire platform. Kind of feed back in and grow on top of itself.
What are some of the main goals of these platforms we’re talking about? The number one absolute goal is just to make people more efficient. Developers have to spend less time re-doing codes. They have to spend less time bug-fixing because they fixed the same bug in the same place before. It also makes the content-creators a lot more efficient because they seeing the same interfaces, the same types of sites and they’re not having to re-learn every single time how to work on each site. It makes everyone quite a bit more efficient. It inspires collaboration over isolation.
In this case, if you look at the, the analogy we’ll be working through is a higher-ed, university- type examples, and having a platform where everyone’s sharing these common features. You can have all those users talking amongst themselves and figuring out cool ways to leverage those features that you’ve created for them rather than splitting them all off on different pieces of software and having them all struggle to fill the same sort of void that they all have just for them to begin with.
Increasing innovation? Same sort of idea. If people are working together and sharing ideas, that’s where the platform shines and grows beyond just a maintenance fast track.
Decreasing risk and making business more successful? Obviously if you have a platform that is tried and true and you can ramp up new sites and organizations on them very quickly, then it reduces risk for everyone because you’ve already solved the problems and you’ve already tested to make sure that everything works well together. Overall, it helps the developer, the content users, the business people behind the projects. It’s really a win-win for everyone if it’s phrased in the right way.
Let’s look at types of platforms. Some of these don’t have platform in the name, but in reality they fit these generic definitions. Infrastructure as a Service. This is something like Amazon Web Services, where they’ve set up all the service for you, all the hardware in kind of an abstracted way so you don’t have to worry about it, but more or less you’re really left with a bare system to work off of.
Platform as a Service is something like Acquia’s Cloud Solutions, where the infrastructure’s not only taken care of, but so are optimizations and the set-up required to get a piece of software on top of it and run efficiently.
And last, Software as a Service is kind of an even farther evolution of that, where now you’re not even concerned with installing the software and maintaining updates to it. You’re really looking at something that is just there so you can just jump in, get things built, and really get out of the way without having to spend a lot of time just on that initial set-up. It’s really about the rapid prototype, rapid site creation. This is similar to the Drupal Gardens Product from vernacular that we’ll talk about a little bit later.
This is what a typical, higher-ed sort of landscape looks like with a lot of different colleges. All these features, some have internal developers, some have external developers. Some are e-commerce, some have student data. Some don’t have student data and don’t need to be secured. One’s in PHP, one’s in dotNet. It’s really all over the place because, realistically, this is how large organizations naturally kind of grow.
As each group comes up with their own needs, their own use cases, their first natural instinct is to go out there and do it. Part of a platform is really sort of a policy issue of trying to get people back in together to make it an organization-wide initiative and not splitting off all these other teams and losing that efficiency that a large organization really needs to run well.
Just looking at some simple examples of a platform, a performance infrastructure is something like Acquia’s Cloud. Something that’s tuned for performance, but it’s built on top of what you would normally think of as a hosting provider.
Container hosting. A very similar idea. It’s usually a little generic just outside the world of just Drupal, but it’s something that’s really built on top of it. Anything below a certain line, you’re not really concerned about. Everything above that is where your specialists lie, where your knowledge is.
Some other great examples are regional publications for a publishing company. All those publications are going to share very similar features, very similar functionality, same type of background for users, but there’s no need for each one to reinvent the wheel and come up with a new solution every time. Using a platform is a great way that they can all leverage that same functionality without trying to do too much work every time a new region is put up or every time a new re-design is needed.
Now let’s talk about how you get the buy-in from customers. I think this is the hardest part of getting people to normalize onto a platform is understanding that it is addition by subtraction. They’re gaining a lot of different advantages even though they are losing some control. That’s the hardest thing to convince. Here’s what I would pitch as to sort of bring in as a platform into an organization.
Let’s start on the negative side. Let’s talk about the problems that, when I’m out on-site with clients, these are usually the types of concerns that come up and are a primary issue for people. The biggest one that I’ve seen is that it’s a common problem that is affecting everyone in the organization. Whether it’s an internal tool or an external tool, it’s something that people think are different use cases where, if you break it down into technical requirements and business requirements, it’s actually not that different. People see the scope or the visibility of the application and assume that these things are somehow unmanageable together. In reality, that’s usually not the case.
There’s also a cultural shift. One of the biggest things is, in most organizations, people are very accustomed to looking at things on a project basis. Meaning, if a new site’s launched, that gets its own allocated resources, its own people, its own servers, its own environment to work off of. Moving to a platform is more of a product or a service where there’s an internal core team that’s keeping that afloat, keeping things running well, and it’s the job of each one of these new projects that spins up to just come in and work with that team. Rather than filing off all this development, it’s kind of a fundamental shift on how resources are allocated and how projects are run at most organizations.
Some of the other things that people are usually scared off by sharing all this use cases and all this information is they think they are sharing content between all these sites because they see it as one large service. A lot of this is positioning of your specific platform, but the biggest things is people are worried that one team in an organization and another team in an organization are going to collide, start unnecessarily exchanging content, or creating some sort of security issues that move between them. That’s something that’s built out of a poorly-built platform. That’s not an inherent problem of platforms. It’s typically something people run into in their first foray into building these common tools and they’re typically scared off because of that original experience. Unfortunately, there are some technical issues that need to be worked out to put everyone’s minds at ease. But, it’s key to understand that that’s not a platform issue. That was simply an implementation issue that happened sometime in the past, most likely.
Lastly, it’s that autonomy issue that I mentioned earlier. Under the normal landscape without a platform, people are used to being able to add a feature whenever they wanted. They make whatever change they need just whenever the business need arises. But, moving to a platform, you’re often faced with working with unfair development release cycles and their particular work flow of how they build-out the platform itself.
This is a hard balancing act to follow, helping people understand that it may take you another week or two to get that feature that you want in, but because so many more people are using it, it can fit a lot more different use cases, it overall saves the organization money, and even more so, you can allow it to be, it’s tested on so many different platforms, so many different sites, that it’s a more stable product in the end.
Here are some of the direct tradeoffs you run into. You have lower maintenance costs because there are less separate developers working on the project, and there’re less bugs to fix over and over. That’s compared to less flexibility. That’s always the give and take there.
You’re getting shared features updates, but it’s usually on a fixed timeframe. Like I said, if you have a week or two that are really mission-critical, sometimes that just has to fall into the release cycle of the platform itself to make the whole system work efficiently.
Having less internal resources is so important now. With so many people who are somewhat understaffed technically, if you have fewer resources, you can consolidate those and build a bigger single product, then you essentially have the same number of users, but less developers behind it, which makes everything work. There are less contact people, there’s more collaboration and overall, having those fewer resources that are more specialized helps make everything run better.
Of course, what everyone always asks at the end of one of these sorts of presentations out in front of clients is, “What’s in it for me?” With all these drawbacks and all these tradeoffs, what is it really going to take for me to understand why this is the right way to go?
The biggest thing is sharing resources with the web. The way the web traffic works in this case is that most sites don’t experience the same sort of traffic over and over. If you have a shared, especially hosting platform in this case, you can take those ebbs and flows and average them out across all the sites and experience a lot of cost savings without having unnecessary servers and unnecessary resources being tied up by sites that just aren’t used parts of the year or parts of the month.
It helps to normalize that and this is one of the fundamental balancing acts that have made the Cloud so popular as a generic hosting platform. There’s less total lines of code, so to speak, to maintain. So, with that development effort, there’s one platform maybe one or two platforms, its one code base that has to be looked after. It’s easier to on-board new people. It’s easier to run testing’s for that. It’s easier to make the overall development process much lighter and less risk prone.
Also, the documentation. I think one of the biggest problems web projects have, is because the turnover for web projects is so quick, there’s a new product, or a new re-design, or a new team that spins up. Web projects don’t specifically last very long. If you need the time to document a product, it usually doesn’t happen for these short-term developments. But, if you build out a platform that can evolve over time and create new features and has the fundamental work around it to make everyone’s use case better, or work correctly, documentation can be written once for this platform, written well, and then the whole system becomes easier to manage, even by brand new people or contractors coming and trying to help out.
So, what does this have to do with Drupal? First of all, installation profile’s a great tool to use with Drupal. What these basically are, pre-defined configurations that include all the building blocks of the Drupal site stuck together so that people can ramp up quickly for their new site. You can look at this example from Drupal Gardens where if, whether it’s self-service or not, allowing people to quickly spin up an internet site versus a marketing microsite.
There may be most of the same code underneath, but an installation profile gives them sort of a quick start in one direction or another, so then they have the sample concept they need, they have the layouts they need, and it just becomes an exercise in filling in the concept. Installation profiles allow this sort of single-platform idea to be more flexible and make a lot more use cases work and bring in more of those naysayers in to the platform by showing them you can address their exact needs.
It also, one of the benefits, especially in Drupal 7 and moving forward, is because these installation profiles work like a normal Drupal model, I’m not sure this is the right place to go too far on the technical side, but, because it works like a normal module, it can actually do updates over time. This is not something where it’s asked for a blog site to get the installation from today, and then you have no control over it keeping up-to-date later. It’s actually a living piece of code that’s always on their site. If you add a new feature to the blog profile, for instance, everyone gets that. Everyone can benefit on and on and you don’t really have to go back and constantly be bringing sites up to date. It’s a very nice, smooth, automatic process.
Let’s go back a little bit to our example of a higher-ed body. In this case, before we looked at all these different colleges and they all have their different features, if you start looking at it in terms of Drupal and features and what features are required and understanding that not every use case really is completely different, you can start categorizing these into these different profiles. Maybe a few of these colleges are internal sites, so internet sites. Document management, Wickes, maybe, more messaging capabilities, those are the types of things that internet, internal site would have, rather than a multi-media site, for instance, that would be going externally and need to handle lots of videos and asset-management tools. You can fit all these different use cases and you can even combine them. If it’s an internal site that needs multi-media, you have both of those sets of codes. All it is is the matter of putting the two of those together.
The App Standard, the Open App Standard is something that’s happened relatively recently, I guess sometime very early this year. The idea is to take a feature which is essentially a Drupal module of configuration, you could think of it like a subset of an installation profile, and the app standard allows these to essentially be distributed.
If you think of the app store in an IOS or Android sense in other markets, the idea is everyone has a common platform on their device. They can go to one central place and start pulling down new features as they need them. The app standard allows people to have some autonomy as they need it, but because they are all connecting back to the same place, you have a really smooth, consistent way to make sure that all those features that all those different people are using can be taken advantage of.
What makes apps different for platforms? I have to be honest. When the app standard first came out, I didn’t get what the benefit was beyond other Drupal’s that already exist. But, if you actually think of it in terms of platforms, it’s a tremendously powerful idea. If you think of how Drupal modules work or how apps in a single platform work, you can make mixtures of it to make things more generic or less generic, based on how tightly controlled that platform is or how distributive it is.
It’s essentially as if you’re going out to an online store, finding a feature you want, and just simply pulling it down to your site. All this is done through the Drupal interface, so it can even be handed off to non-developers to really kind of build their own site, even though you have control over the code itself. It’s also what I’m calling a Voluntary Distribution Model. I like terms like that. (laughs)
What that’s really saying, these new features, if I come out with a new feature tomorrow, you’re in no way bound to going to get that feature. Right? It’s kind of an opt-in model where someone could actually look at it and say, “That’s a great new feature. I want that on my site.” But, the site next to it, the very next site that’s built, maybe they don’t care so much about that. It gives that kind of flexibility that the platform more of an eco-system of all these different sites working together, more so than you’re thinking about it in terms of one site.
This is a slight departure from what you think of as a shared platform, but because you’re sharing all these features and you’re sharing the communication and that innovative approach, you’re really getting all the same perks. It’s just two really different use cases, two different business cases that need to be met.
Let’s go back to our higher-ed model again. If we look at the University of Drupal, we can look at how user’s log in. A single sign-on the cross means our university. An app is something great that someone could just connect out into, pull down the single sign-on app, and now they have all the LDAP or CAS or site-minder, whatever single sign-on solution you are using, they now have all of that configuration locally and you know it’s the same for everyone.
It’s a great new tool to make those new features available regardless of necessarily where people started with the project. So, why create a new search? If you have an Enterprise-wide search solution, it’s not something you really want to write up in a documentation page and send out and hope people do, by creating features or a common platform or apps to do this, it becomes a point-and-click type of interface of making sure they’ve turned on Enterprise Search and that’s essentially the only set-up they need. It’s tremendously powerful to allow someone other than developers to have that sort of ability to create new sites and move things forward.
I want to come back to how Acquia fits into all these models. We talked about platforms and a couple of different contexts initially. But, as we talk about Drupal, it’s platforms that allow Drupal to succeed. What Acquia does, we provide two separate levels of products, essentially, which hit different needs of different people’s platforms.
We’ll start with Acquia Cloud. It is a fully-managed platform from the end structure down. What this means is if you need custom modules or custom functionality that’s specific to your organization, we give you the power and ability to do that without having to worry about how to tune things for performance or where to go for help. Acquia Cloud provides all of that from the level down, and whatever features you guys need you can throw on top and the two will work together to build out that platform however you need it to.
Managed Cloud is one component of Acquia Cloud. Managed Cloud is about pulling in these large sites you have or large number of sites and maintaining them all through one hosting platform. It’s taking that Drupal side of the platform and centralizing it even more. Rather than just sharing code, now you’re sharing the same resource model, the same support, and, again, everyone can benefit from these singular bug fixes or isolate features that get created an all in one safe, stable hosting platform that Drupal simply sits on top of.
Enterprise Drupal Gardens is more the software of the service solution. In this model, it’s all about allowing people have a fully UI-driven experience to building a Drupal site. There’s no code to maintain, there’s no specific servers to manage or any high-level sites to manage.
It’s an area where you can log in, enable whatever features you need, and then create content and move on. It’s the fastest way to ramp up to a content-driven platform. Rather than giving the flexibility to implement your own code, what Enterprise Gardens does, is it allows you to rely on us as Acquia to develop and create new features that are fully supported.
Rather than relying just on the community modules and how those are all configured together, Enterprise Drupal Gardens supports everything from the content all the way down to the servers. This model fits really well, especially if you think of micro sites or sites that are really design-focused rather than functionality-focused. It gives the ability to duplicate sites and create lots of sites very quickly and puts that into the power of marketing teams or communication teams without even involving the development or back office teams. Like I said, it’s the easiest way to ramp up to Drupal sites that are more content-design focused.
A couple of other key points here, and personally, myself as being an Open Source guy for a long time now, is having something like vendor lock-in. In something like Drupal Gardens, if certain sites outgrow this set functionality, it isn’t a case of having to rebuild that internally. You can actually pull that off of Drupal Gardens, move that straight on to Managed Cloud, add that additional functionality you need, and you still have one resource that’s still providing all of that functionality.
So, you’re not locked-in to Drupal Gardens. In reality, it’s just Drupal, so you’re gaining all the benefits that you already knew about when you chose Drupal initially and Drupal Gardens is really just a layer on top of that. It isn’t, it’s no sort of black box functionality that allows you to grow as your site grows rather than having to pick the full solution of tools that you need when you don’t know what that growth pattern’s going to look like. We allow you to grow and evolve as your site needs to in different capacities based on what your current needs are and where you’re trying to take your organization.
I want to leave a lot of time open for question because, usually for platforms there’s a lot deeper questions we want to move into. If anybody has any questions, please feel free to throw them in the Q&A section and we’ll address as many of them as we can.
Hannah: We had two of them come in. The first one is to install Profile Works for or with Commons.
Erik: Commons itself is an installation profile. I don’t know if you’re referring to Drupal 6 or Drupal 7, but I actually did a lot of the initial work with Drupal 7 with Commons and it’s really great. I’m trying to be objective. But, Commons itself is an installation profile, so you can build off of essentially the code Commons relies on. Because these are living, breathing profiles, you can sort of learn from them and use them all together. So, it’s not that installation profiles work with Commons, but Commons itself is one. You can either use Commons as is, or add to that with your own additional pieces of that profile and sort of layer that on top of Commons as your own rendition of it or your own breed of Commons.
Hannah: Does anybody have any more questions? Please ask them in the Q&A tab now. What is the best way to find developers who work with non-profits?
Erik: I think one, this is a larger question, obviously. I’ll give my perspective on it. One really interesting thing about the Drupal community is so much of it’s been built out of non-profits or out of that background. So many Drupal developers are looking for that next big push or that next big challenge more so than the specific kind of job. Just like with any sort of Drupal hiring, the best way to try and find those resources is to work within the community itself. Even as a business person, or recruiter, or, I obviously don’t know your background, working within the community itself. Attending meet-ups. Explaining the types of problems you’re trying to solve. Get people interested in what greater issues you’re trying to find a resolutions to, whether it’s camps, or local meet-ups, or group-a-thons. In my experience, that’s been the best way to get people on board and building out these kinds of big platforms is a really interesting exercise and typically attracts a lot of people. It’s just a matter of getting that word out there and getting it in front of the right people. The community is a great place to bring up those interesting scenarios and get some buy-in from external folks.
Hannah: We had another question come in. I’m looking at Commons 3 when it releases and Commerce Quick Start, too. How can you combine two different profiles?
Erik: Combining two different profiles is kind of a difficult combination to do. When I say that I mean in a normal, simplified way. Because the profiles are actually working together, you can basically create another layer on top of it, similar to the previous questions with Commons and pull the two in together. The only problem you’ll run into, to be honest I don’t know how large a problem this would be, you may have conflicts between how the two profiles are built because most installation profiles like Commons or Commerce are built to be single purpose, stand-alone sites. In this case, I would say it’s less of a sort of a process issue and more of what types of assumptions are those two profiles using that may conflict with one another? With e-Commerce and the event-based model that Commons 3 is moving towards, to be honest I think this is a place where you may actually have a platform below either of those that’s creating whatever shared functionality you need, and a lot of the time e-Commerce requirements and community site requirements are often different enough that the maintenance of these types of sites is easier separately built on top of a common platform beneath it all. I hope that’s not too much of a non-answer, but I would say the biggest thing is to make sure that you’re putting the two together to complement one another. Figure out what those maybe incompatible assumptions are. Then you can move forward with technical decisions on what you actually need from both.
Hannah: We had a technical question come in. What is your preferred method of including default content in an installation profile? Is it a Deploy module, default content module, custom code, and quick install?
Erik: I’ll actually say there are two different scenarios here. One is, or I should say the two scenarios are based on who’s maintaining that default content? If it’s just basic stub content where there’s really no meaning to it, then I think putting it in the profile itself is really the simplest, most straightforward way to do it. However, if that default content is more of boilerplate content or something that content, content managers are building rather than developers, I would actually say something like feeds would be a better option. The reason, it’s similar, I guess while you’re asking about Deploy, the main fundamental difference with Deploy, it needs to know all the different sites to send it to. So, as you roll out new sites, you have to go back to that base content depositer and keep adding new sites. Whereas, something like feeds, you would just have an open XML feed or some sort of feed to pull from and every time you install a new site it could just reach back to that URL and bring it into the site. I would say it depends on who’s maintaining the content is really the big difference here, in my opinion, of which technical solution makes sense.
Hannah: The next question is, in your experience, what is best theorem for membership management?
Erik: Unfortunately, I have to say I don’t have a lot of hands-on experience with a lot of CRN systems as part of this. I wish I could give an answer there, but, unfortunately, I’d be speaking on second-hand knowledge.
Hannah: There has, two more questions came in. If you want to have a community with fee-based activities events, is that practical for Commons?
Erik: Yes, absolutely. The main, I guess the Commerce Quick Start versus Commons issue that I was referring to was Commerce Quick Start is so much more than just adding individual feeds to sites. It’s so much more than that. If I were going that, the way I would look at it is Spin Up, Commerce Quick Start, and learn what of that you’ll need. And then there’s some integration you’ll need with events. There are various events modules out there that allow you to do basic payments. One thing that you and I, maybe what would be interesting to you is you look at the COD distribution, so this is their Conference Organizing Distribution, this is what all the Drupal Con Sites and most of the Drupal Camp Sites work off of, those actually have really specific use cases for buying access to individual trainings. In those cases it’s actually simpler than Commerce, where the Commerce Quick Start and the whole Commerce Suite really go for full-service e-Commerce sites. Now I pay for registration-type sites, so I would say, to sum it up, I would say Commons is probably your right starting point if there are lots of community events. And then I would learn from, I think even COD may be a better place to start. Learn what they use to accept payments and add-up pricing, because, as far as I understand in use cases, Commerce Quick Start may be a bit too much that particular case.
Hannah: I think that’s it for questions. If anybody has any additional questions, please ask them now. All right, I think that’s it. Erik, do you want to end with anything?
Erik: No. I want to thank everyone for attending and want to reiterate kind of the higher-ed background I have in working with these sorts of platforms. I really want to emphasize the innovation part of it. It’s not just about business processes, but if you get 10 people in a room with the same tool, they’ll all use it differently and everyone will learn from that. So, I just want to put that out there that platforms can actually foster innovation more than just thinking about it as a process or efficiency tool.
Hannah: Thank you so much, Eric. And thank you, everyone, for attending. Again, the Webex has been recording the webinar and we’ll post it to Acquia.com in the next 48 hours. Thanks.