The Challenges of Compliance: Mark Arbour and Andrew Chapman

Blue Fish: Andrew Chapman, Mark Arbour–welcome to DM Developer

Mark Arbour: Thank you.

Blue Fish: Maybe just to start out if you guys could both kind of introduce yourselves, what your roles are at Documentum and kind of what you do.

Mark Arbour: Sure, so Mark Arbour. I’m the General Manager of our Compliance Business Unit in Ottawa and I also run the Rich Media Business Unit in Toronto, so those are–within Documentum we have several focus business units that build out compliance, collaboration, search, web publishing–etcetera, so I’ve got the two in Canada.

Andrew Chapman: Andrew Chapman. I’m the Group Product Manager for Compliance, so I look after all of our compliance products including records manager, retention policy services, DCM and DSM.

Blue Fish: Great. Thanks.

Andrew Chapman: You’ll translate those acronyms I assume.

Blue Fish: Yes. Absolutely. So my first question is when people think of compliance they typically think of things like Sarbanes-Oxley, HIPAA, CFR Part 11, but that’s certainly not everything related to compliance. So maybe if you could just kind of give a–for folks unfamiliar with compliance issues in general, if you could kind of give a background on why compliance is important, what is the value that Documentum brings to the table.

Mark Arbour: Actually you can talk about your beautiful slide.

Andrew Chapman: Vision for compliance. So that is a lot of compliance. I mean that’s definitely the most form of compliance is complying to external standards or even internal standards that are being imposed on you with records management as well, which is a different flavor of compliance, but compliance really is something that’s completely pervasive now. Everybody has to be compliant all the time to some sort of standard inside of the company. You may be compliant to the size that your mailbox is allowed to be. It’s not particularly a legal requirement, but there’s probably a requirement that everybody has to be aware of all that they’re deleting, what they’re dealing with, if you receive an email that’s related to business–you know, it may have some sort of compliance applied to it and you have to be aware of that. Every part of your business process has to be compliant. You have to be or at least be compliant enabled so you’re aware that any time during any business process you may have to be compliant to some standard whether it’s something legal or it’s something internal. So we believe that–what we do is make compliance much more pervasive that compliance should be exposed throughout the whole of a lifecycle from creating an object throughout its whole life to be expunged at the end of its lifecycle. We also believe that it should be as inevasive as possible that to make compliance successful you should expose compliance in a way that it’s completely transparent are RPS does. You put something in a folder and by virtue of putting it in a folder it gets retention policy applied to it or it should be as small and overhead as possible. You’re creating an object and when you create the object it asks you a code of extra questions to do with record classifications and maybe the questions are just completely benign–you know, which department they’re for and what kind of document is it and from that you can ascertain what retention policy should be, what–if it’s a records does it have to relate to some other internal or external standard. So it should be something that is as inevasive as possible, that it should be pervasive across the whole of the lifecycle and the whole of the desktop.

Mark Arbour: One of the things is we started to realize that in the past we built specific clients for compliance–DCM and such and what happens is people come up with new and innovative ways that use your technology, but if you tightly couple the capabilities of deploying it, it limits what they can do. So one of the things we’re really pushing for is to get a control content records–all those things in the platform, lowering the platform with a published API, so people can then extend your offerings in as many ways as they want and so we’ve already done that with RPS and we’re pushing for that with the DCM client. So we really–I mean in the future it would be nice to not have a DCM client, instead set up control content capabilities–you know, I’ve got a piece of content that’s controlled, I want to be able to audit what’s done with it, I want to be able to track every activity, I want to be able to put digital signatures on content, I want to have all those services that I can call from any other client. So overall we’re moving towards a unified client concept at Documentum and pushing these compliant capabilities in the platform is like a critical part of that. It’s kind of interesting, because when you go with customers–they’ve gotten–they’ve got ways of using your product you’ve never thought of and really what they ask for is, hey how can you make it easier for us to–what we’re trying to do is say, build these platform components in a generic way so that people can customize and extend on it, but offer one or two sample applications that prove that the stuff works. So for instance, we’re just shipping a product–Submissions Manager–DSM for eCTD it’s called and it just came out this week. And what we have there is a structured publishing platform and again, it’s related to compliance because you’re publishing information to the FDA for instance. It’s got to follow a certain format and structure and it has to work in concert with DCM, but we don’t want it to just be used for eCTD Submission. We want it to be able to be used for any type of structured submissions whether it’s mortgage submission or a healthcare submission, but we don’t necessarily intend to build all those applications. We’d like to provide our partners with that submissions platform and have our one sample application and say, hey we built an application to prove this works and it scales and does what you need and now partners, you can go and extend it to any other type of structured compliance submission you want. So that’s where we want to head is build a platform, build the framework, build on app–maybe two to prove out that it works and that you can deploy and then provide our partners the ability to extend any way they want.

