 So welcome everyone, I hope you enjoy Dripplecon so far. This talk is a case study about SunCorp group and how we started on the Dripple journey a few years back. So hopefully you find it useful, have some takeaways for yourself. Myself, I'm Chong Vu, team leader for the new media team in SunCorp group. The new media team looks after our corporate websites. Basically it grew from a team of developers to now purely almost a group of developers who work on Dripple. So our main platform in SunCorp that serves our corporate sites is the Dripple platform. I started in SunCorp about four years ago but before that I was with another company that we merged. So I've been in the group for quite a long time, 18 years overall, but every four or five years there's a new company that comes in and take us over. So I didn't really have to move around too much, things were moving around me. I became a team leader in about two years ago. Prior to that I was a developer within the team. So I've worked quite a bit on Dripple itself but nowadays more managing than working on the technical aspects of Dripple. Feel free to ask any questions at any time you feel like. It's quite a fluid presentation so if you have any questions just raise your hand. A bit about SunCorp itself. SunCorp is a fairly large corporation. It's a conglomerate of smaller companies which we call now brands. They used to be companies. It has 16,000 plus employees and it's a top 25 AXX listed company. It's quite unique in the Australian market. It's really the only company we know that does banking, insurance, wealth and life. And it is the largest second-tier bank in Australia. Since the merge with Promenade, which you'll hear about in a minute, it was also one of the largest insurers in Australia. And some of the famous brands you can see there's AME, GAO, APR, Shannon's. Those brands are quite large and we have the majority of the market. So 2009 was special for a few reasons. That's the year that Michael Jackson passed away. One of the most popular pop artist history of music. Also Harry Potter and Ice Age was quite popular at the time as well. Barack Obama won the Nobel Peace Prize at the time. And the H1N1 swine flu was the pandemic for the year. And also it was the year of natural disasters. We couldn't forget the 2000 homes and 173 lives lost in Victoria in that year. But it was also a year, a Sun Corp transformation in corporate strategy. The transformation that happened was that Sun Corp started to adopt open source. So prior to that it was very vendor centric. So we had a lot of large vendors in the company themselves such as IBM and Microsoft. But with our CIO at the time, he had a vision that says the future is open source. And that's where we headed. Not just for Drupal but for other platforms as well like JBoss in the company. Another important transformation that Sun Corp went through was Agile. We adopted Agile methodology in that year. And we trained in that year 3,000 people in Sun Corp virtually in Agile. And that's in our business technology areas only. So it was a very important year. The other reason why it's important was that Drupal was introduced to Sun Corp. That was the first time we heard about Drupal. And with that union, these are some of the sites that we have now that runs on Drupal. It's a sample of some of our populous sites. We have 30 sites, 30 corporate sites. And we maintained and built all of these over the years. But why Drupal? Why was Drupal chosen ahead of countless other web content management systems out there? And to tell that story, I'll probably have to go back to a time before 2009. So Sun Corp Group, which we are now, was made up of two very large companies at the time. Sun Corp was primarily a bank. And prior to 2006, that was its major business. So if you were in Queensland, anyone in Queensland down here? Sun Corp is probably one of the largest employer in Queensland. Promenade, on the other hand, was more an insurance and wealth business. And Amy is probably its most famous brand. It's probably the gem in Promenade's suite of brands. And with the merger of the two, Sun Corp became really strong in those areas. With really strong brands and well-known brands. So during that period, about 2006, 2007, there was plenty of opportunities for the groups to get together, plenty of opportunities for changes to be made. But there was also a lot of uncertainty. And the reasoning for that was each of these companies were in their own right very large. So if you take each one of them out, they were companies in their own right. And they had their own systems, their own processes, their own cultures. And the challenge for us was to bring it all together and merge it so that we became one group, one team. But that took time, especially in the web systems. So these are some of the samples of the web systems that were available at the time, around 2006, 2007. There were really no content management systems that were suitable. These were all bespoke web systems. We had systems that were running on personal servers, systems that were outsourced to agencies. We had even systems running on laptops. And you can imagine if people run a website on a laptop, if they take this laptop home, the website will be down. So it wasn't an ideal situation. But like I said, companies, because some of them were quite small, they only make $100,000 a year. They can't afford to have large systems to run their platform. So they had to make do with whatever was there. And as a result, around that time, even though we knew that online was an important channel, it wasn't really profitable for SunCorp. Most of the sites were actually non-supportable. There was no system to actually produce content, create content, maintain content. It was created once and remained for quite a while. There was also high risk. There was no one really looking around to see whether the sites were hackable or not and what kind of security systems were put in place. And in fact, some of those sites were defaced and hacked and all of that. So it was quite dangerous. Also, a lot of these sites were made for search. So you cannot go in there and do a search and actually find a product that you want to buy unless you know where to go. So if you know SunCorp, or sorry, if you know a certain product that you need, you probably find it with the URL. You cannot actually search for it. So overall, it was expensive to actually maintain these sites for SunCorp during that these years. And the sites, although we were making money, weren't profitable because we put so much money into just maintaining them. So really, we needed a flexible content management system very, very quickly. Mainly because we saw our competitors who were moving quickly. A lot of the large committers out there had sites out there that were responding to the market trends. Online technology we saw was accelerating at a phenomenal pace. And mobile adoption thanks to the iPhone was coming into its own. Our businesses needed a system that they can update content independent of IT. So prior to this, a change, even just a small change, would have taken about five days because you cannot release on a weekly cycle. So a spelling mistake may last for five days, but it actually gets fixed. And that wasn't ideal for us. So what's true for our saviour at the time? Not quite yet because, as you can see there, we went through a very rigorous process of evaluating all the different content systems that were there. There were more than that, but these were the main ones that we focused on. And with the new corporate strategy of open source, we really focused on a lot of the open source, apart from one, which is the one on the left you see there, which is IBM WCM. And the reason for IBM WCM being in the mix was that there was still our major vendor in SunCorp at the time. And they had quite good offering because it was based on Java. SunCorp had a very big Java team, and using our core skills, actually we can do things very quickly with IBM WCM. But why wasn't it picked? It wasn't picked because when you look at their roadmap, the flexibility, the previous relationships with some of the work that we needed, it wasn't as flexible as something that was open source. So other open source system, that was .NET Nuke, based on a .NET platform, LifeRay based on Java, Joomla and WordPress, and obviously Drupal. The reason why we chose Drupal was not because it was better than any of the others, but adding up all the positives, outweighs a lot of the other systems that you saw there. And the biggest aspect of it was that when we were starting it, it was Drupal 6. Drupal 6 was the core Drupal version. Drupal 7 was just in the works, and Drupal 7 promised so much, especially for enterprise level features, things like deployments and all of that. But also we analyzed some of the roadmap that Drupal provided, and it looked probably the most promising that was out there. It was the most flexible, most scalable, and the community was very active and growing very quickly. So that made Drupal probably the highest ranking system that we chose. But the real reason why we chose Drupal was that our business, our managers gave us the support. So it was exactly like that. They asked what we wanted. We said Drupal was really good, and we wanted to use Drupal. And literally the manager said, yep, okay, go for it. But that wasn't it. That wasn't the crux of it. The crux of it was that once he said, okay, he actually supported us all the way through. Because if you're in a large enterprise, how many people he's in an enterprise in a large corporation? So not too many. But if you're in an enterprise, trying to get some of these fundamental changes through can be quite hard. The number of processes and the red tape you have to go through can be quite challenging unless you have that support. It's very important to have the support, especially if the higher up the better. And we did have that support. The business themselves didn't really care at the time what platform we chose, so long as it allowed them to publish quickly. That was their main primary concern. But we had a great support from our executive manager at the time. But Drupal wasn't very popular. Sorry, yep. Sorry. So we had him for about three months, literally. There was a lot of changes. And when he became our manager, he said we needed a content management system. So from that three month period to when we had something to present to him, it was just three months. But not everyone was convinced that Drupal was the right solution. Some of the main concerns were that we're in enterprise and we're using open source. Open source is not safe. I don't know if it's a myth or the kind of thinking that we have, but that was one of the concerns. The other concern was that we are the vendors. There's no vendor support. And at that time Acquia was around, but Acquia was still fairly small and in the United States. Not a lot of presence in Australia. And in Australia itself in 2009, I don't know if you remember, but there's a total lack of developers out there. You may be going to a meet up or a group or a forum and you might find people there. And that's where we ended up going. But looking at the market on seek or career or whatever, you cannot find a Drupal developer that you can hire. So those were the main concerns, but we alleviated a lot of that again with the support of our managers. Because we had the belief that we can achieve this basically. And with that support, we were able to get through a lot of these questions and overcome a lot of these questions because of the transformation that we were going through at the time. Had we were not in that transformation, it might have been a little bit harder to do that. We might have had to go with one of the vendor-specific systems. So I just want to make a quick observation. If you want to push Drupal into your corporation, do your research and have compelling reasons why you need it, but ensure that you have very, very strong support from your leaders for the journey. Either business leaders or your managers or anyone who has the power to make the decision basically. So now that we have chosen a platform and it's going to be Drupal, how do we go about building the team? So this is what we had when we started. There was no roadmap. There was no infrastructure. And our skills in Drupal were zero. Like, all we did during the... when we evaluated was that did a few proof-of-concept sites, brought it up on local machines, and that's all we had. But everything else was learning from scratch. What we had a lot was passionate people. And these people were the ones that enabled us to overcome our barriers. I did not have any skills or knowledge, but they had the willingness to actually learn. They had the willingness to just give it a go and just went out and try things. And with that, we were able to actually start. And how did we set up our team to do that? So basically, this was our start. So there was two streams. There was a platform stream and a development stream. And then some stakeholders. In the platform stream, keeping in mind that these people also had no idea how to set up a Drupal platform. What is it that we needed? But they had the, you know, the power to take the risks. Because again, we had that support. So Architect led the networks team, the middleware team, mid-range and database team. And later on, we brought on security, deployment and storage. And finally, once we have a platform, we can play with the BCP, which is the business continuity teams and also the access teams. In the development area, we had a tech lead leading our internal developers. There's only two of them and a Drupal consultant. I can see her standing at the back right there. But as mentioned before, we didn't have a lot of people we can call on to actually help us. But with the consultants and internal DevOps, which myself and one of my tech lead behind there at the moment, had a platform consultant. So we had two consultants in with the tech lead worked on the development space. Our business partners were kept informed, but like mentioned, they weren't really interested at that time. They just wanted to see the end product. We had to keep our legal, our risk, and our marketing and communication teams informed because they really want to make sure that what we deliver is not going to put some corporate risk. Again, reminding that it was open source and it was not something usual for an enterprise to do. So in three months, we literally worked day and night to actually have the platform ready. But in delivering the platform, it wasn't perfect. Had we tried to go for a perfect platform, I don't think we would have come out. So we didn't have continuous integration. We didn't have a testing platform there. We did not allow editors to edit on the live server, which a lot of Drupal sites, if you worked or built your own sites, actually allow you to do. But what we did have was a platform that we can host sites in multiple regions. And that was the minimum that we needed to launch. And that was the minimum that we had. We also have some practices that had anyone who's come and worked with us, and there's quite a few contractors who have worked with us. That weren't best practice, such as how we use subversion or how we use versioning. It's not best practice, but that didn't really matter. And it still hasn't mattered if we have ways to maintain it and ways to be aware of what we're doing. It's not conforming to best practice, but we can overcome that. So with this platform, it allowed us to go live, and these are the regions that we have. So it's a very simplified one, and this is probably as simple as it got at the time, but it's much more complex than that now. But the internal developers work on in the development region. Once they've created the site, they've built the site running on the server. They then migrate it, and we'll talk about migration in a minute, into the test where the developers and sometimes the editors, sometimes the business people come in and actually test the site. Once it's ready to go up, it gets pushed into the authoring region. Once it's in author, that's where our internal editors come in and put in their content. And from there, we push out to our live service, which are lockdown, and when I mean lockdown, all the services that aren't required are disabled. So sometimes, when you do something in dev, test, and author, then you put it to live. Sometimes it doesn't work due to the amount of systems that we lock down in our live server. So we also need to test here before we actually launch. Now we have high availability, which means the sites are basically identical to each other in each of those streams. But that also means we cannot edit in production. As you see, the database is actually separate. So if you edit in production, then you have disparate sites between each of those streams. That's why we lock them down. But again, that was enough to launch our sites and have them highly available, very secure, and to this day, the platform still runs. But we realize that we need to move on from there and make it more, add more features to it. So these were, you look here, some of the first sites that was launched. This one here and that one there were the first two sites that no longer exist because they've been sold. But they have a sentiment of value to us because they were the two that took us quite a while to build. APR, the one in the middle, even though it was built in 2009, still runs perfectly. And the reason for that was, even though this is built in Drupal 6, we've built it in a way that allows us to re-themed the site without touching the core code. So the site looks totally different to where it was in 2006, but it's still relevant today. Now, the learning curve, as mentioned before, was quite steep. Drupal, I don't know if you can remember back to one of the first days you've ever started Drupal, but in 2009 there was no courses, no books, or three books that I can count. And it was hard finding Drupal developers to help us. So even a small site like that took us three months. It wasn't, I guess, an easy thing for us to do. The other reason was that a few corporate sites in Australia at that time was using Drupal. I think I can remember one, and that was Lonely Planet, and they had literally a million pages in Drupal, but we really couldn't use them because it was a totally different business. So what we did, we took one of their platform experts to come in and help us set up our platform. So it helped us a lot there. But what it was, we took a big risk and a leap of faith, basically, in going with Drupal and learning and practice. And from then, we reached now today. So starting off with a humble beginning with one small site. This has been a giant leap for Suncall. And Drupal nowadays is used for anything from mobile to content repositories to whatever we need to do on the web space. So let's make a second observation then. Keep your platform simple. Launch very, very quickly. Use the community, consultants, and experts to get your first win to enable you to grow. And the most important thing there is you need to do it quickly because if you're launching as a platform, new platform and a site, that's going to take you months or even a year to do, and it's imperative that, as I mentioned before, we needed something quick that would have just pushed us back straight away. So it was very important to launch quickly. Now, from 2009, it was just a matter of time for the team to grow. The business demand was huge. Business was just waiting for something out there to enable them to actually engage their customers, basically. And Drupal was seen as that platform. Once we had those three sites up, the more advanced businesses, the ones that interact with customers, the personal insurance business like Amy and GIO, jumped on a bandwagon straight away. And they were our largest sites that we had to work with, even to today. But it was still hard work. We still had to go out, speak to our businesses. We still had to go to our board and did a lot of what we call selling at the time. A lot of demonstrations and a lot of found convincing. Because if we didn't do that, it would not have got out there. We were still a small team and people were still happy running their sites the way they were, even though we knew it wasn't supportable. So the team grew very, very quickly. In 2009, we had basically five developers develop three sites. As you can see, it doubled in 2010. It doubled again in 2011. This is where we are now. Last year, we launched 29 sites. We have about 30 people in the team now. But that doesn't sound a lot for 30 people. Keep in mind that we also have to support all these other things that we've built in previous years but to support all these sites as well. So we do end-to-end work. We do projects. We support the sites. We do consulting. And we basically are the front-end group for SunCorp. So we do also SunCorp front-ends for Java teams and a lot of that. So in last year, we did 29 sites but more than a thousand other smaller pieces, just this team. So we're quite busy. We can't do all of that out of just Sydney, where we are. So our team's distributed. And the reason why we have that is our business is across Australia. So in Brisbane, for example, that's where our core bank business is. In Melbourne, that's where our core insurance is. In Sydney, it's our life and wealth. But we all have this team here in Chengdu, our partners. And our partners allow us to flex. Without our partners, with the amount of people and developers that we have, we are not able to support all the amount of work that comes through. But that presents other challenges with such a distributed team. How do we keep them all engaged? How do we keep them all collaborated? And fortunately in SunCorp, we invest a lot of money in technologies for collaboration. Our SunCorp group itself has 16,000 people and it's evenly distributed across the three states. So the investment in these kind of technologies of video screens and communication mechanisms has been huge. So this allows us, for example, to do stand-ups, because I'll talk about agile in a minute, to do stand-ups via VC, not in the room, just out in the open. These are, you can push these anywhere. And also it allows us to actually set up a screen, like this, and have it on for full days. So you can actually see if the person is there that you want to talk to. You don't have to pick up a phone or whatever. You can actually just go there, stand there, maybe wave your arm or say hello to actually get their attention. And it's not expensive to set up something like this. You can get a TV screen now for fairly cheap. Cameras are fairly cheap. And this is just a netbook running Skype, $300 netbook. Setting something like this up is not very expensive. And Skype is our primary tool for connecting with other teams. But we also recently invested in a technology called Link, which is a Microsoft technology. If you use Microsoft, you're aware of Link. And we use Link TV, which allows us to have multiple conversations with multiple people at the same time. So you may have someone working from home, so SunCorp supports flexible work environments, and you can be working from home and still communicate with all your team members. The other challenge we had was trying to attract talent. And the way we overcome that is with rotations and cross-training in SunCorp Group. SunCorp Group itself is quite big, and opportunities for people to move around is a bounce. So you may be a Java developer. You may be Java developer for many years, but you want to change careers. That's when you would come to our team. We've had .NET developers, Java developers, or even people who are coming from the graduate programs joining our teams. Our team is quite diverse and quite young. And we have a training and support program in there that allows these people who have no Drupal skills to come up to speed with Drupal very, very quickly. Now, the reason why we do that is, again, pure Drupal developers, you heard Theresa this morning and a few other talks today, talk about how pure Drupal developers are still very rare in the marketplace. Even trying to find them in current day and age, much better than when it was in 2009, but trying to find them is very rare. You can get PHP or Drupal developers or WordPress, but getting someone with Drupal is not as easy. So what's our training and support program like? Basically, we put them to work straight away. So this is the 70-20, 10% rule. So 70% of their learnings, education, the way they work is from doing on the job real work. 20% of the time, we'll be pairing them with another expert, another Drupal expert. And the other 10% where they pick up the 10% of the knowledge is from videos that we have, from courses, from books. And with this training and support program in place, we find that developers who have no skills in Drupal at all come up to speed in about two weeks. Basically, in two weeks' time, they're very familiar with Drupal and able to really work on their own. In four weeks with this program, they are able to build their own site, literally. And we've had that repeated over and over, either with graduates or people who just changed their careers. And that compares to three months when we started. It's a huge saving in time. And that's how we were able to bring our people up very, very quickly within our team. And it's a model that is repeated across, not just in our team, but other teams in SunCorp as well. So how do we remain competitive then? How do we keep ourselves up to date and how do we actually find new work? So what we do here is we focus on our core competencies and outsource anything that we find is going to take us too long to do or it's not something that we wanted to head into. For example, a few years ago, we didn't have any UX or design skills, so we would partner with agencies to actually do that. We'll focus on actually just building sites very quickly after we receive the actual output from those agencies instead of trying to design it ourselves. Times have changed a little bit, so we are now focusing on those UX and design areas, but when we started, we just focused on the core competencies. We continually monitor the market. You cannot stop doing this. The market just in our space especially moves really, really quickly, so we had to try out new ideas and implementing at least two new ideas on every site that we build, and that's at least. Most sites, especially quick ones, have at least 10 or 20 new features. So it's our policy to actually try to implement two new ideas and then we reuse those ideas as we build new sites. So things like galleries or click to chat and those kind of things, we reuse all those ideas as we build new sites and it becomes quicker and quicker. This allows our businesses to be more competitive and spend less time trying to build these features. We just reuse them. Another very important aspect of remaining competitive is to showcase to other corporations. So we have people like Google or Optus and those other corporations visiting our workplace and we showcase what we do to them. Because the kind of things we do are also the kind of things that they do and by sharing our knowledge, sharing what we do, we all learn from each other. So core competencies. As you see, sites are what we do the most. Mobile, we also do mobile web, not mobile native applications. There's other teams that do that in our corporation. Content repositories and what that means is that we use Drupal to store content. If you... Does anyone here work with Java or is it in the Java space? The Java space tends to move to deploy quite slowly. So to make a change in Java and then deploy it may take you two or three days. Drupal can do that within minutes. Now, we use the content repositories to allow content editors to actually go in there, make changes to content which is displayed on our Java applications and deploy that within minutes. Traditionally, to do that would have required a developer in Java to sit down, manage the content, and then push it out. And that goes through many processes. Now, we save them a lot of time by building these content repositories and exposing that content to those Java applications. And we also do campaigns, quite a bit of campaigns. So these sites have changed, I'd say in the last six months or so. And the only reason why we can do that with our team is that we reuse a lot of the work. So the core code as mentioned before is some of them are still on Drupal 6, some on Drupal 7. But the reuse features and all of that we were able to reuse and change sites very quickly. Most of our sites have mobile and some of them are still on Drupal 6 and some of them are still on Drupal 7. Most of our sites have mobile versions as well. And these mobile versions leverage the content of the site. So Drupal, Frontend, and the mobile uses the same content. And the thing we built internally was campaigns or Facebook applications. Here, we take away all the technicalities of setting up a Facebook application provide a simple frontend for content editors to manage the actual Facebook app itself and then publish it to Facebook. We have regions that allow them to test before they publish it live. But by leveraging the power of Drupal, we were able to publish a lot of Facebook apps very, very quickly. And this has been an interest in many corporations because a lot of time as a corporation you don't have the skills to build Facebook apps. Normally you would go to an agency to do that. But by taking away all the technicalities we allow our content editors to actually do that themselves. What we also do nowadays is UX and XD. So UX is user experience and XD is experience design. The areas that we're trying to focus on and build internal capability for that. Analytics is very strong. So analyzing data, reusing the information and building better sites. We also do AB testing, which allows you to present different versions of sites to different groups of people. And I'll talk to that in a minute. And design, so we have a little design capability that we're trying to build up. And consultancy. We'll consult on everything frontend. Gamification, development, web architecture and anything to do with frontend with the consultancy. This is a picture of what we call ClickTale. Basically it gives you a heat map of our site. So this is an example of GIO. We integrate ClickTale into our site to allow our user experience and experience designers to actually analyze how people are using our site. This is just one example of the tool that we have integrated into Drupal itself. This is AB testing. So AB testing, we use a tool from Adobe called Test and Target. Test and Target allows us to put in rules and parameters to target certain groups of people. So as you can see here, if you're coming from New South Wales on the Bingo site, you get that look on the right. But if you're coming to Bingo from another state, you get a different look. And this allows us, after a few months of testing and the results that come out, to actually determine which one of them is better. And looking at this, you probably can guess, you know, that was a lot better than that. So after the testing, once we find out which one is better, we apply the look that's better. The way we work at SunCorp, as mentioned before, during 2009 with the transformation is agile. We use agile for almost everything nowadays. But again, to start off, it wasn't easy. We trained 3,000 people in our area, business technologies in agile in 2009, really to bring people up as quickly as possible and giving people all the support that they need. Now, all our projects go through the agile process, which is a basically concept where we sit down and work out whether it's a viable project or not to do. Once we consider this viable, we'll go through the initiate step, which is basically go drill down into those details, write story cards for each of those features, estimate, size them. Then again, if it's still viable and we still sign off, then we go into the delivery phase, and that's an iterative phase. Initially, the agile practices, which are things like doing stand-ups or retrospectives, which is reviewing what you do, and those kind of practices work, we weren't doing them. We were using the principles more so about collaboration and teamwork. Nowadays, we actually do a lot of the agile practices, so we stand-ups every day, we do showcases and retrospectives. And the deployment, so we have systems set up now that we can deploy very, very quickly. This is just an example of one of our wars. Basically, it's very hard to find a free space in the Sun Corp, especially where we work, because there is no war space, and then up with physical story cards, Officeworks doing very well from us, with cards and Blu-Tac and all of that. All of that's been held up by Blu-Tac. So we do iterative web development, not just for projects, but also for BAU. So this is an example of our BAU space. And because we work distributively, we can't just rely on wars. We also have to use some tools, and that's Gero and Confluence from Atlassian to allow us to share our views and our cards and our status with our other teams in other states and other countries. But recently, we've also employed the Lean Startup model. So Lean Startup model is about coming together to design quickly, to launch a product quickly, test it, and let it fail quickly. And then apply our learnings, and then iterate. So some of our sites that we've done, we've applied this actual model to our sites. We've built it very quickly, we've deployed it to the market, and then take the learning from there. It's not always going to be successful, because really, that's what we want to do. We want to test to see whether it is successful or not. Other things we do within SunCorp, every quarter is what we have, what we call FedEx, or Shippet days, or Dev days, different terms around the place. But basically, if you have an idea, you take it to your manager, or you don't even need to really, you form a group of people, and for two days straight, you work on that idea. After two days, you have a valid proof of concept, and you take it to your manager again, and you probably can productionize it. So there's a few of our systems or our applications that has gone through that process very successfully. One of them you may have heard of, if you watch TV a lot, the Amy Claims app with a tool, and what's her name? Ronda. Ronda and a tool. So that came out from a FedEx idea that we had. Our support structure. So support structure is very important, because we've been talking about Drupal quite a lot, but without our in-house specialists. So there are people like our iteration managers who leads our delivery for Agile, our business analysts, our UX and XD designers, our content editors, system engineers, network engineers, database. We weren't able to have a successful system, so in-house specialists are very, very important to us. We also have consultants, which we partner with a few technology firms out there, and they provide us with new capabilities and new ideas, and also allow us to flex. The community. So we are involved in the community. Even though we're an enterprise, we don't work in isolation. We do go out, we do share stories, and we do learn from other people in the community, and that's very important, especially in open-source space, and Acrea. Recently, we've partnered with Acrea to actually provide us with the actual corporate support and Drupal core support, and our engagement with them continues. Most importantly, though, is we take every single opportunity that we can to share and learn, and SunCorp have, fortunately, a lot of these opportunities, so some of these pictures here, my team are out there constantly sharing and learning about Drupal, about our platforms, about our new technologies, and that's how we keep the interest and the work alive with these kind of sessions. So, final observation. Your team, if you have one, will grow, so you need a proper training support structure. You need to focus on your core competencies and adopt a sound methodology and remain competitive. Thanks very much. Is there any questions? It's a very good question. So the question was whether different developers have different techniques and different ways of working. How do we do with that? So it's a constant, constant issue that we have and the way we deal with that is to run workshops, because if we get contractors in, for example, they're not aware of the process and the way we work, we normally pair them with people that are already in the corporation for quite a while, so they learn our process. But there are literally times when we couldn't do that because we're too busy and we haven't been before where a developer may come in, does his work, go away and then we find that we can't maintain that site. But the way we overcome a lot of that is have workshops. We call them quality workshops or one of my tech lead running a front-end society so that to educate people in the way we work to help standardize and reduce a lot of these differences. But that's one way we overcome it. But there's always going to be a difference. But to minimize that difference, we have a lot of workshops. Yeah, so we still have some of that frustration. So as you know, the way Drupal works is it doesn't provide back-with-compatibility, basically. So to move forward, we either have to rebuild the site or rebuild some of our modules. The way we overcome that is for our core modules, we would rewrite them. But for the ones that are non-core, we just find better ones or other ones that we can use again. But the frustrations doesn't really bore out because we know that if there's a site that needs to rewrite, we're going to do it in Drupal 7 anyway. So we didn't really have to change a lot of Drupal 6 into Drupal 7 yet until Drupal 8 comes out. So for user-generated content, we have them in internal sites. We've built a site internally that allows us to allow people to edit user-generated content, like comments, but there are other things like raising ideas, for example, and they can vote on those ideas. Generally, internal sites, we allow them to do that for external sites. We have to use third-party providers like Discuss or Facebook or those providers. It works quite well because there haven't really been that need for it yet, but we know that going forward, as Street was saying this morning, it's more about web experience now. So we do have to move to a platform that allows us to do that. No, so I didn't show that on there and didn't show the deployment process either, but we have an integration into our directory, Active Directory. We have a module that we use called LDAP, our LDAP module, and people use their own credentials to log in. We have roles for editing. We have roles for approving, and we have roles for developers standardized. Externally, we have a different access management system that we use to allow external editors to log in. Not editors, but external people to log in. We don't use any Drupal, use access at all due to security reasons. Yeah. It's becoming a common problem because it is rare to find Drupal developers, and when we develop and build the people up with these kind of skills, they are pure Drupal developers, so they become very attractive to the market. We do have, I wouldn't say it's a problem, but instances of where people are becoming very popular in other places, sure. With the agile way of working, our teams now are quite small, even on larger projects, so larger projects may have four developers on it, and that's for a fairly large project, but those four developers are supported by our iteration managers, our testers, our business analysts, so literally a team would be four to five or six people for building a site like Amy, for example, or building a site like SunCorp. That's how we would use it. For smaller sites, we would literally have one person or two person working on it, but again, with a lot of support. Yeah. Anything we build, we need to look after, so we don't own dog food basically, so we have to be very careful and we have to maintain the quality. Anyone who builds a site has to maintain it. Yeah. What's your culture for? Yeah. We have, what we call rotations. The way we build the culture is that when a new team member joins or when we bring on new team members in Chengdu, for example, we want to rotate them and bring them over to Sydney or Melbourne or Brisbane and bring them over, get them embedded within the team and then build the culture that way. Other ways is having regular catch-up and regular meetings. So every day, because we work agile, they stand up. So these team members talk together, talk to each other every single day. They know who's working on what. There's none of the... someone being lost and not able to have that communication. So they do talk to each other, they do help each other remove blockages due to just constant communication. Pardon? No, we use Link. So we have the technologies called Link, which is a Microsoft technology. We use Link and LinkTV to actually chat to each other. Yeah. And Skype, a lot of Skype. Sorry, just someone in the back. Yeah, we come up with a... So how do we manage all the different regions? We came up with our own system for that. We call it the traffic light system. So the traffic light system tells you whether that region is red, which means there's a change in there. Please don't do any other changes. And it tells you who's credit that and their little comment of what the change is. If it's green, means go for it. Do whatever you want to do it. If it's amber, just be careful. But we're going to also lock a region down so you cannot migrate or move that region until it's unlocked. Look at... What, sorry? Okay, so moving to a different platform, it's not a platform itself, but an architecture that allows us to meet the business needs in the future. So this morning, Trisha was talking about experience management. So if we're going to move to experience management, the platform we have now is not going to be suitable for it. So we need to come up with a new platform in the future and architecture that allows us to meet the business demands moving forward over the next few years. Experience design and use experience, that's another area. A colleague of mine is now running that area. But that's about building the skill sets internally to allow us to manage a lot of the demands that comes out of business for those kind of skills now. And we're working with our partners and also training our people in those areas to be more skilled in those areas. Yes, for the near future, we'll be all the same with the developer platform. Yeah, so with the agile process, the actual business owners, business sponsors, legal, all of that, they work very closely to collaborate with us as developers. So we work with designers and use experience people and developers, BAs, they all collaborate together and they all come together in our stand-ups. And as you see those walls, if we do a big project, for example, 10 o'clock every morning, they're all there. So the communication happens right at that moment. If there's a blockage, generally we can discuss right then and solve it right then, because everyone's there. So we're not the user situation where we make the decision and then later on go to someone else and ask them for something else. That's been reduced quite a lot with our agile methodologies. The biggest challenge, I guess, was managing the business demands. We kept constant demands and because we do look at, we do support what we build. So a little bit different to some agencies where you would build and then you have another team to support. We would build and there's no other team to support except us. So managing the workload, the demands and the amount of work that comes in constantly, that's our biggest challenge. Other challenges having distributed teams, even though we do have constant connection, a lot of technologies for us to discuss, as we mentioned, it's just the distance and sometimes technologies cause us issues, but yeah, it's something we deal with. Any more questions? Thanks very much. I hope you learned something today.