 Hey, everyone. Let's get started. My name is Brian House. I'm Vice President of Product Marketing at Aquia. And I want to welcome and thank you all for coming to the session today. We've got a really, really very good session. It's my distinct pleasure to have Mike Lamb from Pfizer here. Mike runs their Director of Technology for their digital marketing platform. And so Mike's going to come in here and share a little bit of Pfizer's story about how they used Drupal to build a digital marketing platform to power all of their consumer brands. And so I've been working with Mike for the last few years. As long as a large team at Aquia had helped them think about the role Drupal could play at Pfizer, how it competes versus some of the other technologies they had in place and some of the other technologies they were considering, and then why they ultimately selected Pfizer. And Mike's got some great slides to walk through that process and then how they use it. One of the questions that we get all the time from organizations that just had the conversation this morning is, help me understand other people's successes. My peers in my industry, in my title, that are trying to meet similar business objectives. And so an important piece of what we do at Aquia is to share those case studies. Sometimes those are Aquia customers like in a case with Pfizer. Sometimes they're not. But I think spreading the word about Drupal, there's a lot of great technical pieces of the story. But there's also a lot of great business successes and also the results and sort of where you get from that. And so this is, you know, a big piece of what we do and we love when we have customers like Mike who are willing to do that and to share their story so that way you can learn and think about how to sell this in your clients or inside your own organization, how to do greater investment in Drupal. So what we're going to do is Mike's going to walk through some slides and we're going to sit down and have a Q&A. So I'm going to ask a couple questions and then I'd really love for you guys to ask questions and participate in here. So we've got microphones, there's a mic in the middle of the room. So I know it's always hard to be the first person to ask a question. So we have lots of plants so we'll get over that now. So don't be shy and then once we usually get one or two then the questions start to roll. So we'll get you guys involved as well. So certainly be active and listening and think of some good questions for Mike. So without further ado, I'm going to introduce Mike Lam. Thanks guys. So it's really exciting to be sharing what we're doing with with Drupal at Pfizer but I have to intro with my first slide from my legal department. This is the first time we're actually publicly sharing anything or officially sharing anything about what we're doing with Drupal and as much as that's a that's a very exciting time for us it comes with some conditions. So I'll let you read that as I pass that. So Pfizer have been using Drupal for a while now actually so we started with Drupal 4.7 and we started with that with a with a few internal sites. So a few intranet sites like knowledge sharing sites that we built using using Drupal 4.7. That really got us very excited in in in this technology in this area and we really started closely watching the project to that point. We evaluated Drupal 6 a number of times for external facing external facing projects but many of those projects were very large and we were hoping they would turn into a global platform off the back of those first projects. We didn't we didn't feel like Drupal 6 was quite there yet so we hadn't we hadn't selected that but the moment Drupal 7 came out it really the timing really worked very well for us with one of our global business units our consumer health business unit who make Advil, Anadin, Centrum, Robert Tusk and Chapstick etc. They were doing a global assessment. They really wanted to put a put a new content management system in place for all the consumer facing facing brands. So that happened in Q1 2011 and Drupal 7 was selected as a global technology at that point. So this was the first time we we really got we got serious about implementing Drupal. It was a very exciting time. So I was I was running the project to implement Drupal 7 and I was about six to eight weeks into that project and there was a larger larger assessment assessment underway. So consumer represents about five or six percent of Pfizer's revenue which doesn't sound a lot but that's a multi-billion dollar company. So that was a it was a it was a large large company within supporting the Drupal. The second assessment was for the Biopharm of Biopharm of business so really like 90 percent of Pfizer's Pfizer's revenue the lion share of Pfizer were doing an equal assessment say which which content management system should we use. So with only only six or so weeks experience with with Drupal 7 and implementing this within consumer we fought to get Drupal 7 on the list of projects to be evaluated and we went through that whole evaluation process actually together with Acquia with Brian and team and then a year later in Q1 2012 at the very beginning of Q1 actually we selected Drupal and Acquia to be our global platform for all of all of commercial Pfizer. So this is really every market all of all of our commercial products there digital offerings would be delivered using Drupal. Now consider that the real real beginning of large-scale Drupal at Pfizer so we're only about 18 months in so it's really this still is kind of chapter one of our Drupal story and we're very excited about what's to come. The case for why we wanted to do this was was actually pretty clear I mean the requirements from brand teams everyone's everyone's very familiar with I mean the expectation on on any digital delivery organization is continuing to rise we have to build sites with more capabilities more features they have to be mobile there's more and more we have to build there's no room especially in a regulated industry to even get you just can't compromise on quality these these more complex properties have to be the highest quality they possibly can be a wider audience you're typically publishing these two especially when we're some of our consumer products have been advertised with competitions and things on social networks at the same time you know this is a given you've got to deliver all of this but you got to deliver it faster and you got to deliver it cheaper so this was really the case for implementing some of these global platforms and implementing a platform this size while doing all these things is certainly a challenge to be addressed the the environment in which we operate isn't isn't simple so at the most basic level I consider to consider Pfizer was to be our regions made up of our individual markets and then our business units with our individual products and then at the intersection of each one of these we typically have a demanding brand team who whose job it is to promote a particular product in their market and at the intersection you can actually have many dozens of web properties you know what we we market to healthcare professionals to patients we have disease awareness sites we have sites with medical content we have sites with promotional content have to be separated you have sites for for events you have many many different properties in each in each one of these these intersections there are also lots of integrations with third parties accession needs to happen it's even in one of these boxes it can be very very challenging and the default behavior is to for that brand team to go and engage a company and implement snowflake solution I call it in each one of those in each one of those markets you have little little pockets of consistency if you're lucky but really there's snowflake solutions on a market by market basis there's there is some merit to this solution it's you know it's horrifically expensive of course and it's it's not at all efficient but those requirements are talking about in terms of quality you know integrations etc they're not simple requirements typically so you do get to market with with the individual brands timeline with their individual requirements but you know everybody here knows this this isn't going to this isn't going to make sense on a large scale and this is this is still the simple version of the picture that's a 50 by 50 grid of these intersections and then 18 months of Pfizer we've already implemented implemented Drupal in 46 markets across 86 sorry 84 different products so that's 18 months in and there are lots of boxes they're still to be filled and it's a very very big grid it can be very complicated very quickly so if you want to build a global platform a single global platform on a core set of technologies to meet this requirement it has to be very very flexible you have to understand what needs to happen in each one of these and the platform has to be very flexible so we know we selected Drupal but very quickly how we got to got to selecting Drupal I mean I don't think our process was too different to what I've seen in other organizations but really what it boiled down to was evaluating the different technologies with our critical use cases understanding what the differentiators were between these technologies and in a lot of time there were proprietary solutions that we were comparing to open source so really understanding those two environments and how they work and then coming down to the list of pros and cons like we we really need to understand if you were to implement solution X versus solution Y in Pfizer what are the real pros and cons that we're going to see for implementing these so I said it's about six or eight weeks ahead with that previous selection so that by the time we we got through this this evaluation we were learning more and more about Drupal so as much as we came out the evaluation selecting Drupal which was great we came out of that selection really knowing what we had to tackle to implement Drupal on a global scale at Pfizer so we found three or we listed three key challenges that we wanted to address as part of our implementation and for each one of these challenges our objective was to put in a short-term solution so this was this was a solution that the Pfizer would invest in a point solution us putting our finger in the dam to say we are going to fix this we're gonna we're gonna solve this challenge so we can continue with our global implementation and then we're gonna put in a long-term solution or typically that long-term solution is a greater investment where we want to be working with groups like LSD or the community to to plan for a long-term solution for implementing these kind of technologies at Pfizer so the first challenge was enterprise deployment I mean this isn't a new topic for for many people but it was it it was a real challenge for us and when it the the the key challenge around this this Pfizer was it's a regulated industry and the thought of editing on production or editing content on production it's just it's just a non-starter your content will not go near a production environment until it's absolutely perfect and ready to be published so we we had to put in a short-term solution or an immediate solution to solve for this so we put in a continuous integration environment based on Jenkins for various reasons but then we put in some scripts to move an application from staging to production to to to allow for this this process we also put in some guidelines so our various vendor partners could build applications that would work in this this way and that's what very well I mean this has been in place for about 18 months now it's been been very successful long-term we're investing in in a collection of tools called WF tools so to handle our entire continuous integration and workflow workflow requirements there's actually a Pfizer session tomorrow to talk more about WF tools and and what what that really is and the combination of WF tools with seven then ultimately WF tools which were really planning and implementing now to complement Drupal aid we feel that this this challenge just disappears off the radar for Drupal we're very excited about what comes as these things naturally progress the second one was the content editors experience so personally I feel that Drupal gets a bit of unfair bad press about the content editors experience lots of people talk about it but we've implemented a lot of systems that are a lot worse a lot worse in this area so the key challenge for content editing a Pfizer was not just editing the content you know and having inline editing or a WYSIWYG editor it was the person who was editing the content ultimately had to run a Jenkins script in order to get on to production so it wasn't something that a business user was really going to be doing so to start off with we have a highly trained centralized content entry team so that we can manage this on on many many sites on a large scale long-term we're very excited about Spark and what's coming with that project and Spark combined with with with WF tools and and Drupal aid again you really feel like this this disappears off of the map content editors will be able to be able to edit their content and then publish it in in our very complex work within our very complex workflow requirements without any real challenges the third and final one is around Drupal resourcing so in this in our first experience implementing for consumer where again we had to implement hundreds of sites we very quickly realized to implement hundreds of websites on Drupal you don't need hundreds of PHP developers you need dozens of Drupal lists and the the model in which large organizations typically are sourcing or were typically sourcing the technical skills store to work on these kind of projects through large systems integrators didn't immediately jive with Drupal particularly back then with at the you know the beginning of Drupal 7 I think it's constantly improving but it didn't it didn't quite work at that scale at that time so what we did to start off with we engaged with a number of dedicated Drupal shops so we we went and signed contracts and started working with a few Drupal shops and a lot of our Drupal demand has been met in that way longer term I mean the number of sites were deploying on Drupal's only ever increasing we hope to leverage our SaaS offering and our share more about that in a bit to help with our demand of the number of sites we have to launch but then also interested in engagements with with larger systems integrators as as as more and more large companies are investing more and more in Drupal really getting Drupal on the list of their key technologies as we know that these large companies have a lot of influence when it comes to getting getting people trained up on these technologies so there's there's certainly some potential for the long term there as well when it came to the advantage of implementing Drupal it was really interesting because anybody who really got to know Drupal or had attended a Drupal con or anybody technical they were very very passionate about Drupal so in these sessions they really they they wanted it to they wanted it to win they wanted to implement this technology but sometimes articulating that against a very big proprietary solution with a list of a thousand features is is a bit more difficult so this was my intent my attempt internally that I'll share with you of how I was trying to compare this to some of our previous implementations which were almost exclusively proprietary tools so we have lots of different projects of course with with lots of different sizes and complexity some of these projects are very very different and the typical model that we found was to go by a big proprietary solution this is the this is the proprietary solution your license that has a thousand features everything that you ask does this solution don't do this absolutely the answer is yes so we come and implement this solution excuse me and it does everything but it doesn't really do quite what we needed it to do in in my analogy it's that this is square peg and around helps them with me as I take you through this so the typical model is we get this big proprietary solution and then we customize it we work with one of our systems integrators we customize it which takes some time and costs us some money and we get a little bit closer but we do this over and over and over again to the point that we end up with something that didn't look like the original project that the product that we bought doesn't look like what we want to implement but we actually wanted to implement it's overengineered in some cases and then misses key requirements and this is a that's actually a very common pattern that I've seen in the past when we've implemented proprietary tools in this space and that circle changes shape as well as you're implementing these projects and get get quite challenging so we get to this point and we go speak to the person that you know sold us this sold us this toilet it doesn't quite work and they have a new version of this that does a thousand one thousand one hundred things at this point that didn't look like the original tool but we're still stranded on our island we can't we can't get to this we can't get to this new new upgrade and you see this pattern and I've seen platforms that have been implemented using this pattern and they don't they don't go past a dozen implementations you can't you can't scale this past a dozen implementation before you run out before you run out of money so you see pretty quickly it's not going to work and you don't end up with happy happy business users so the better way I consider really is what we're doing with Drupal as we have the very lightweight Drupal core and we put course Drupal core is a course across every single one of our sites unaltered we're not hacking core we're not touching this it's consistent across every single one of our sites on top of that we add in the Pfizer platforms this is the Pfizer platform of installation profiles you know standard modules that we we want to implement across every single one of our sites it's again consistent unhacked across every single one of our sites that really helps us to put that base of this platform in place then on top of that you have the magic contribution of Contrib and custom so between your own special source for each one of these sites if you like and through this combination we can meet any of these requirements and actually the size of the box if you actually looked at Contrib is huge but the magic is you really are only picking those individual pieces and you you're in good shape to be able to implement so this is this is kind of my internal Drupal story because you you're all very familiar with with Drupal but this is this is how I was trying to articulate internally why I felt this was so different and we were so passionate about this versus proprietary tools that we'd implemented before so talking a bit about our implementation specifically I say we're really 18 months in and we developed hundreds of websites or said differently what hundreds of business days in and we developed hundreds of websites that can be very challenging if you want to if you are really launching multiple websites per week then it can be very disruptive and we spoke about that at the beginning about getting to market as fast as you possibly can and reducing cost so we're not here in a position here where this solution so magical that you can build massive team to go and implement this and to be very very efficient and how you're doing it to use me so at Pfizer we have a massive massive scale of different different types of sites we plan to deploy we are deploying from that one page event site it's like a map of the event and the timing for the event all the way up to a multi-lingual portal that is deployed across many markets it's actually almost a thousand X difference in terms of the size of these projects and we have everything across the scale as well and we've implemented multiple of every single one of these and when implementing when planning to implement Drupal it was it was almost astounding to start off with the fact that we really felt like we had a platform that could deploy for every single one of these patterns that was impressive in itself but we realized that the model to deploy the largest site probably wouldn't be the most efficient model for deploying the smallest sites we have to we have to figure something out there so again this is this is how I was sharing this internally but to a brand manager building a website in one of those one of those little snowflakes there's a lot of things they've got to go and buy in order to deploy their their particular site of their site of their market and in this one-off scenario they have to they have to stretch their budget across this entire this entire spectrum they've got to hit every single one of these boxes to some degree they of course want to shift their investment as far up the scale as they possibly can they want to be be developing things that really differentiate Pfizer they want to be delivering great content and great promotion and great strategy around that they don't want to be talking about low balances and databases but in this in this one-off scenario you really are in a bit of a catch 22 situation if you don't balance this out and you end up spending all your money on promotion no money on having a low balanced environment or something that can scale your campaign is not going to be successful so the idea with the Drupal platform is we have two flavors of this platform we have what we call internally our custom platform or our past platform where we as the core team we we define the infrastructure that you have we make sure that meets a global requirement set which isn't isn't simple but we make sure that that that does meet meet a global requirement set the platform again of terms aren't quite quite what we're implementing but the core and the platform is again consistent across every single one of our sites and then when it comes to the features that have been implemented there's a library you can choose from so you can go and go and of course pick something from Contrib or you can pick something that Pfizer previously developed and then then implement that this model pushes your investment far up further up the scale it's far more efficient and it has almost unlimited flexibility this we've developed lots of different types of sites on this platform and it really does have almost unlimited flexibility but not every site needs unlimited flexibility that that first site that was just a branded site with a map of the event and some some steps of complexity on further than that didn't need unlimited complexity sorry unlimited flexibility so we have a second platform we put in place our SAS platform which is the gardens where the the core the core platform underneath this is identical you know same versions of Drupal core the same Pfizer standard modules were deploying to every single one of these sites but on top of that we locked down the features that are available to each one of these these marketing teams when you're deploying hundreds of sites you very quickly recognize a lot of lot of consistency between them you see key features that are on many many of these sites and if you can pick those out and get as many of those into your core SAS platform as you can do then if this this method of creating the many of these sites becomes becomes such more more easier so this really pushes the investment all the way up the scale so the pattern we see here when a brand manager wants to deploy a site is rather than coming in and starting with a basic Baltic site and building up from there they come in and they see a site that's been been deployed already to another market it really meets their need they take that site they take the content they adapt it for their market they localize it for their comp for them for their market and they deploy it and if you can get into a model we have enough enough of your core features in this kind of platform that many of your sites can be deployed in that in that way then launching multiple sites per week gets per week gets a lot easier if the core or the technical build of the project that comes in on Tuesday can be done by Friday then the following projects that you're bringing in can get a get a lot easier it can be it can be can be scalable without having thousands of people behind this so in terms of we talked about this this the standard expectations around capability so one installation of Drupal no so this these are all separate sites but they're on one instance of Drupal it's using it's using cloud site battery aqua cloud site battery so it's one installation one code base of Drupal so our features are consistent across consistent across these hundreds of sites but they are individual sites so the key reason for that is I find when we're implementing implementing a particular site in multiple markets it's easy to think that the process of taking this one campaign to multiple sites is just translation but localizing content for multiple sites with different regulation regulations different different environments can be very challenging so we we find by having multiple sites it strikes the right balance for for our industry to have consistency but at the same time have flexibility for each one of the marketing teams and that there are there are you know very different regulatory environments in each one these markets were deployed to so it's often more complicated than trans you know translating content or showing slightly different things on a domain access model right so we said you know the core platform what you're expected to do responsive design integration with with various other systems is standard it's there it's expected but we've got to get into a situation where we we we get to market ever much faster and the cost for doing this is reduced so clearly this is this picture works in this way you know the one-off model is very expensive and it takes a very long time that's almost like the proprietary model the first time round but then the past model is ever so much faster and cheaper and this this met a lot of this was this was met a lot of expectations internally until you get to the point where you really need to scale and when you really need to scale you get into a situation very easily or using this this strategy we can deliver sites in days you know in days in our kind of industry and deliver the matter so much cheaper so just some key lessons we've learned as we've worked along worked through this over the last 18 months must say it's still early days but focus on the right things when you when you are getting multiple requests in per week you've got to be focusing on the right ones so so partner partner for the commodities so at this scale we're not really in the luxury of saying or hoping that things aren't gonna break at some point it's more being smart about figuring what's gonna what's about what's gonna break next and making sure that there is a team that's capable of fixing that ready at the side to go and go and take care of that when it ultimately happens so if you can take large parts of your infrastructure and let someone else deal with that for you then you're gonna be in a much better situation so as much of those lower components we have we have we have partners to deal with that for us take the software as a service approach as many of the sites as possible this is a an internal learning anyway but every site thinks that they are their own special snowflake from the beginning they think they have some custom requirement that's very special for them but in reality as long as you get into a situation where you can offer flexibility if it comes to it or if it's absolutely necessary and you have an alternative of I can deploy what you really need and I can deploy it very very cost effectively in a number of days and the remainder of your budget can be spent on promotion then you can have some realistic conversations about what is really gonna drive effectiveness of this of this campaign talking more to kind of like the domain access model model piece this is a big big learning from the from the beginning it's one line but it can be talked about for hours on end but I really like implementing the model of having application independence by default and then layering layering in the consistency that's necessary so for example on the SAS platform a consistent single installation of Drupal makes absolute sense that's that's very easy but on the custom platform you can very quickly get into scenarios where you deploy one capability to as we have them to like 40 plus markets and then market number 10 needs needs an enhancement and sometimes these enhancements in Drupal can be complicated sometimes we've had enhancements that need new modules that need latest versions of PHP and if we get into a situation where in order to get that market to meet its objective I need to go and either engage with or regression test another 50 markets then I'm not in a I'm not in a very flexible situation so application independence independence by default and then choose your level of consistency you want to layer on top of that build a team of Drupal rock stars if you have the luxury of doing this absolutely do this especially if you're you're operating at scale so there are there are 10 ways to do anything in Drupal of course you're going to do that anything multiple times so pick the right way to do it and pick it or the right way for you to do it and do it consistently consistently in that way some projects especially if you're working with lots of different vendors won't go as perfectly as you might hope so be there to rescue those people there to guide them and they get into trouble to help them out develop a platform so the platform we mentioned have a team there to develop that have a team that understand what it means to make a change that's going to be deployed across many many sites and ensure that appropriate level of consistency finally implement your your core functionality and strategy and we kind of consider that our internal internal Drupal team they're the creators of our continuous integration environment our deployment environment etc etc but also our champions of things like BDD so if you want to push this platform forward but like behavioral driven development these are the guys that are leading to say this is the benefit so to implement this this on this scale it can help us put guidelines etc in place for how we actually get that implemented with with our with our vendor partners finally security of course it's a given that you have to be there's no compromise around security here and if you have a core team that's constantly watching your back or understanding what what issues could be faced or what issues you could come up with here then you're going to be in a better situation so other than the the questions which we're doing a moment just a plug for our session that we're doing tomorrow so some of the Pfizer guys at the back of the room tomorrow are presenting on WF tools a far more technical session on the the tools that we're implementing to manage our workflow environment for Drupal 7 and then Drupal 8 and beyond that's it for my slides so thanks Mike that was that was fantastic so at this point what we'll do is we'll I'm gonna have a couple questions that I'm gonna ask and then I encourage you as I mentioned before to think about the questions that you want to ask Mike and sort of how we can get the most out of this session given that you do have access to them here so certainly take advantage of it so so Mike one of the first questions I had was you mentioned that you guys were looking at Drupal early days and six and then seven came out but what you found was both consumer pharma and the bio pharma were doing CMS selection processes and sort of in parallel so what triggered the organization to start the CMS selection processes that ultimately resulted in the selection of Drupal sure so so really it was it started off from the capability side so we had a lot of these snowflake solutions and a lot of lot of cases brand teams were meeting their objectives through through their own agencies in their own implementations but there were some some limited platforms in place and we we quickly got to a point where some of these like what were originally considered edge cases like you know five years ago building a site to work on a mobile phone we didn't need to build platforms to do that became absolutely mandatory and as soon as those as soon as those pockets of consistency couldn't deliver on that then it opened kind of a can of worms of a lot of other things that those common platforms couldn't couldn't deliver and that led to the case of led to the case of were implementing things that are far more complex we need to take a better platform approach to this interesting I know you know one of the things you talked a lot about at the end was your ability now you've gotten to this place where you guys can deliver sites and days and I know a few years ago I think back to the conversations we had we talked a lot about how long it took to develop sites and some of the existing systems you had give us a little bit of a flavor of how how big a change this has been advisor and sort of what it took to build a website the old way yeah it's it's a massive it's a massive massive change so there's there's a lot of benefits to come out if I talk about the SAS approach so that's one extreme so that's the extreme where you can you can really have a website coming on Tuesday and if if there it can it can absolutely be built on front by Friday and in many cases it can be approved and ready to launch by Friday as well there's a lot that needed to happen in that SAS platform to make it make it necessary I mean there's so much consistent consistency on that platform that we are security testing this for example to the platform level so our security testing process that takes multiple weeks with multiple months of lead time happens on a platform level so if you're building this is a one off one by one site by default you have a multi multi month process to start off with we don't compromise on security so it means that even if even if that site came in on the Tuesday and put its requested on the Tuesday to to be security tested even in the best case and that was our highest priority site for Pfizer to launch still gonna be a couple of weeks before it can be out the door by default no matter how fast you can you can build it and there are a lot of processes around this that we've managed to optimize or and already perfect for a SAS type deployment using using using this kind of this kind of structure so you know a lot of what you do I believe is on the IT and through the technical side in your customer within Pfizer's business the product managers in market what's their awareness of Drupal do they know they're using Drupal I mean how what's your interaction with them from a technology perspective I didn't have this question but I do have just to give you a sorry I didn't know this question in advance but just to give you and I was talking about this yesterday to give someone an idea of the awareness of this in within Pfizer I was with one of my colleagues when we were when we're introducing Drupal to to a marketing team this was this was at the very beginning and we were introducing that Drupal to that marketing team and talking about a lot of the advantages of why we wanted to build this in Drupal and that we got to the end of the conversation they were convinced why we wanted to do this in Drupal but their response then came to why am I building in Drupal but not in Bangalore you guys came to us you guys came to us a few months ago and had this great outsourcing opportunity and you're building sites in Bangalore cheaper than you'd ever ever done it before so there's certainly been a learning curve we started off with just the requirements coming from the business and having to meet those requirements so I'd say a lot of the success of this platform has just been building credibility understanding and pushing the boundaries of what what the brand teams want to do and then delivering on that very very consistently interesting so you know you talked a lot about platform and obviously platforms are really important piece of your story you know you mentioned you have pass and sass and you work with Acquia as you think back to the selection process the fact that you had the flexibility in your deployment models and sort of these how important a role did that play in your selection ultimately of Drupal as compared to the other technologies you were looking at there there wasn't another technology that we were selecting that could deliver that full scale of the smallest sites the largest sites we knew in that selection that we we needed to tackle that full spectrum and we knew that that was going to be a critical critical to our success but the competitor to Drupal in that space was implementing multiple technologies so this was a major win for Drupal in the fact that we could choose one technology and it still astounds me the fact that we really have one technology when you see the complexity on one end versus the the the microsites that are built on the other end and it was it was only Drupal that could deliver that but further than that it was only it really made Drupal Drupal win from another benefit that we could actually invest in those in those SaaS components so the common features that are going to be deployed across the rest of our sites by not splitting this across two different technologies and having to implement every single one of those functionalities twice it really actually works we built sites in that SaaS platform that were built very fast maybe took a marketing opportunity that wouldn't have otherwise been addressed without without that platform but then have grown and then have required custom functionality and things that were one off of that particular site and using this model it's it's it's magical you can take it take it out put it into your past platform and then put in whatever layer of integration or functionality you might want on top of that as well so it was the only it was the only solution that really offered that yeah I know and that's a you know that's this be the only product pitch here I think that's a big piece of when we built our SaaS platform aqua cloud site factory that freedom and flexibility to move between one model right because you know I think the hard thing when we're talking to business people is sites are not the static thing okay it's launched now go to and go on to the next thing it becomes this entity that grows and evolves and changes and you you know being locked in in some cases is is worse now you're going to start over again I'm going to ask one more question then we'll I'll open it up to the audience what I will ask is is maybe if you can come to the microphone the session is being recorded and so that talking to the microphone in the room will be able to capture the questions for anyone who's listening or listens to this later so a lot of folks in here aren't organizations like Pfizer but they're actually service providers consulting digital agencies so what advice do you have for consulting firms for agencies in the room in terms of how they should think or approach working with a company like Pfizer in a large global multinational you know Fortune 100 company it's a good question I have to think a bit about the answer so we we work with when we're talking about that spectrum of different sites that we're launching the reason we're working with multiple vendor partners is we find that there are there each of the vendors have their sweet spot across that spectrum at some point you don't want to take the you want to be developing those smaller sites as efficiently as possible as fast as you possibly can that's typically a completely different skill set that we need at the other end of the scale what I'd say is we we've got to a situation where we're using that kind of internal team and also with Acquia where we're really understanding the quality of our Drupal Drupal solutions and we're really getting into a situation where we can that quality typically maps over to the value of that over time I mean reuse is a massive massive component of this so if you can if your organizations don't understand or aren't reusing components or aren't asking to build things in way that can be reused help them understand that story because it's something I haven't talked about here too much but it's it's a kind of a whole nother vector for this for how you can bring value to these kind of projects so not every every Drupal shop we approach thinks that way or vendor we approach thinks that way so if you do then or if you either do it by default or convince the organization you're working with why they should build these things then you're going to be bringing a ton of extra value to the projects that's great that's great so so love to take some questions from the audience so so someone be the first one John are you gonna do it all right thanks it's always the first one's always the hardest so you talked about how the brand managers have their own agencies and now there's you know you've got the SAS on site factory and you've got pass as well what's those agencies assume now have to have something to do with that they have to be integrated into that process when there's a new theme built for a new product or something like this they're building inside factory as well can you talk about that process and maybe how you got those agencies involved or whether that was to do that queer or who else sure so I'd start by making sure I'm clear about the term agency and what I'm doing with with the agency so I would separate that from the Drupal shops for example yeah I'm just not gonna bucket these two together I'd say our agencies and the partners were working there with their from the creative side particularly the ones that we're working with with a kind of content we're expecting them to produce building these sites is not in their core in their core case I believe you work with WPP and a couple of other work with a lot of a lot of agencies yeah and not Drupal's not their thing yeah Drupal's not their thing and if they do implement it they'll typically outsource it to a partner sometimes some of the partners we're using for Drupal development anyway but it's not really there it's not really their thing and because you work with a lot of different agencies and a lot of different markets the consistency has to really come from Pfizer so you have to get into a model where you change your relationship with with with those those agencies to a degree and you have the right selection for the right vendor for the build and you have have an appropriate not necessarily fully centralized but you have the appropriate model in place to be able to marry these things together so that you have the agency focused on what they're doing which is typically in that top like golden category and then you have a team that can can effectively understand that to be able to implement that in a case of technologies technology implementation besides that so you're marrying you know the marketing agency he's doing you know the PSTs or the first design with a Drupal agency who does the thing that kind of thing and then yeah and we manage that and we put in build kits and guidelines to help help manage that transition between them cool thanks John yes it's the mic from good you guys come from online when I'm closer and I have a question I can imagine that on your local markets there are some people who are reluctant to a standardized solution who think that they were far ahead of the crowd and it might even be further ahead of what you're providing now do you have any best practices on how getting these people on board so if they're further ahead let them be further ahead I mean we're not we're not trying to we're not trying to solve for every single possible use case and we listen very closely to our individual markets to help understand common trends of things that might want to be implemented but this implementing this platform has been I say it's a hundred percent carrot and zero percent stick we try and help out with with implementing these these services and that's been very very successful if it turns out that a marketing campaign an individual market considering all the extra process they have to go through to launch their site can still be more effective I don't believe that happens on a large scale but if it really is more effective let it run in that let it run in that way so there's a lot of what we're doing in terms of proving the value internally to this or showing the value to each of these individual teams but to be honest that's that's not largely been it's not really largely a challenge that we've had to address with this platform I would say I've spent the majority of my time at Pfizer on the other side where that has been a much larger challenge where there's a typically that proprietary implementation and you're one of the first and you're fighting against it thanks hi I have kind of two backgrounds I'm a jubile developer but on the other hand I'm also a pharmacist working at a small pharmaceutical company as a product manager and so I try to bring Drupal into our organization on an internet base as a product platform and what I think is for always for us the biggest challenges to somehow get our approval processes which differ from brand to brand from product from market to market to get this into Drupal so we often have the situation that we have a content creator we have a search engine optimization team we have the approval person we have the product manager we have many different people who differ from project to project and do you manage to get all this into your workflow tools so into Drupal so we we so when we're talking about our workflow within within within Drupal for for promoting content you talked to a lot of the challenges that we have you know you should talk think about that environment and you think at the other end of the scale directly editing something on production you can see why these things aren't going to jive and why these things aren't going to work together but on the other hand when implementing a platform on this scale we can't we have to have some like common integration points to some of these some of these processes so I'd say we've optimized and we built specific features or functionality into our platform to support these kind of approval processes but in many in many cases in many markets they're offline processes and so we built functionality to optimize those as much as we possibly can can do especially where it only gets more complicated around things like responsive design and translation and these kind of things we optimize to integrate with those processes but the objective of the digital platform isn't isn't to run those processes it's to integrate with with the existing processes in each of the markets okay so the approval process of times also completely outside of Drupal and somebody signs a document which is a legal document for example which needs for the registration or yeah exactly that so that process happens outside and we make sure that we're we're putting the workflow within in within Drupal to give you absolute confidence that the the thing that you're saying yes the publisher to production matches the PDF file you got in front of you and the thing that was legally legally signed off by compliance to be launched but do you still work then with revisions that if you have new content for example that the old content is saved in the Drupal platform yep so there's lots of advantages that come from that so we use those tools so of course we have revisions on on all content on all content types that were we have within our sites and that also helps when when that person sat there with the PDF file in front of them of this is what was signed off through that legal process then revisions of things can help help with that process by doing like a diff between what was there before and what's there now and am I comfortable that that diff is fully represented in this document and can be legally signed off to deploy I think there's more that can be done to optimize optimize that area and particularly as we're we're stretching the boundaries of some of the additional challenge you want to deploy to then that needs to be done done done faster but I would say we built enough into Drupal to really optimize that process versus versus doing it from scratch which is very very very good. Can I ask one last question? So as a Drupal developer I also work for political parties and also in our company I think they also want the approval process inside of Drupal they want this do you have tools inside your work for tools that you get excited by the WF tools sessions tomorrow I'm sure okay yeah come along to that what we built that or it's been built effectively as a framework to manage the very very different types of workflow needs in each one of our each one of our markets and the the requirement we're talking about here is is typically medical content of or promotional content related to a pharmaceutical product. We have a lot of different types of products or lots of different types of properties at the same time that might not be promotional might or might not contain medical content in which case probably some of the workflow types you might expect for your other other sites are more relevant and the idea of of the implementation with WF tools is to cover the spectrum to be flexible enough to cover the spectrum in some cases it will be the the the method of signing off content to go to production fully in case within that system in some cases it will be integrated with the the other processes to the point that we can we can optimize this as much as we can. Cool, you're doing more pitching than I am and you're the IT guy. As I said I spent most of my time outside of IT in the past. Mike, thank you for your presentation. It was really interesting. Specifically the platform information. Maria's channel blink reaction. I have a couple of questions. First one is when you work with this multiple design agencies do you have any guidelines for designing Drupal sites? The reason why I'm asking is we all know that we can implement any kind of design in Drupal but if the design is so-called like Drupal friendly or responsive design friendly and adaptive that makes a huge difference for the time frame. Right and it's a very good question. So I would say on a lot of our a lot of our more basic sites we don't if something comes up and it's clear that it's going to take a lot of time to implement it this way in Drupal versus we really believe that you could implement it this way particularly if you're building it on also on the SaaS platform. You know it's going to take us longer to build this particular widget in this way whereas blink of building some of those if you want to build it if you want to build it in the Drupal way it might be easier. So we have some discussion around that but I'd say that really comes up on some of our larger projects when you may be maybe building a web application on Drupal. It's easy to have an agency who are building a concept for a large application to build many many dozens of wireframes covering the full functionality and we even had a project recently where there were say we got into about a dozen wireframes covering functionality that was already delivered by Drupal so they're kind of redesigning or re-implementing this and on all of those larger projects it's a member of my team so that core that core engineering team that are running this platform that are engaged in each one of those projects so we try and catch those things early on enough to say you're consulting with those projects and and understand you know the that doesn't make sense to implement it quite that way within Drupal we can optimize this we can do this a lot faster if we do it do it this way. I say it's my team but it's really guys I have from Acquia doing that I take the credit for. Thank you and I have one more question in regards to the deployments due to the business requirements and approval process you mentioned that all content changes are done on staging environment and then after approval they are deployed to production how do you handle websites where you have user-generated content like five-star voting comments submissions form submissions and other it's a good question it's not it's not easy and there's the when I said that the short-term implementation was the script to move from stage into production that comes along with some guidelines that tells you in a lot of technical detail how this process works and there are a number of different ways you can preserve specific content on production while while running that stage into production process so I would say it's very far from perfect and it's a it's a good it's a good use case that's absolutely covered using using the WF implementation however a lot of a lot of the sites that we have user-generated content on production it's typically things like five-star voting or some comments or the more the things that are easier to solve for rather than the rather than sites where the majority of the content is is is starting from production effectively thank you so I have a quick question on something that I'm sort of deeply passionate about which is contribution I know that you have done multiple contributions to to the Drupal ecosystem and you have part of your your your platform is out out on the world and part of it is internal so it's sort of a two-part question one is how do you manage that your internal developers your contractors contributing and how do they know what they can contribute what they can't contribute and the second one is how do you measure sort of or can you measure some sort of ROI that is has this helped you like be better has the contribution helped you and how did you justify that internally to keep doing it good good set of questions right so contributing contributing back it's something that absolutely needs needs to happen in order for this to work long term be sustainable etc something that is without a doubt without a doubt has to happen but at the same time it's of course not it's not the easiest of things of things to do I would say we're really really getting started on what we're doing in this area now as it's early days enough that it's a certain enough days you know 18 months in that I'd say we we were learning a lot more from the community we weren't really getting things to the quality that we could really add a huge amount of value until until the last six months or so so in the last six months or so we've had we've had larger projects things like WF tools that would be very beneficial to many other companies to implement so when there are cases like this it's it's in it's an agreement to it's an agreement with the individual developers whether they're internal with a particular vendor to publish this this to Drupal.org or in some cases where it's not Drupal specifically to GitHub in a in an appropriate way so I would say that's it's largely just through close communication and expectation between my me and my team as to what is appropriate and what isn't appropriate but really it's it's it's only starting to come up in more detail now is there are some of these there's something's larger investments in that we're making to fix problems that haven't been been widely fixed in other areas I'd say internally the my management in particular really understand the value from doing this there's there's a lot of great cases that I can go when I go into more detail and more specifics about what we've implemented and how successful that's been that really that's the opportunity to kind of go and sell how we've managed to be so efficient writing off the back of what other people have been built have built and and and really the when you talk through the whole case of how we've been successful what we're building and how we want to contribute back it's quite an easy story it's quite easy to understand why you have to do that and for these larger in larger investments we're trying out something like WF tools where we want other we want other companies to be using that and I think I hope that will be my case study to go and take and say hey we built this it perfectly met our use case it made us even faster and even even more efficient on these platforms and these other companies have adopted it and as a result of that here is the here is the benefit we see from other people helping to maintain it so that will be my one first I remember being in one of the meetings we had in New York we sort of walked the rest of the Pfizer team through the views story and how you know views started out with a single company's investment you know it's become the most popular module and now is moving into Drupal aid and you know it's very easy to quantify I know Mike Myers does this in large-scale Drupal to say you might spend fifty thousand dollars but look two million dollars of investment has happened in this module you get to take advantage of that or you could do it yourself and that's an important story to tell I think it's an important piece of understanding the business model of open source and help to tell that hopefully you guys can hear me the one thing I will say and maybe you can talk on it real quickly is the role of programs like large-scale Drupal to you know contribute in ways that may not be code but also predict move the project forward as well yeah absolutely so so we're very also very excited about large-scale Drupal and that's where I see larger investments of things like the WF tools project we're doing really really living well and I'm really excited about and this is this is something we talk with with Mike about a lot but there is huge huge potential there for where the time scales and the investment from a number of companies are there to the point that we can we can really get into a model to collaboratively development on a few of these these areas because when you're collaboratively development developing in an environment like like the LSD the LSD group it's much easier to then go and publish this and particularly not just publish it but productize it to something that the other companies can really pick up adopt and use so that's really the right home for doing these kind of things and I hope we can do a lot more in that kind of environment as well fantastic thanks Brian you nicely articulated the the sort of the challenges of taking a proprietary system cutting the corners of making nice and round I guess the question is a couple of parts for me so we've got the migration to Drupal 8 trees touched upon this this morning it's not going to be easy you've clearly built up a significant platform you've then got custom contrived you're developing that out I can see how that works from a SAS perspective obviously from a pass sort of buy in what would you recommend to large scale organizations or agencies to mitigate the risk of going from 7 to 8 you're clearly going to be held up as an exemplar so I think you're probably a good case study to show us how we could be in a good place in maybe six to nine months time right so it's a topic of a lot of a lot of debate of course at the moment and I'm sharing Mike's opinion here really rather than I think it's really been been clearly planned within Pfizer at this point but along with the discussion around moving from Drupal 7 to Drupal 8 which we're very excited about and were largely very excited about it because I expect to be talking about this platform in a number of years and what we've continued to do with this platform rather than talking about the next technology that we picked up which is ultimately what can happen what's going to happen if we just continue on with 7 we pointed to some of those challenges with 7 that are not going to be fixed in 7 those long term solutions don't come in 7 so we're very realistic about where we are and I would say as much as you see many many sites moving to Drupal you know several per week I think we maybe would be doing more if it wasn't for the fact that we knew 8 was coming and wanting to make the appropriate investment there I think there's a lot of discussion as well around kind of caught up to my opinion of how I see us running this our own migration there's lots of discussion around making 8 backwards compatible with 7 so not just can 8 be backwards compatible with 7 but do a few large organizations want to get together and figure out a way to build some legacy module to make that happen I don't personally think that's that's something you should be pursued past that kind of sentence it's not you've got to you've got to move on and I think if you get into a structure as we have where we're very clear on what these key functionalities are when you've implemented them once and you know there's these 50 things that I've got to get ready for Drupal 8 then the the investment across an organization this size to actually get those things migrated across the Drupal 8 is nowhere near the scale of investment as say switching from Drupal to another technology so it has to be the story has to be very clear and has to be well articulated to meet the expectations from a Drupal 7 to Drupal 8 migration don't let anybody begin to think it's going to be a one button upgrade from from from from any angle but I think having a platform strategy and having a good case of the the value of these platforms in a good case for for where they're going to go will will help that so that's that's how I expect us to do this be very clear on what it will take for us to move to weight and I want us to be one of the companies leading leading the way I was to have one of the first first Drupal 8 sites so I'm involuntary to you so you're all set good thanks bro great well Mike thank you so much for sharing a lot of insight this is a fantastic session so give it up for Mike