Blue Fish: So that’s the vision as far as the stack goes today?

Mark Arbour: Yes.

Blue Fish: In addition to those kinds of services or capabilities that are deep down inside the platform, what kind of constitutes the stack today?

Andrew Chapman: So if you look at the record side then it’s basically around retention policies, around file plans which is the way it can be structured to records, around being able to apply holds, being able to do discoveries, being able to do expungements or delete things so they’re really deleted. So that’s on the records side. On the document control side it’s primarily about having controlled lifecycles of an object so that you can make sure that it only moves through steps of the lifecycle based on the rules that you’ve applied to it–that you’ve enforced on it, so it has to be signed off by whoever it needs to be signed off by before it can move through the process, but after a certain period of time it will be deleted. So that’s controlled lifecycles. Prints and file controls so that you can stop people from printing things, that you can stop people from saving things outside of the environment they’re in, manifesting signatures or watermarks onto documents, if documents can be printed manifesting a unique control number onto the document so that you know whose copy it is that was printed and left on the printer or photocopy–etcetera. Digital signatures and electronic signatures are a large part of that which we would see as a separate piece of functionality. Am I missing one?

Mark Arbour: Transformation–to be able to watermark things and have a platform transform. We have that in contract information services out that allows you to enforce certain renditions and sizes and resolutions of content as you put it into the Documentum system and again, that’s something that we had out–we’ve had a transformation engine for three years and we’ve just come up with a new version which is a general purpose transformation engine for PDF, Rich Media, Audio–whatever and a lot of people have actually come up with innovative ways to use that to say, I’m going to put a piece of content into the system. Of these twenty renditions each one has different access for different users, has different–it’s developed for different channels. They’re not particular channels. We have to have certain information kind of printed out in the watermark. If you’re a life sciences company and you’re going to do marketing material, you have to have disclaimers if it’s on a certain channel versus another, so things like that. A transformation engine.

Andrew Chapman: And then enhanced auditing is another part of that, so the ability to know exactly what has been changed on a document or even what’s been changed in the configuration of the application you’re using to manage the control documents. The other one to consider that people often forget is just the core document and platform. You forget any of the products that we use. If you put something into the Documentum platform you’re getting a pretty high level of security. Not as high as you’d get with DCM or with RM (Records Manager), but pretty high level security. Certainly high enough for most people. You’re getting auditing, you’re getting logging, you’re getting notifications, so just putting content in the doc base is a good first step towards getting compliance.

Blue Fish: So obviously compliance is driven by regulatory standards either imposed by a government agency or by a collection of companies or organizations. How does your group go about collecting feedback from your clients as to what’s important to them and what are some of the things that you’re hearing either at the conference now or in the past few months about the biggest compliance challenges that they face or that they fear in the future.

Mark Arbour: Yeah. I think for getting feedback we have things like our Life Sciences Advisory Council, which runs about once a quarter. We have product management is out in the field all the time with customers trying to get feedback on the products–you know, what’s working, what’s not. Those are kind of our main channels–face-to-face interaction with customers and things like our Life Science Advisory Council. For all the standards that are out there obviously we kind of keep up to date on any changes and we work closely with people like in records JITC Group in North America for the DoD standards and PRO groups–you know PRO, VERS different standards around the world, so I’d say regular interaction with specific customers can be the best way to get feedback. Get people that have implemented your product and they come up with a list of–you know, hey here’s some areas that we had to customize to fill gaps and–

Andrew Chapman: On a high level we actually have it easy from a vendor perspective, because we are told exactly what we have to do, so a regular of mine who is a good example of this. When the Department of Defense come into our offices, sit down with our record mining products and want a set of scripts, they basically–you know, they tell us exactly what the product has to do, not how it has to do, but exactly what it has to do, so we know exactly what we have to put into record management just to get DoD to have to do certification for instance. Now obviously we have market differentiators, but we have a lot of market differentiators–things that we can do on top of Chapter 2 around physical records management, around long term records management which is interaction with Centera for instance, so we have a lot of differentiators, but from the core product perspective we’re pretty much told what our products have to do. I mean for Part 11 compliance we know that we have extra security–the requirements that we have to implement, so we implement them. But then as Mark says, we spend a lot of time talking to customers getting feedback–you know, looking at people who file product change requests, so we spend a lot of time looking at those because some people have different ways of interpreting those same rules and people have different ways of doing it and people are interested in different part of it. But generally we start with the, well what do we have to do–you know, what does SAC (Science Advisory Council) says we have to do? Provide that functionality and then build differentiators. Well a lot of differentiators come for free, because we’re built on top of Documentum, so a lot of things that we sell as things that are unique to our solutions aren’t big costs–you know, rendition management, version management, automatic rendition creation for long term data storage for instance. These are things that come because we have other products in the stack that already provide this functionality.

