 Hello everyone, so I'm Ben Fletcher and what I'm going to talk about today is turning policy into a wiki. So what I'm looking to cover is the background and in terms of the challenges, not only the challenges of how the policy was in its current state, but also the challenges of introducing a wiki and getting over a certain mindset. We also also going to look at why we chose the particular content management system, what its disadvantages were and how we addressed those, and how we addressed the concerns of stakeholders in terms of when you talk about turning a policy, which is seen as quite a slow moving beast to a wiki, which is conceived absolutely differently, how do you address those concerns. Then also our approach to developing the policy, so the methodology that we chose because when you're looking at this giant problem, it can be quite daunting and then the conclusions observations and hopefully that will be quite an interactive thing. So there will be a lot of sort of hard truths that our stakeholders feel about media wiki, semantic media wiki. So we'll put those out there and see what people think about them. So I've been 15 years in the Royal Air Force actually in just over a week, it will be a 100 year anniversary. And really I've been extremely fortunate, I've had a really interesting career. If I could tie down, whether it's been delivering coalition systems in Afghanistan or dealing with surveillance systems in the UK, in a nutshell it's about getting the right information to the decision makers. So it is about moving that information, making sure the integrity of that information is there for the decision makers to make those operational decisions. So when I was given policy, I wasn't overly happy, I'll be honest with you. I didn't really join the Air Force to do policy, but I looked at it in the same sort of as the same problem. It is about getting the right information to the right people and how can we best do that. It was also that I was probably the sixth person in about five years who was trying to address this problem. It was a complex problem. It wasn't easy and really what we wanted to do was go back to basics. Why was a policy struggling to keep pace with ICT? So if I just talk briefly about how the policy worked. So as the JSP604 as this is called, the Joint Service Publication, this was the Defence Manual for ICT. So it is about what delivery inside the services or external contractors have to adhere to for ICT to be delivered to the military. The way initially this was done was we had a defence network. So in old school terms, we had a network and you had to make sure that you'd adhere to the policy or you were not allowed to join that network. So in simplistic terms, what we had a business requirement come in, you'd have the architects, the case officers who were the people who assisted the delivery teams to adhere to the accreditation requirements and the delivery teams. And they would work together to understand that business requirement. And then what we had were network joining rules. And these were specific rules that you had to adhere to. And if you didn't, you were not allowed to release that capability. And this formed a document which was a technical release readiness assessment. And it was risk management. So you'd have to adhere to a certain rule, certain aspects. And there would be a red, green and amber in terms of have you adhered to that. Are we accepting that risk to allow this capability to be deployed on the defence network? The way we wanted to, we saw a couple of flaws with this straight away. One was that it was difficult for project managers, the case officers to really understand their project timescale. What's the resources that they would have to put against the release of this capability? So the first thing we wanted to do was work out the agreed evidence along and what we chose was a generic project cycle, project phases. And the reason we chose generic project phases is because we could then map that against whether it be agile, whether it be cadmid, whether it be Prince II. So we didn't want to tie down to a methodology. What we wanted to do was to create an open framework where we could map it across. So phase one was understanding that. The other key thing was understanding who the risk arbitrator was. So who was the person who wanted that evidence? So you could go to them and say, look, we won't be able to deliver that evidence. Are you willing to accept that risk as the risk arbitrator? And they could say, no way, and that would escalate further because of course there's an operational imperative sometimes to deliver capability. So we have to match the operational perspective in terms of why this capability is required over the security risks or whatever other risks there are in delivering a capability. I've put phase one and phase two because we're dealing with phase one at the moment. What we've also done is changed it to ICT joining rules instead of network joining rules because we've transitioned. We now purchase services. We procure services. So it's not about joining a network anymore. It's about the procurement of a service and the aspects of that service and how that's delivered. So if we're purchasing a cloud service, what are the rules that we have to adhere to or make sure that we align with? The phase two bit is what we'd ideally like to do is to have that single documented evidence that is following the growth of that capability as it's being delivered. So you've got a complete history of why that capability is delivered, what the conversations were, the concerns were, and so on. That content management system in terms of tracking that body of evidence hasn't been decided yet. That's going to be the next phase. My cards on the table I clearly think media wiki would be a very good solution. There's other benefits in terms of SharePoint using Flow in terms of getting those documents to the right people. So that's further discussion. In terms of the priority of tasks, the key thing we wanted to do was there were a lot of documents out of date and we weren't quite sure the history of them. So we wanted to make sure we tied down who the authors were, who owned those documents, who could we point at and say, that's out of date, that needs to be updating, or what do you mean by that, can you clarify that further? So really, and was that content still valid and relevant? Initially the 604 with the network joining rules had a very good reputation in terms of it absolutely ensured that what we deployed on the defence network was safe, robust and meet the specifications. It became a victim of its own success, so everybody wanted to add rules. And the problem is that is then what happened was we were starting to delay the delivery of capability because we didn't, people, what I'd call is stavepipe thinking. So they were thinking, and they were doing absolutely the right thing. They were saying, this is really important that this rule is there because in the past somebody hasn't done it and we've seen that effect. But what we didn't understand was the impact of introducing that rule. So if a project's made up of cost, time and functionality, what was the impact of cost and time? Were they really worth it? Was it really justified to add that extra process within it? The hardest thing to understand within the JSP 604 in its current state was the impact of change. If I change this one document, what's the ripple effect it has throughout this document? And that was one of our greatest challenges and that stavepipe thinking I've talked about. But if we focus on anything, the key thing was to speed up delivery. Every change that we do within this policy, the first question we ask is, how does that speed up delivery? And I'm not saying step away from the security or step away from these other things, but we need to speed up delivery. That is absolutely key. We need to get operational capability to frontline troops. That is what this policy is about in a nutshell. So how do we speed up that delivery? The reason it was so complex was it was 2,000 pages, 90 PDFs of documents, and you really had to read the whole lot to understand the interrelationship between it. There was missing information, there was links out of date. There was what we've all experienced in terms of when you have your content within PDFs. So you'd have to spend probably a year, a year and a half to really go through them, really understand them, really understand those interrelationships, and then you'd have to try and work out what to change and what that impact is going to have. An incredibly complex problem. And really, well, it'd be no surprise otherwise I wouldn't be here. We chose Media Wiki as the content management system. And these were the advantages that we could see straight away. The history, seeing where the document was, because, of course, somebody may contract against that policy at a certain point. So straight away we can tell them what that document was at that certain date when that contract was signed. Open source means we have the ability to look at the code, to make sure that we're content that there's nothing nefarious going on. The ability to transclude information is absolutely phenomenal. To be fair, I didn't know what transclusion meant before I ever started for Media Wiki, and I use it on a daily basis just to try and show off. But that ability to have that single source of information and use it multiple times is an absolute killer feature. Having the ability just to Google something with such a vast community makes all the difference. It saves us time having to write the manuals. Our key thing about the manuals was don't write it if it's already there. Only write the things that are unique to our Wiki in terms of the manuals. Multi-platform, obviously. Low skill gap, although I will put a high skill gap and we'll talk about that in a sec. Also, I had good friends in NATO who were very helpful when I was in that beginning learning curve, and actually the argument that NATO and NASA are using are used constantly. That's a winning argument straight away. It's very encouraging when you've got strong organisations like that converging to the same solution. We've talked about security. The ability to segregate users. Actually, for our Wiki, the Wiki will be eventually published on the internet. It is supposed to be out there for industry to be able to have a look at and understand what they have to adhere to. In this sense, it's not required. But if phase two, where I talk about the tracking and the following of capability, which will be capturing risks and all those sort of things, that's something we would have to keep separate. Also, when you've got military civil servants, contractors, there's also lines of segregation there as well that you have to think about. There is certainly a justification for working out an agreed way of segregating users. It's no coincidence that Microsoft give out office free to schools. They create a generation who pick up Microsoft Word when they're older and straight away they can use it. There's a lot of people who've got a lot of good things to say towards a policy who really struggled with editing on a Wiki. We need to address that. We want greater contributors. We need to make it. Visual editor, I don't particularly like it. I quite like going back to the Wiki pages and just typing like that. But it's not about us. We're converted. We need to get the next generation on board. The reputation of the Wiki is something, again, I will talk about. Policy, static, quite rigid Wiki. I don't know what it is about human psyche, but we do always... First of all, we hate change. That's absolutely given. Secondly, we always remember the bad things. Everybody tells you how horrific the internet is. Daily basis is probably a bit of an exaggeration, but certainly on a weekly basis, every three or four days, I'm asked how can you possibly put policy into a Wiki? Somebody can just vandalise it and so on. We were discussing this last night what we need to have is killer answers for that. We all know what you're doing is you're taking the Wikipedia example where you can have anonymous editing. I can see everybody who makes a change. The other thing is I'd be seriously worried about my organisation if somebody is going around vandalising the Wiki. I think we'd have a far greater problem than that. I think if somebody put it, it would highlight probably greater issues that we probably needed to know about anyway. We need to address that because Wiki, unfortunately, has a poor reputation that needs to be addressed. What I want to talk about now, I've convinced the chain of command that a Wiki is where we should go, and I've also shown them the advantages of semantic media Wiki and how we can actually start to database our knowledge and put it forward. It's quite a good diagram. It's from a joint defence publication. It's called the information management bridge, as you can read. We've got this vast policy. What we're talking about is we want to be in this space. We want to enable decision makers to make decisions. It talks about the infrastructure, we understand that, and then this managing of information, the exploitation and so on. It's implying that you need to get your information management right and obviously the infrastructure and all those sort of things. I actually think that's the wrong approach. I'll tell you about this bridge. Does anybody know this bridge? Fourth rail bridge. When they used to paint it, they would start at this end and they'd take them about four years and they'd get to this end. Guess what they had to do? They had to start again. The term is like painting the fourth rail bridge. That's what I think, sadly, actually science has ruined this. I've developed a 15-year lasting painter. It's still a good analogy. What I'm saying is start at this end. Start at what do your decision makers need? What is the first thing? What's the most prioritised, the things they need? Start at this end and say, you need this, that breaks down into this database schema, whatever you want to call it, and then gets to go here. Start trying to boil the ocean, paint the fourth road bridge. You'll never finish. Get here. This is where you are adding value to the organisation. What is it you need? Write. We can do that. What's the next thing you need? Actually, we've done half of that the first one. To me, don't get stuck in that space is basically. I've seen tragic situations where people who are trying to do the right thing with information management, creating these slightly draconian rules on how you manage information. The concept is correct if you've got it all, then we can search it and all that sort of thing. But actually what it starts doing is impacting the decision makers because they're having to adhere to these draconian rules without actually people thinking about what are we trying to achieve. We want to be at that sharp end enabling those decisions. Quick win. Absolutely. It's agile. Perfection is the enemy good. We say good is good enough. Let's get it out there. Let's deliver in an agile way. Let's get those prototypes. I talked about the beginning. The most important thing we needed was we needed to understand who the stakeholders were within the document. Straight away, we created little info boxes. I know you'll laugh at my basic attempts at semantic media. The first thing was, who owns that page? Who's the author? Who's the owner? We can point to them and say, look, you haven't updated this and so on. Do you actually mean this? So we had people that we could actually nail down and say, from that we built the stakeholder pages. This is absolutely critical because, like most organisations, we're constantly changing. We're looking at how we can reorganise the business straight away. We can say, well, if you get rid of this team, they're responsible for this. That is your decision, but please understand the impact. So we straight away could now show the impact of change to the business. As a handover, they could see straight away what they're responsible for within the policy and understand those areas as well. It benefited in both ways. I talked about the project plan. What we started doing was mapping it. We wanted to try and be as agile as possible. Then what we could do was relate those bits of evidence that you have to produce when who is the arbitrator of that risk. So straight away, they've got a better idea of the resources they require, what they need to produce and when they need to produce it. I talked about the policy becoming a victim of its own success in terms of people adding these rules and not really understanding the impact of cost and time to the delivery. We identified 60 documents that people would have to produce for the delivery of capability. Now, what we started going back to and saying is, do you actually require that document? Or what is it you're asking for within that document? So what we started building was a body of evidence. Actually, you found a lot of the rules, a lot of the risk arbitrators. We're asking for the same thing just in different words. So we're now looking at how we absolutely nail down our taxonomy. So we're asking for the same thing, the evidence to produce, and then we have this single document which is about the capability and all of that evidence captured on there with the discussions there. You understand why this was delivered, why risks were taken, why decisions were made. So I come from a cybersecurity background and it always comes back to this, the CIA triangle, confidentiality, integrity and availability. We have to be really, really careful that we're not burdening the project managers so much that we don't ever deliver a capability. So how do we get that? I'm not saying release a system that is dangerous to other systems, but let's understand that risk and that's what we're trying to do. We're trying to better understand and articulate that risk of capabilities being brought into the military. We're absolutely key for this. We're throwing things out there, agile delivery, get it out there, see what people say. You can't, you can spend too long speculating on what should be delivered. Get it out there, let people throw spears at it, but actually if they're throwing spears at it, they're showing an interest. So it means they care. So now you've got another stakeholder who's going to help you develop this and drive it forward. Change process is actually quite difficult. You can change one word, you could put no, not, and it could change the whole context of that page. So it's something that we're trying to grasp, but we've tried to break it down in terms of minor changes just changing the wording or whatever grammar within the page or if the teams have changed names. Significant change is basically you're making a change in that page, but it has an impact on at least another page. So therefore we want a larger number. We called ourselves the curators. I was very keen to make myself called a curator, so I didn't have to write any of this. I just designed it. I let other people write policy. So day-to-day business, we want to give them mission command. We don't want to be holding their hands the whole time, but once a change starts stepping outside of their area, they need to start telling us. If it's a major change, i.e. you're completely redesigning that page, what we do is we create a draft page, so we put it in a draft namespace. We allow all those discussions to go on there. We have a release process and then we'll do a large changeover. I have to say analytics. So some of the people we had to convince were government digital services. Actually they were fully on board. They liked the fact that we were looking at other technologies for the hosting of policy. We're getting contacted probably on a weekly basis by other policy owners asking us how we're doing it and how we're overcoming some of the challenges. Analytics is key because we need to quantify the evidence. We believed there were a lot of people going on our pages, but we also wanted to understand how people were going through the document. On the front page you see I had... Actually, that took me ages. I know it's only four buttons, but that took me ages to work out because first of all we had lots of links on the pages, but I wanted to narrow down. If you think that people can only memorise seven things, the average human can only memorise seven things, the rule is you shouldn't have more than seven things there. We wanted to consider all the stakeholders and work out which way they're going to go into the document. It's trying to make it as simple as possible for the users just to drill down into that information. This was telling us how people's route through the wiki, how long they spent on certain pages, really useful. Observations, the controversial bit. Some of these are my opinions, some of these are stakeholders' opinions, but these are opinions that have been put out there. Style. A lot of people, when you're trying to sell a wiki to your bosses, it could do with looking a bit slicker. I'm just throwing out there. I think it looks a bit Microsoft XP. Some people like the way it looks. Style could certainly... It's a sad thing, but aesthetics are a major factor in people choosing capability. It shouldn't be, but it is. Editing, as I've said before, we need to capture... We're asking people to spend their time giving us their knowledge. We need to make it as easy for everybody as possible. We need to have some killer answers to can't anybody come up and wipe off all your data? These standard questions. Semantic media wiki is really, really difficult to understand. It took me a long time to really understand the benefits of semantic media wiki. Now I'm blown away. It's absolutely phenomenal. I show demonstration pages and so on, but it's not doing itself any favours because it is not selling itself as well as it could. Visualising information. People are getting lost in our wiki. The ability just to have what page links an easy way of doing it. I know there's lots of ways of doing it, but an easy way to show of where you are within the document and how you got there and who the pair and who the childs. Something simple would be again absolutely very useful. What are the unique selling points of media wiki? Selling points of semantic media wiki. We need to get that information out there. We need to put that in frequently asked questions. So somebody comes up to me. I've got 10 seconds to sell to them. What it does, let's have it. Between us, there's lots of word smiths. Let's come up with some really catchy. In business speak, how are we going to sell this? Developer environments. The next generation, you want people just to be able to jump onto something. It is way too complicated to download stuff, to download the extensions. We all accept that. If we want people to become more stable, the saying is for every pair of hands, you get a free brain. So the more people we get, just playing around with it on sand pits and everywhere, the more people we will have starting to contribute. We all understand the benefits of increasing the organisation. Recipes. There are standard things. We've actually put them so that websites, the enterprise media Wiki, we started putting them down. Things like meeting records. Things like bug trackers, issue logs, those sort of things. We can create those little recipes. How do you create them? Bang straight away, you've got a 10-minute structure of how I can now build that onto my Wiki. Let's start building best examples and showing people and just giving them step-by-step guides on how you deploy that onto your system. Straight away, you're giving them a prototype to show to their bosses. Bundle extensions. Just give me something double-click install done. If you want, build it around business personas. If it's an engineering company, if it's a marketing company, it doesn't matter, but let's put it all together and just sell it out there. Security layers. The more I think about security layers, because we had a lively discussion about it yesterday, it is really complicated because it's the aggregation of data that can increase the classification. That is very difficult to understand. The more I think about splitting a Wiki, the more difficult I think that is. I think actually you need to talk about deploying separate wikis and blocking those links in between. I don't know. Most of us, the solution is in this room. What we need to do is to put a white paper out of this is our solution to security layers. There is absolutely a business case for that. If we can put forward what we think is the best solution that enables people to say, this is how we would do it in this circumstance. We talked about crossing the chasm. Media wiki. I don't know if you've seen this. It is about how you jump from being a... Jumping to be a mainstream capability that people use. They talk about the 14%. You want to get past the early adopters and that's when you're into the money if you're a business. You're trying to jump that 14%. I've put just because it's open source that doesn't mean it shouldn't behave like a proprietary software. Shouldn't look at how it can market itself. Shouldn't look at... There's nothing wrong with looking at other capabilities and saying they do that well, how could we do that? How could we replicate that? There are some things that the media wiki's not meant to do but there's other things that go, actually we could do that. We could probably do that better. Real life examples we've talked about. Let's showcase the capability. Let's use this website, send it out there, get the prototypes out there. We're talking about creating a fake company and just all their reports and so on just so you can go through it and understand it. Let's address the fake news. Let's have those answers to those questions in terms of can anybody come up and delete everything and so on is my stuff safe, et cetera, et cetera. We've all heard it. Let's create those answers to it. That is it from me. Questions, yes, sorry. Peter. Am I first? Good. I like your remark about the recipes discussed with a couple of people over the days and especially Ike, who is not here today, he came up with some very good advice and I agree that if you install the wiki from the box, you end up with that single white page and then you have to do something to create and there are a lot of use cases, a lot of proven use cases that people create over and over again and it would be easier to install those as a basic functionality on top of your new fresh wiki install. It would make it a lot easier for people to get started with making it a tailor-made solution for their own good. So things like having a document management system or having a list of events and a calendar or having a way of gathering personal data and creating contact lists and mailing lists or you name it. There are a couple of those basic functions that people might want to have in their wiki and if you can find a way to make those easily accessible and easy to install on a blank wiki, that would be a great feature, I think, especially for people who are relatively new in the game and who haven't built up their own experience in the wiki markup yet. I came with an interesting suggestion that all it takes is to create the definitions for a set of properties, forms and templates and categories and you can easily import them in your wiki as an XML file. So if you could build a website that hosts a couple of those examples and a user could download them in XML format and import them into their wiki, they're set to go. So that is relatively easily. The only thing you need to do is to build those recipes and make them offer them to the public. Absolutely. I think that's where the Enterprise wiki website. We've discussed that. We should put down our suggestions for recipes and then prioritise them, all agree on a few, start creating them. So it almost becomes the app store for media wiki. Exactly. If there is any interest of other people doing this, I'm happy to set up a little working group or a platform where a couple of people can exchange ideas about this and we can make this available in the open domain. Well, I saw that you had a page owner and a page author. My experience with legal people is that they want everything to be casted in concrete and not to be touched anymore and it has to be perfect, unfortunately. So for them, a wiki is like it is always flowing around and it's never... I was wondering, do you also use an extension of closing, making a page not edible? No. So first of all, I don't want to stop people going around and creating grammatical mistakes so we've said, absolutely do that. If you're not the author, if you're not being delegated north of that page, you're not to change the content of that page. It's a verbal thing. The administration of trying to lock them down and so on, I don't think the workload justifies the risk. Every day I look at the changelogs and I think we had a discussion with the NASA guys last night and they said in six and a half years they haven't had a problem. So there's a perception that could be an issue but I don't think there is an issue. Anyone else? Thank you. You mentioned analytics. Do you guys have something separate and stalled? Yeah, I've forgotten the name. It's Mammoto. I can't remember. It was Piric before and it's changed names recently. But yeah, that's the one we installed. Watching and looking at click through links for where users are going? Yeah, so to me the most powerful feature is understanding the route that people go through the wiki. Because it makes you wonder why you've gone down that path, what's led you down that way. But there's lots of other things where the hits are, how often it's hit and what pages are most popular. More importantly, what pages are never visited and why. Let's get rid of it then. I think no more questions. Excellent. Thank you very much.