Download the Audio Interview (17MBytes)

Mark Arbour

The Challenges of Compliance: Mark Arbour and Andrew Chapman

Mark Arbour is General Manager of two of EMC|Documentum’s product
business units – Rich Media and Compliance. The Rich Media
business unit adds Digital Asset Management capabilities to
Documentum’s Enterprise Content Management platform, and
focuses on intelligent handling of images, audio, video and
compound multimedia content. As General Manager, Mark is
involved in all aspects of the Rich Media and Compliance
Businesses including Product Strategy and Engineering,
Marketing, Customer Success and Sales enablement. Mark has been
with EMC|Documentum for 5 years. Overall, Mark has 20 years
experience designing, developing and deploying scalable
enterprise software, defining product and solution offerings and
implementing enterprise systems. Mark was Director of Product
Management for Digital Asset Management solutions at the Bulldog
Group. Prior to that, Mark spent 5 years at Baan, architecting
Enterprise Resource Planning solutions. He also has 10 years
experience as a software engineer and consultant, building and
implementing enterprise technologies with Electronic Data Systems
(EDS).

Andrew Chapman

The Challenges of Compliance: Mark Arbour and Andrew Chapman

With a Masters Degree in Computer Science and over eight years of
experience in developing Documentum-based applications, Andrew
Chapman is well versed in both the architectural and technical
details of the Documentum platform. Andrew manages the
compliance product group and is responsible for the strategic
direction of all things ‘compliant’ at Documentum. Prior to his
role in the compliance product group, Andrew was instrumental in
the creation of the Developer Program Web site and the Developer
Conference.

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.