Blue Fish: It’s a good segway to a question that we asked Howard in Barcelona was, what are some of the emerging technologies that are exciting to you and he mentioned specifically things like wikis and blogs and RSS and obviously there are companies that are sprouting up that deal specifically with IM compliance. I think one of them is IM Logic-I think it’s called that-makes an IM compliance tool. Are you hearing from customers the fact that they’re starting to say, we’ve got to monitor what’s going on with these wikis inside the company with blogs. How are you guys addressing that?

Mark Arbour: That’s kind of a forward looking–you know, we see they’re becoming more pervasive. I don’t get a lot of customers that are saying, how are you going to manage my blog? I don’t see the blog in the corporate world being very pervasive yet, so I think it’s something that maybe–you know, people are using them, they’re out there, it definitely isn’t top of mind of our customers. What I’m hearing from a records perspective for instance is people want to have automatic everything. They don’t want to have to manually create records, manually identify records. They want to have tools that can go out and find the records automatically determine based on some taxonomy on how they’re going to classify them. They want to have zero click–you know, not have to touch anything if they’re doing any kind of manual work. It’s all automated and behind the scenes, because what they’re afraid is things are going to get kind of classified incorrectly or they’re going to lose information and they’re not going to retain something or they’re going to–

Andrew Chapman: To bypass the system.

Mark Arbour: Or they’ll bypass the system.

Andrew Chapman: It’s difficult to use.

Mark Arbour: So right now when you talk to anybody who’s implementing a record system for instance, they’re all into, I need it automated, I need to know that things aren’t going to get misclassified, I need to have auto-crawlers and I need them to go across my doc and find things across other repositories non-Documentum and so really that’s where a lot of our effort is, is to try to work with our ECI Group–Enterprise Content Integration Search Group and build all these capabilities to hook into other repositories and adaptors into other locations and file systems. So really that’s top of mind. On the life sciences compliance side of the world, really the thing people are–I hear probably nine times out of ten is helping them to reduce validation costs. That is still–I mean, it’s something that has been forever, right? But it’s still the number one thing. It’s like it costs too much to validate the system, too much to upgrade the system. It’s just a very complex process and that’s what people are focused on. So when you go out and you present a visionary, hey here’s where you’d like to have something for auto configuration of your validated work processes and configurators and stuff and they’re like, that’s great but I need my validation process to be faster and less costly or I can’t adopt any of this great technology because it takes too long to upgrade from system to system. So I think people are pretty practical in terms of what they really want to do with their system. With records it’s, hey I want to be able to take my twenty million emails a day and I want to be able to get them in the system and I want to retain them and I want to be able to delete them automatically and I don’t want to have to go in and manually do a bunch of work. On the life sciences side I want an efficient way to upgrade, validate and take advantage of your new technologies and right now a lot of our customers are working on three or four year old versions because it costs them too much to revalidate them. That’s what the reality is. That’s what they’re interested in. That’s what’s kind of keeping people from innovating right now.

Blue Fish: It seems that, at least from the customers that we talk to, that up to now or maybe even a little while ago that people were trying to catch up. Right? For HIPAA compliance or different FCC standards–

Mark Arbour: Yeah.

Blue Fish: …or certainly in the life sciences industry.

Mark Arbour: Yeah.

Blue Fish: But now it seems that customers are taking compliance a lot more seriously–

Mark Arbour: Right.

Blue Fish: …and instead of playing catch up and trying to figure out what all they need to do just to be safe, they’re kind of shifting it and saying, okay well let’s try to look out a little bit ahead and see what’s coming and try to build out a framework like you say down at a repository level to try to stay ahead of the game–

Andrew Chapman: Right.

Blue Fish: …because it’s a game really.

Andrew Chapman: I think this comes to–I mean the thing that I’m seeing that is sort of emerging–it comes down to trying to get people recognize they have to do this now and in often cases they recognize they have to just do something now even–but they don’t understand exactly what they need to do. They realize that they have to do something otherwise they’re really liable. Collaboration is something that the people seem to be getting more interested in and a collaboration with a little bit of intelligence behind it, so we were demoing this week DCE (Documentum Collaborative Edition) and DCM and I’ve had a few people come up to me and say, that’s great, we’d love to be able to collaborate around our control documents and be able to sort of discuss the document as it goes through its lifecycle, can you make sure that when the document becomes effective that all of those discussion threads are deleted? Which is a beautiful concept. It’s easy enough for us to do, because we understand the relationship between those things. It’s not like a blog where it’s just sitting alone and then you’ve got your control documents and you’re talking about them. We actually have a relationship there so we can go and purge out the discussion. So collaboration is something and what collaboration is indicative of is that people are realizing that they don’t want to collaborate on a control document. They want to bring a control document into their normal business process, because that’s what you’re seeing in collaborations. You’re seeing people working as they are anyway, but you’re bringing the document into that environment. So I think that’s something that is part of this pervasiveness and not something that we can do today and we demoed at Documentum this week. The other one that there seems to be quite a bit of noise around and I think it’s actually because it’s an emerging technology–I don’t know whether people really need it or whether it’s just because it’s cool and it’s sort of emerging is digital rights management. If you go to the expo there’s a lot of people who are now calling it different things, but a lot of people are now looking at ways of protecting content when it’s perhaps outside of the repository for instance.

Blue Fish: Is it like SealedMedia?

Mark Arbour: Right.

Andrew Chapman: SealedMedia, Code Green–you know, have a system for preventing content from leaving the firewall for instance. You can just copy and paste it from one document into an email and send. It can recognize that that’s controlled content and will stop it going out the firewall. So there’s a lot people I think looking around–you know, whether it’s print and file control or whether it’s something like SealedMedia or whether it’s applying a retention policy to an object where it’s outside of the doc-base, which is something that you’re able to do. I think there’s a lot of noise around–you know, people just realize that it’s okay to be controlled inside of the doc-base, but we also need to control content outside of the doc-base or control it when it’s left the doc-base or at least know that it’s left the doc-base so that you know where it went. So I think collaboration and DRM are the two things that–you know, we’re dealing with a lot of muted issues and typically people in compliance are a very practical, pragmatic sort of focused bunch of guys who know that they have some real life problems to solve. They’re not sort of visionaries who really–but collaboration and DRM is definitely interest and they’re both areas that we’re addressing.

Blue Fish: What’s the competitive landscape look like right now for compliance? Who are the big players right now besides you guys?

Mark Arbour: Yeah well most of the traditional big ECM players in the record space are out there, so you’ve got your IBMs, your FileNets, your OpenTexts–they’re out there in all the deals that we’re in competing and I think the story is–the reason why the ECM vendors are out there instead of a stand alone kind of a records player is because people need to be able to do records management and be able to control all content types, so the marriage of ECM with records management. It gives those players a competitive advantage in the record space. It’s the big ECM vendors. In the life sciences space we’re getting–there’s a lot of smaller niche vendors out there that are offering specific tools and I think a lot of cases, because life sciences people are really trying to solve the real practical problems like if they’re–you know, get their drugs out the door faster, cheaper. They’re looking for anybody who has a solution to solve those drug problems, so there we see a lot more of the small–there’s dozens of small vendors that are offering point solutions and they seem to be pretty successful, because they’re able to say, hey I can help you solve that problem and help you to validate the solution and get it into your system quickly. Now I think over time we’re going to see that a lot of these capabilities are commoditized and put into more of the ECM solutions, but right now there’s still a lot of the small players that are offering solutions for life sciences customer. And the big players are there too, but we see a lot more niche players in life sciences.

Blue Fish: Mark, you mentioned earlier about the desire to move compliance down closer to the repository.

Mark Arbour: Right.

Blue Fish: And that’s kind of the trend on how to address compliance. From a regulation’s perspective, are there any emerging regulatory standards or issues that you’re hearing from clients that maybe aren’t here today but that you know are coming in the future that you’re trying to keep ahead of?

Andrew Chapman: And we know that they are rewriting the DoD (Department of Defense) part of the thing standard and we know that a large part of the new standard is going to be around business processes and they’re probably going to change the name of it, but it’s currently–what is currently Chapter 4 becomes Chapter 3 and the new Chapter 4 is all about freedom of information and it’s almost entirely built around business processes. It’s just lots and lots and lots of business logic. Although we don’t yet know exactly how we’re going to address this, it’s almost certainly going to be addressed using BPM–our Business Process Tool, so if we want to sort of piggy back on BPM then we to need to make sure that we’re down in the platform so that we can just bolt our logic into activity templates and BPM will run away with implementing the logic, dealing with all the exceptions enough so again, we just manage to leverage the stack and get a solution out there faster than everybody else. So that’s the big emerging standard that we’re aware of is DoD–the new Chapter 4, which has nothing to do with the old Chapter 4. We should probably edit that out of there. We’ll just cut all of that and just talk about the standard, because it was way too confusing, but that’s certainly the biggest one that I know of that’s coming. It’s for the new Records Management Standard for North America which starts in–I think they’re releasing–it’s sort of out as a draft now. I think it’s being released in June of next year, but I’m actually not aware of any other large emerging standards that–I mean, we’re pretty much–when you look at–we actually have a–I found this chart of all the different things that we do in compliance and so this is like 25 things that we enable–you know, security, signatures–etcetera, etcetera. A big list of things and across the top we have all the different standards or a selection of fifteen different standards and then we’ve got Crossware. That standard requires that functionality and 80% of the chart has Xs in it, because the functionality that is required for compliance is almost common across every single standard. There’s nothing really new in compliance from a standard perspective. They’re all expecting us to do almost exactly the same kinds of things. What we’re looking for is ways of being able to pull those things together in different combinations as efficiently as possible, so deliver sort of the lowest cost of ownership by only delivering what you need or to making it wherever we can–making it pervasive so that it pops up wherever you want it in whatever business process you’re doing and whatever client you’re using so that it’s just part–you know, so we’re not basically interrupting what you’re doing so you have to go to a silo to do something, which is the conventional way of doing compliance. So just manage your place, make it smooth, make it just as simple as possible for the end user, but make it so the end users don’t even know it’s happening which is what we’re doing with things like EX where–EX is something in the background. The users don’t even know this stuff is going on. They have no idea what happened, but we’re being compliant without affecting the users. I think that’s the most important thing we can do to make compliance successful.

Blue Fish: Just to shift a bit over to DCM for a moment, because you’ve talked a little bit about what’s new in 5.3 and a little bit about the product roadmap for 5.4 and perhaps 6.

Mark Arbour: Sure. Sure. Well for 5.3–the main thing we’ve done there is added–it’s basically the first time that we’ve had DCM aligned with the latest stack release for a couple of years. In January of this year we decided to beef up our investment in our DCM product in life sciences, so we’ve increased the number of engineers and the number of QA people, so our focus for 5.3 was really on stack alignment, quality improvement, scalability improvement. We did a bunch of scalability RAS [phonetic]. There’s a thing called reliability testing that we did with DCM and actually DCM is the first kind of known platform out that it’s done on. So that was kind of the main thing we were targeting for 5.3 is scalability, reliability, QA enhancements. We’ve also added integration because we moved to 5.3 stack. We now have ability to integrate with compliance DCE. We have the ability to use BPM–the workflow capabilities and workflow stuff. So that was really the key focus of the 5.3 release. Going forward in 5.4 there’s a bunch of things we’re going to do to add features. This is where we’re starting to push some of those control content capabilities down into lower levels of the stack–BOF layers and such. Have published interfaces so people can access them without–right now DCM–most of the logic is embedded in the client. It’s basically in that gooey level, so in 5.4 we’re pushing that down. We’re actually working to integrate the DSM and DCM components more tightly. We’re looking at being able to expose control content through other clients and that’s really kind of what we’re focusing on is to get that control capability available throughout the stack. I don’t know if you’ll add anything to that.

Andrew Chapman: Yeah. BPM was a big change. I mean the ability to use BPM to manage the process of moving through the lifecycle states gives us so much flexibility just–again, straight out of the box, but no–I agree with what Mark is saying. It’s almost not about what’s happening to DCM and just to be clear, we imagine DCM will always exist as a solution. It’s just it won’t be a monolithic client anymore. So it’s about moving that functionality and we’re trying not to look at it as being DCM’s functionality, because it’s common to so many internal, external compliance solutions, so we’re looking at moving that compliance functionality down into the stack and improving DCM at the same time and the first thing we’ll do is we’ll basically start re-engineering DCM while starting the new functionality so that it can be more easily moved into the stack and it becomes a little more of applicable framework.

Blue Fish: So you’ve got DCM, you’ve got other aspects of the compliance stack in Documentum. Legato addresses email archiving for example. Are there plans perhaps with 6 to offer a single unified compliance offering that integrates maybe other EMC components like Legato into a single stack as maybe an option that people can buy?

Andrew Chapman: Yeah. That’s way before 6. We’re talking about Q1 of next year having–so E5–actually it’s not called that. It’s called Enterprise–it’s EASE isn’t it for email enterprise archiving–

Mark Arbour: Enterprise Archiving I think for mail solutions or something.

Andrew Chapman: There’s a new name for E5. There’s a real name for E5, so E5 which is the new release of the X–for instance, which is I believe Q1 or Q2?

Mark Arbour: Yeah Q1.

Andrew Chapman: Q1 of next year. It will actually be built on top of Retention Policy Services, so Retention Policy Services is the retention engine for all the ST products. So we have Retention Policy Services which is a product and will remain a product on its own and when E5 is released, E5 will obviously apply retention policies to emails. It will use RPS as its retention policy engine when RMU, the new version of the RM product, is released in Q1–Q2 of next year. It will also use RPS for its retention policies, so actually we’re not waiting for version 6 or even 5.4. We’re looking right now at trying to bring all of the products together so that we’re using this compliance functionality out of the box.

Mark Arbour: And we’ll have integration with–you mentioned other divisions within EMC, so Legato with their email being built on top of the Documentum repository is this end of Q1 release. So what that will mean is that all your email capabilities will be tightly coupled with your collaboration, with your retention–all that. We also have integration with Centera from a storage perspective, right? So the policies you define in Documentum apply on the Centera storage. We have a product called Content Storage Services–CSS and so what that allows you to do is based on retention policies move content to the proper tiered storage so that if contents in a certain stage of its lifecycle and it’s used a lot–you’ll want it on high speed, quick access storage when it hits a certain gait and maybe a project has been completed you might want to move it to near to line of offline or some kind of lower cost storage. So that’s a way that we’re integrating across the different EMC technology stacks. And again, that’s all going to be–the course is to have everything unified on the Documentum platform and then from there we’re building hooks into Centera’s and Legato’s. Yeah, so we’re moving that way pretty aggressively.

Andrew Chapman: And there’s already plan–there’s integrations into quite a few of the other products that are on the table that we probably can’t announce yet, so there’s a lot of work going around.

Blue Fish: Stay tuned?

Andrew Chapman: Stay tuned.

Blue Fish: Is there one or maybe two clients that you guys know of that you look to–Documentum customers that use the compliance stack in some shape or form that you point to and you go, those guys really have it together, they’re ahead of the game, they know what they’re doing. Are there any that you can–

Andrew Chapman: Don’t answer the question. That’s a loaded question.

Blue Fish: Are there any that you think that really have their act together?

Andrew Chapman: I would say that when I look at the life sciences area, we have a Life Science Advisory Council which is basically a steering council. The guys that have handled life sciences advisory council I would say all have their–I’m not just saying it, but they all really do all have their acts together. They know our products in and out. They’re particularly–in this particular case they’re DCM users rather than RM (Records Manager) users, but no–I mean I would say those guys pretty much all have their act together. They have to. We’re talking about huge amounts of money being invested in–in this case in DCM.

Mark Arbour: Yeah. In fact, a lot of them we pick for the Life Science Advisory Council, because we know that they deploy successfully and they’re the ones giving us innovative ideas on, hey if you did this to your product or you did this with your combined consulting services and product and we get much broader adoption. So yeah, so we have that group that we work with. Like I said, every quarter we meet with them and get good feedback. Our Global Industry Group–you know, John Hanrahan–do you know John? But yeah, I think he interacts with these guys all the time and he’s always giving us daily feedback on, hey guys here’s something you should think of, here’s something you should consider. So I think he’s pegged those key customers and we work with them pretty closely.

Blue Fish: Are there industries that you guys look at where you’re like, they’re way behind or they could really benefit from–

Andrew Chapman: It’s interesting–I mean I wouldn’t say they were behind. I would say that typically your large pharmaceuticals are way ahead, but that’s because they’re being forced to be. I mean the FDA–even medical devices are behind the large pharmaceuticals. These guys are way ahead of everybody else when it comes to compliance, because they’ve been subject to compliance for so long and such rigorous compliance, so those guys are definitely way ahead. Other industries–medical devices, financial–you know, they’re not far behind. I guess it’s in more traditional industries perhaps–process.

Mark Arbour: Yeah. I think it’s the people that don’t have to adopt it. Yeah, like probably high tech manufacturing. They’re probably not as far along.

Andrew Chapman: just because they’re not under so many–scrutiny–

Mark Arbour: So many controls.

Andrew Chapman: Exactly.

Mark Arbour: Yeah.

Andrew Chapman: So no one does this to themselves for fun and you can quote me on that. That was one of the top ten things that–did you see the key note this morning?

Blue Fish: No.

Andrew Chapman: That was your first key note. They did the top ten reasons why you buy Documentum and one of them was just for the sheer fun of installing it.

Blue Fish: What size team are you putting on all this?

Mark Arbour: We have–the Compliance Group in Ottawa is about maybe 25 people and these are people that are specifically building DCM, DSM, RM and then we have our whole engineering team across Documentum–probably I think around 500 now with engineering products, so what I do find coming from a small–I came from Bulldog where we used to have to build everything ourselves, so Bulldog–our engineering team was about 40 people and we built Digital Asset Management, but we had to build all the security, all of the workflow, all of the UI, certify on all the platforms and all that kind of stuff, so these 40 people–you really had like four building–with Rich Media capabilities. Everybody else was just trying to keep things running, so with Documentum we have this team of twenty–25 people that are working on stuff, but really everything is done in the platform–not everything, but a high percentage that we can leverage. So for instance BPS is a good example. We’re investing on a team for BPS is 4.15 people building out workflow capabilities–everything BPM and everything that’s done there–

Andrew Chapman: And TCS (Trusted Content Services). We get–

Mark Arbour: Or TCS same thing.

Andrew Chapman: TCS gives the digital writing and encryption. We don’t have to write that. It comes from TCS, which is the platform group.

Mark Arbour: Right, so this is where if I kind of look at–if people that are retention–building features that are applicable to our compliance customers, it’s probably half the engineering team. It might be 250 people that are building things that we can leverage, so whether it’s we just produced a whole bunch of enhanced supports that we call MACL–this TCS digital Shredding. All of our workflow enhancements. We leverage all of that stuff. We’re doing some stuff now–some proof of concepts on something called Electronic Trial Master Files and we’re leveraging all of the collaboration work that’s being done on that solution, so when I kind of see what I was like before when I had to get 30 people just to certify on an Oracle database or something weird or an app server and now I get all that for free, so I think that I kind of said, everything is being built. How much can applied to compliance? It’s a high percentage. So the virtual team is very large.

Blue Fish: When someone is setting out to establish a degree of formality in a process especially when you’re now talking larger than just DCM or all the applications already exist, what is your vision for how someone would set about doing that with–you’ve now got a set of parameters in the platform, but there is no place to go, there is no place to start. You’re really starting with a blank piece of paper. How would you do it?

Andrew Chapman: Creativity must start on a blank piece of paper and again, this is where it’s a little bit easier for us in the compliance world. So you never start it with a blank piece of paper. It’s not that some visionary says, wow let’s create a compliance problem for ourselves. Typically someone comes along and says, you’ve got a compliance problem and here’s what you need to do about it. So we actually start with a very well defined set of requirements. We have to make this immutable. When it’s deleted it has to be expunged and removed from all backup tapes. You can do reduction in this country, but you can’t do reduction in that country. You’ve got a very well defined set of requirements and then actually it’s very simple. So you’ve got a set of requirements, we have a set of functionality within the core platform and within all the services that we have within compliance and basically as long as we make sure all those things work together, as long as you can put together a process flow, which obviously we manage extremely well in Documentum, then all you need to do is basically plug the pieces into the process flow and there’s your solution. It’s never quite as simple as that, but it’s a lot simpler than in a more sort of visionary kind of thing where let’s try and rationalize this problem that we didn’t even know we had in the first place and try and build a solution. That’s not how it is. You typically start with, forget the fluff, let’s just deal with the actual problem that’s going to get us into core or it’s going to cause us problems. So let’s deal with those issues and typically that’s what people are looking for. They’re actually not looking for the fluff. They’re looking for the–deal with these problems so that we know that it’s dealt with and we know that it’s secure, that we have confidence in the solution. Obviously again, this is what the Documentum stack bring to us is if we say something is immutable, we’re pretty confident that’s immutable. We don’t have to worry about–as Mark said, if you have to write all this yourself how to you actually make it immutable? That’s handed to us on a plate and we build that functionality on top of that.

Blue Fish: At some point you mentioned that you had intentions to make foundations easier. What is your vision for how you’re going to do that?

Mark Arbour: Well one of the things we’re doing–I don’t know if you guys have heard of this thing called WDK Bootstrap. It’s something we’re building right now, but essentially it’s building unit tests and specific feature proof into each WDK component so that you can say, well here’s what this component’s supposed to do, here’s the test we ran against it to prove it did it. We can provide those to our customers to say–and we haven’t done this in the past, right? And so say for each component we can show these are the tests we ran against that component to prove that it does what we say it’s going to do and that’s a big one that we’re–I think the first kind official release of that is going to be probably late Q1 or early Q2. We’re planning on having it really baked and fully deployed in 5.4 which is about a year away. But that’s one of the initiatives that we took on–it will be three or four months ago to say that this is a problem–a problem that we hear all the time from our life sciences customers is, we don’t have an easy way to have you guys tell us this is what we are supposed to do, prove that it does it so I don’t have to do all that testing myself. So that’s one thing that we’re doing. We think it’s going to help a lot. The other thing we’re trying to do is package up validation scripts with–we’re talking about 5.4 release of our product, but package the IQ scripts with the product when we ship it, so at least people have a starting point that they can work with and think that will save them some effort–some time. Those are kind of the two main initiatives and I don’t know if there’s anything else that–

Andrew Chapman: Yeah. For the packaging what we can do is instead of delivering an empty box, so here is all the functionality but basically no configuration. We would really deliver a standard configuration and then either we or our partners can deliver validation scripts based around that standard configuration. Then all we need to–well it’s not a minimal touch, but all we need to do is every time we release a new version of the product is that we test that it does work under the same conditions with that same standard set of configuration. Another thing that we’re trying to do, which is actually quite difficult for us and possibly it’s further down the line is for us to produce basically Diff’s, so what has changed in whatever piece of code and that’s actually quite difficult for us to do because of the stack architecture. It’s not one thing that we’re saying here’s what’s changed exactly in that component, but if we can provide some more guidance on what has changed so people know what to validate because that’s what’s changed. So there’s quite a lot we can do and whatever we can do is actually a huge help for our customers–I mean enormous.

Blue Fish: It sounds as though it’s a much brighter future–it’s a better place to be in the new release. We know any number of clients who are investing heavily and moving into DCM now. How are they going to get there from here?

Andrew Chapman: Get where from here?

Blue Fish: To the bright new future–the DCM installation right now.

Andrew Chapman: Yeah. It’s a good question and I came across a partner yesterday who had the same concern was, are we going to re-engineer DCM to the point where people are going to be left high and dry? And that’s really not what we’re aiming to do. We’re aiming to take DCM as it is today. DCM is already a set of modules, so the modules only co-exist. You can’t take one module and use it on its own, so what we want to do is we want to basically fracture it a little bit so that you can take any module and you can just swap it out and put your own in enhance sort of thing in if you wanted or you could take out the enhance sourcing and use it somewhere else. We always imagine that DCM will exist as a solution that we provide, that we test, that we QA, that we provide migration scripts for. Just because we’re taking the functionality and making it available elsewhere doesn’t mean we’re going to rob part of that compliance type solution whether it’s called DCM or not. That absolutely has to remain. That’s very popular, very well respected. When people validate something against Chapter 11–that Part 11 they see it’s DCM and they’re sort of half way home already, because everyone knows it’s DCM. So no, we’re never going to remove the concept of having a solution that solves these problems. It’s our bread and butter and we’ll always provide migration scripts to get there. What we’re suggesting is though that functionality is too useful to only use in DCM. It should be available elsewhere. When we look at the records management model, the Unified Records Manager is exactly the same model. Unified Records Manager that we talk about as a single thing is actually thirteen modules some of which already exist–RPS, notification, reporting. These things already exist. Digital threading comes from TCS, so it’s not like we’re writing all thirteen of them, but when we release RMU what we’re actually doing is we’re saying we’re going to write the pieces that they’re missing, pull them together with the pieces that already exist. It’s about a 50/50 mix and producing a solution that is the unified RM solution. That’s not to say that we want to also make those pieces of functionality available as they are today. You can use digital threading today without using anything else. You can use RPS today without using anything else and that’s the model is still provide solutions, but provide solutions based on modules that can also be used elsewhere. And that doesn’t just give you modules that you can use elsewhere. What it gives you is it gives you a single system that you can deploy in a company, but only expose certain pieces. So let’s say you set all your retention policies up using RM unified. If you set it up properly you could just expose RPS to one part of the company. You’re actually still using the same system. You’re still using the same retention policies. It’s still a single set of audit trails. You can still do expungement in one place. You can still move content between one set of servers, but one part of the company is only seeing one part of the iceberg effectively which produces the total cost of ownership tremendously. You don’t have to deploy the whole monolithic solution out to everybody if they don’t need it. It works for us and it really works for the customers.

Blue Fish: When you talk about putting everything down in the platform and coming up with sample apps–they’re way more than sample apps but it’s–…are you then going to actively propagate the information as to how to craft your own vertical application for compliance?

Andrew Chapman: Sure. One of things that we’re dedicated to doing is making APIs open and so RPS–although the APIs have already been there in the next–they’ll be fully documented and fully supported. So yes, so enabling partners and customers to use this functionality is a huge part of what will make it successful.

Blue Fish: Is that the level of support there will be? It will be the APIs or do you envision having a support structure within your organization whereby partners, clients and whatever can come and get knowledge as well as just reading the APIs?

Andrew Chapman: Well we do have that now. We have Developer Support right now so you can go to Developer Support and they will give you advice on how to craft an application based on the knowledge that we have. For partners there’s the DFD program–the Design for Documentum Program who will sit down with you and give you lessons learned and best advice on how to link the pieces together. So that actually exists today, but I can’t comment on the future.

Mark Arbour: Yeah. I don’t think from an engineering perspective we’re going to create kind of solution models. We’re going to create a sample of one application and more than a sample and support of that, but one application that we build that would be a starting point for people. But then we’re going to rely on some of these organizations like Design for Documentum and other existing developer accomplished groups and our SIs to help with customers to craft custom uses.

Andrew Chapman: Right.

Mark Arbour: So that’s kind of where we’re headed, but yeah, within engineering really we’re looking at building a core product, publishing the APIs, doing it in a modular fashion so that it’s easier to deploy and upgrade and from there we have a real partnering ecosystem that can kind of help people do the–

Blue Fish: Okay Mark, Andrew–thank you for you time.

Mark Arbour: Okay.

Blue Fish: Thanks very much guys.