Episode Transcript
Speaker 0 00:01 Thanks so much everybody for coming today. This is our third New York based symposium in the last, I don't know, six, eight months or so and we tend to record the panel session portions for the workflow show podcast that Chesapeake systems does, so bear with us while we get that manned. All right. I'm Nick gold. I'm the director of business development at Chesapeake systems. I know a good chunk of the people in this room and really appreciate you all coming out today. As I was saying, this is the third in our New York based symposium series on various aspects of digital media, technology and workflow and we wanted to do something a little differently today and we are going to be focusing on a couple of the men products. But this panel discussion is really to talk about the process of implementing ma'am both within your organization, kind of almost even from a cultural perspective and a change management perspective, the perspective of what you should know going into a man project and then talk also about the deeper level integration possibilities with media asset management as a technology because there's a lot of possibilities with this.
Speaker 0 01:14 It's probably the most complex technology platform, uh, and category that we work with. As an integrator. It's often the most challenging for clients and vendors and integrators to fully wrap our heads around. And so we thought this would be a great way of getting into some of the deeper subjects here. I'll do quick intros for everybody and at first of all, let me thank both the ACE hotel, our partner next sand, the storage vendor that Chesapeake systems does a ton of work with and loves and finds to be wonderful and reliable. They've been a big sponsor for this event today and thank you very much to our partners and I will introduce them all now. Greg Schiff, I've known for probably five, six years at least. Um, I've known through several incarnations at several of the storage vendors including active storage and quantum that Chesapeake has worked with over the years.
Speaker 0 02:10 And Greg, I learned when he came on board with levels beyond as kind of their East coast guy. I was like, this is awesome. This is a great spot for you. We've been working with him extensively again for many years now in several capacities. And now he is, is the East coast rep for reach engine. Mike Zemlinsky, I've known even for probably a few years longer. Mike, uh, has a storied history with a w. We first met when he was part of a rep firm called HD sales. Then was at Mac professionals awhile and other uh, Mac oriented systems integrator and they did some distribution stuff. And then Mike has come on board both with Canto and a few of the other vendors that we work with as their U S rep and distributors. So, um, Mike is basically the American face of Canto as well as archi at this point.
Speaker 0 02:59 For those of you who use any of the archi where software that's all coming from Mike and pro video tech. John FICO of access point is a developer that we came to know about a year, year and a half ago probably for the first time access point had done a number of projects with levels beyond but they are a across the board, you know, software contract, software development and integrator firm. And John is the lead developer there who has been in the trenches as much as anyone I know doing deeper level ma'am integrations between media and media, asset management platforms and some of the third party pieces of hardware and software and the ecosystems that these things tend to connect to. And so we wanted to have him on the panel today as a voice of, you know, the guy who actually has to do the coding to make all of these things talk with one another because that's an important part of all of this.
Speaker 0 03:54 I thought we would start by, you know, taking it from the get go. Again, some of the people in this room have already started going down the path of either implementing or at least exploring media asset management, but I'd like to get each of your take on what, what are the right things for an organization to have in the hand when they go down this road of media asset management, workflow automation, tying systems together. What is that checklist of things and organizations should know about itself and have ready for the vendors? They're talking to the integrators they're talking to that can kind of be, you know, key things that even their individual organizations, you know, can put their heads together around and have to kind of frame the entire project. Greg, what are your thoughts about that?
Speaker 1 04:42 The first thing is they have to be ready to embark on a, what's going to be a big change in the overall workflow of the organization, right? This isn't going to be, you know, coming from a storage background that I had previously. It was everybody touched the storage, but they didn't care. It was just the, the icon on the desktop that was there and worked in the background. And if the technology behind that change, it didn't really affect them. Whereas this impacts everybody who's touching the systems and often impacts the users more than the, the technology folks who are often the people that I'm having a conversation with. Right? And so you've got to get buy in from everyone that we're going to, things are going to change and you have to be prepared to do that because if you don't have that buy in then it will never happen.
Speaker 0 05:28 So it should even be the first thing on the list. Is that the mindset you need to be able to go through that change? Mike, maybe you can answer a little more specifically in terms of some of the, I mean even types of documentation and accounting of systems that a client ought to probably have maybe in hand is a file that they can give someone and explains what they have going on even. Yeah, I mean I think one of the biggest things I see is a lot of the people that come to us talk about media asset
Speaker 2 05:57 Management actually may not be aware of all of the different people touching all of the various systems in their existing facility. So you come in to solve one specific problem, but you don't follow the, the, the river flows from that waterfall out to actually see where all these end points are. And that can either create issues down the road because you've implemented something in a maybe nonlinear way that breaks something two stages outside or a, you know, you're just missing out on some of the value that you can have in the system because you're really just not looking far enough out. So I think a really important thing to have is, you know, a rough idea of what your infrastructure looks like before you even start to talk about it. Because without that in place, it's going to get uncovered, but it's going to be a much more time consuming endeavor and it's going to cost more, it's going to take longer.
Speaker 2 06:47 Um, so, you know, I like, I like drawing pictures on walls, you know, and things like that and actually connecting the dots and figuring out how many people are in each place and what they're doing and not be technological about it. I think really it's important to be very high level about that expectation and and speak to it not in the term of products or what's actually being used, but more along the human work that's being done in each of these locations and that can really aid in the speed of understanding and then make the implementation a lot cleaner.
Speaker 0 07:21 John, from your perspective, you know some of the people in this room have smaller infrastructures. Some of the people in this room are managing some of the larger media infrastructures on the planet. For everyone though you have a combination of legacy systems, you may have these ideas about, well I think I should be able to hook a ma'am into these other things. When looking at it from that deeper integration perspective, you know, bearing in mind that there's going to maybe have to be some, you know, specific, you know, development or customization or scripting. What about a customer's environment? Should they have any hand specifically with the idea of we want to tie these systems in. What are the right pieces of documentation that someone might bring to the table when they begin engaging with, with an integrator, with a vendor?
Speaker 3 08:08 Well, I'd like some documentation just from a developer point of view about how they're using these systems today. What are, how do they bring data into these systems? Are they going to continue to bring data into those systems? Um, and then what are the outputs? How do these things get used? I think one of the big challenges of bringing in a legacy system is where does that cut off happen? Is the plan to knife switch? Um, okay, we're just gonna take a weekend and bring everything from the legacy system into the new environment. People say they want to do that, but I've never seen that actually work. There's always some bleed over. There's always some project that's got to be finished Monday morning that they can't, you know, cut that off on the weekend. So we need the ability to say, well, let's think about a plan and even develop a plan together about how we're going to use these systems in parallel until you're from one side onto the other. Or maybe, you know, you don't bring anything new into the old system, but we give you the ability to, to index the assets from the news.
Speaker 0 09:14 That's right. I mean, you know, having these systems in place often really can dramatically change how someone might do their job in a various way. And you know, that the idea that there's an expectation where you're just gonna I like thinking of it as the Frankenstein lever, you know, it's alive, right? It's, it's a more nuanced process than that. You know, Greg, having been around a lot of these projects, is there something or a few things that you see that customers may be, are more often to get wrong when they go into these projects? Maybe it's assumptions that they've made that they probably shouldn't have made those assumptions about how these projects go, or the technologies or their capabilities. What are some of those things that you see again and again as like a, you know, we just, you know, what can we advertise is like, don't, don't do this this way or, and you'll have a better experience.
Speaker 1 10:05 Well, I think the, the, the two things that I see are kind of to touch on what, uh, John and Mike said, is that knowing what everybody's doing with the content that you're making, right? A lot of times there's a big disconnect there and it's, it's really frustrating when you're, you're, you're going down the line with a system. We're building a statement of work, we've got kind of an idea of how it's all gonna happen. And they're like, Oh yeah, by the way, we want to do this, this thing that totally changes, that has implications across the entire document, right? Oh, well actually we want to archive on ingest because we need to have an LTO copy here and Oh, wait a minute. And it sort of changes a lot of different things. So I think it's having that, and also we, I talked to customer like, Oh, this is a great system.
Speaker 1 10:48 We want to do it, we're going to implement it. And then, okay, what do you want to do with it? Well then they look for the vendor to tell them what to do with it, which always has me kind of scratching my head like what are you doing now? And they're like, well we want to implement best practices and what do you guys, what do you guys recommend for that? And yes, we do have a lot of opinions about that and there's things that we see over and over again, but it needs to be informed on the customer side and you've got to really have ideas about that.
Speaker 0 11:12 It is a little bit of an interesting strain in the dynamic between say a vendor or an integrator and the client. Because you know, from our point of view, I've seen this where you know, you're not quite sure if maybe the best thing to do is just say, just do it this way. Just do it this way. It'll be better. Trust us. But you, you still need to kind of have that dialogue to make sure that even from the integrator point of view, you're not going in with the wrong assumptions. So yeah, it's, you know, I think it is important for people to have a sense of what they want to do. Mike, without any, you know, direct implications or naming any names, can you think of, you know, a ma'am or, or, or workflow automation project that just had like something go wrong because of either an assumption that was made or an approach that really someone, you know, again assumed that that was the right way of going about things and it led to some issues. And what were, what were the ramifications of that?
Speaker 2 12:06 Well, I mean, the biggest thing I see is this assumption that a ma'am system just layers over on top of your existing workflows. Generally speaking, the modern ma'am system actually replaces and automates a lot of your existing workflows. So I cannot tell you how many conversations I've had with people that say, well, I've got my folder structure this way, so it's going to stay that way. Okay. Um, now you have multiple metrics to search for things. So where do you, where do you put the file that is for project one, two, three, four, but also has cloudy skies which, which folder does that go into? Stunned silence. I don't know. Are you going to duplicate it? You're gonna make two copies of it so you can walk through the file system and find that. The idea is that don't come to the table with the expectation that this thing is just like an indexer.
Speaker 2 12:52 If you just want an indexer, there are plenty of relatively inexpensive ways to to accomplish that. It's really, it's going to fundamentally change the way you find the media, bring the media in, catalog, index the media and what I like to say is forget about the file system because some of you guys that are in the bigger shops know that a file system itself is not a prerequisite for storage anymore. When you start to get into some of these larger storage systems like object storage, lattice and object matrix and so on, so forth. There is no file system, so the concept of a file system is really completely irrelevant other than for the entry and exit points from the system. That's a huge one that I see pretty regularly.
Speaker 0 13:34 Yeah, I think it's, it's interesting that people were, you know, sort of in a legacy way, we're encoding metadata into our file system, right? That's what it is. That's that whole hierarchical folder structure is, is metadata. Right, and hold on to that and getting people to say, wait, no, it doesn't matter. It's now we're actually going to do it the right way. John, think about a man project that you've had to do some development work on. Is there a hiccup with an integration? You had to do that. Again, without being too specific, you can just use as a frame of reference for, again, maybe an assumption that someone got wrong about how easy something would be to implement or the time it would take.
Speaker 3 14:11 I think the biggest hiccups typically occur. I mean there's, there's more than one side to implementing a map. You've got your it group that has a certain set of expectations. The creatives have a certain set of expectations. The librarians have a certain set of expectations and where it's gone wrong is where we've only gotten one of four, two of those side inputs before we start to develop. So you have, you know, you design two sides of this triangle and then the it group says, well no we don't have enough disk to keep everything online all the time. Well that's what the creative guys said they wanted. So there's a disconnect there and then you have to start working around, cause you're, you know, six, eight months into this project and you're finding it out then that that's, that becomes the issue where you could manage this a little better if you'd had the sort of like what we were saying before, if you had input from all three sides already and you could plan it out and this is how we're going to solve the problem, then I think that that can alleviate a lot of the, a lot of the hiccup
Speaker 0 15:15 And that's important. And you know, again, we deal with many different types of organizations. All of us do. And there are some where, you know it and the support of the creatives are very, you know, integrated. There's ones where the creatives and the people who have to support the creatives are very isolated from it. I think it, it helps to be realistic and know which type you are. Right. And again, we talked about getting buy in from the different stakeholders. Well, you know, at a certain point it is probably going to be involved unless you're on a completely isolated system. So you need to know in advance and be able to frankly convey, I think to the vendors that you're working with, you know, well here's, here's things we may run into. We don't have necessarily a great history of working with those guys. Or maybe it's, these guys are great, we work with them all the time.
Speaker 0 16:07 We want them to be involved from the get go. And there'll be very Frank with you about kind of their perspective from kind of the it world and it's meshed. But no, no what you are, one of the things, you know, speaking about kind of assumptions and where I think you know, hiccups can occur is again, as I said earlier, media asset management is by far and away the most complicated set of media technologies that we deal with. And it's a, it's such a broad phrase too, cause you know, I should probably define it cause that's another thing that confuses people. I think there's so many different phrases and pieces of terminology is something a ma'am, a dam, a Pam, you know, integrating these things, you know, knowing the vocabulary frankly, or at least making sure you're speaking the same vocabulary and have the same set of definitions for things is the vendors you're working with or the different people on your internal teams have kind of the same nomenclature at their disposal.
Speaker 0 17:01 Really, really critical. Um, but another thing is the phases of a project because this is such a complicated set of technologies. The possibilities are, I don't want to say endless, but you keep coming up with new use cases when going into a project or even standing up a new use case for media asset management. Greg, what would you say would be a good breakdown and way of framing out the phases of a project that you know, are combination of, you know, getting people what they want when they want it, but also kind of just being realistic about how these things tend to get adopted in an organization? Right. So when when we do deployments with reach engine, it is almost always a three phase kind of, right? The,
Speaker 1 17:50 The first phase is that discovery phase. And that is so important. It's what we've been talking about before, getting the stakeholders in the room. Everybody sits down, we talk about what the system, what they're doing now, what the system is going to do. We map out all of the asset management, the metadata schema if they have it, and start to talk about what processes we're going to automate. And then from that discovery meeting, I'm able to craft typically two different SRWs, right? There's a, uh, a phase one statement of work and that's usually pretty out of the box functionality. It's easy wins, it's stuff that's immediately gonna make people's lives better and not more complicated and is thing, you know, integrations that we've seen before typically. And then the second phase is, Hey, people have used it for a while. They're thinking inevitably changes about what they want to do.
Speaker 1 18:38 And it's typically a little more specialized. Okay. There's some scheduling tool that we've never seen before that these guys are using. And we want to have the man talk to it so that when a new job is made in the scheduling tool, it creates, um, a metadata framework for that within reach engine. And there's a, a landing pad for the content as it starts to come in. Um, so that's typically how it is. It's a couple of phases. It's several months typically to implement, but you have to, you've got to break it up that way. Excuse me. We, when we've tried to combine all of that into one big statement of work, it just doesn't, it, it, the projects drag on their scope creep people cause because the thinking changes while they're using the system, all of a sudden they want it to do all these things like, Oh we didn't talk about that, you know, six months ago.
Speaker 1 19:24 So having a pause in between the first and second phase is really allows for that creativity on the customer side. And also when we're getting in there to kind of see what, what new things we can do. Mike, can you speak a little bit more about what types of things a customer might get out of a, of a ma'am deployment in phase one, the things that are kind of those easy wins that again get the system in people's hands. So they're kind of their creativity about how they might do further development around that might go in phase two and then what are some of the types of things that might be a little aggressive for phase one and you might want to think about a little bit further down the path?
Speaker 2 20:06 Well, I mean I think I generally feel like if you have much more than one or two little custom workflows and phase one you're, you're biting off more than you can chew in general. Ma'am, systems are unique in this and we've said this three times, I think already today that users and you know, technicians are working in harmony with the ma'am system. There is a lot of automation happening in the backend and there's a lot of UI integration happening on the front end. There are people that are creative that have to use the thing a day in and day out. So making sure that that harmony is maintained. It means not trying to bite off more than you can chew and trying to replace too much of somebody's job with a new tool. I mean, if a new
Speaker 0 20:47 Ed who here has ever just switched overnight to a new editing platform, anyone and just said, you know what, final cut seven's gone. We're just, tomorrow we're cutting rid of it and we're switching over to something new. It doesn't happen. So don't have that expectation with something that is arguably bigger and touches more people than what your, you know, your, some of your core tools are. So I think really on that first phase, it's really defining an organizational scheme on taxonomy. And I think we'll talk about that a little bit more, um, later. But having that and then kind of mapping your end points and your outpoints, where do you want this thing? Where do you want stuff to come in? Who do you want stuff to go out to and how do we organize it and not try to get too much more in depth than that on on a phase one approach. Because once that workflow is settled and in place, the customization becomes relatively easy because you've got full-scale buy in and everybody understands some of the capabilities of the system already to make intelligent suggestions. I can't tell you how many phone calls I've been on where somebody makes a suggestion, like I'd really love it if you know this thing could birth a new unicorn for me. And the reality is it just can't do that. And our product does do that.
Speaker 0 21:58 Now with unicorn horn, John, every vendor wants to close deals, right? Of course we all want to sell more ma'am systems and sometimes I find the customers, the clients are very aggressive about trying to get the deals closed as well. They're like, no, no, no. We need to be able to execute this. You know, thing that's going to completely transform our entire organization potentially, or maybe over time, but we've got to close the deal. Like, you know, in a week because you know funding period is coming from him and sometimes those are the realities on the ground, right? Everyone potentially has a budget windows and things like that. We've talked a little bit about how to phase out the implementation, but being a guy who actually has to make a lot of this stuff work, what might you say to like the actual phase one, which is before you've even cut a deal, like what should a customer, who's, who's thinking about this thinking about integrations that they might want to take place, do in that pre sales phase with the vendor or vendors that they're working with? That again sometimes gets glossed through, you know, what are those things that would make your life as the guy writing the code easier if more time had been spent before a deal was executed?
Speaker 3 23:15 Well, the two biggest things that are more difficult to change after the fact, let's say it that way, metadata is key. So defining what metadata you want, not just what metadata, not just a scheme in all the taxonomy and where you want to store it, but at what point does that metadata get associated with your assets? You know, when we do ingestion workflows, one of the powers of that ingestion workflow is forcing the system or the user or whoever's putting the asset into the system to provide some minimum level of metadata because you're going to have to be able to find this thing later. So that's on the inbound side. On the outbound side is how long do you want this asset to live in its various stages? How long is it going to be on spinning disk? Where's it going to get put to tape?
Speaker 3 24:02 How many copies? Not necessarily how many copies. I don't need that phase one, but I need to know whether I have to put metadata on this object on ingestion to say, I'm using this object right now. Don't take it off tape, right? If, if now you're six months in and we're doing phase two and you've decided now you want this crazy archival scheme that relies on data that I should have put on that asset six months ago, now I've got a bigger problem. Now I've got to do some kind of update scripts or, or um, some kind of fancy stuff.
Speaker 0 24:36 And you know, one of the things that I think is a little, and we're going to have questions and answers right at the end of the panel discussion. So hold them tight, make a mental note of them and then we'll just kind of hit them rapid fire, uh, when we're done yammering on. Um, you know, it's funny, you know, media asset management quotes, not necessarily the scopes of work, but the quotes themselves I think are often misleadingly simple, right? You might have a server or several, so there's a few hardware boxes. You might have a software license on it. You might have an annual support and maintenance fee may sometimes that's a bundled with the first year of the software purchase. Sometimes it's a separate line item. And then you've got like pro services, which yes is a scope, but you know what you're saying about a lot goes into that.
Speaker 0 25:27 And the estimate of the cost of that is really based on nitty gritty specific things that taught you, you get into in presales. And so just to back up your point that the more specific you can communicate what your goals are and what you really expect out of that lump of labor, um, with the vendors before executing a contract or sending a purchase order is better. And you're, one of the things I find, you know, sometimes when you're not having to do the integrations yourself and you're working with partners, which is of course we all think a wonderful way to do it, but, um, you know, you may make an assumption about, you know, well, okay, maybe we didn't quite specifically describe that, but we want to just do, it's a little tweak, you know, it shouldn't really affect anything. And I mean as you know sometimes what seems like a really little tweak can be like, Oh well that's an extra week of work to do that extra development work because you didn't say you wanted to do it that way and this can lead to some strained relations at times when people are like, guys, this isn't what we talked about and you're going to need to pay us more to do that and so again, being as nitty gritty before even closing the deal, thinking of the presales conversation as a very legitimate phase in the process I think is a really, really important one.
Speaker 0 26:51 Guys, what are questions that you think are the right ones for customers to be asking of their vendors? You know, what are the things that they want to put out there? What are the things you know that you want them to be asking you about as they're evaluating a platform? Again, this is pretty complicated stuff. I find that usually the clients, the customers who ask some of the best, some of the toughest and the most nuanced questions are the ones that we have the most success with because they hit us with the nitty gritty stuff ahead of time. So there were less surprises all around. Can you Greg throw out some good questions that you think people should be hitting, whether it's the integrator, whether it's the software development company that makes the products, you know, what are the ones that you kind of like, guys shouldn't you have asked me about X, Y and Z?
Speaker 0 27:43 Cause it seems like you're making some serious assumptions if you haven't asked me about this stuff. I think it's to hit on what we talked about before. How is data getting out of the system, right? How are we going to do this? How are we going to do the delivery? How do you do that? Where is it going? And you know who defines that, right? I think that's, I mean sometimes it's really basic to like, you know, we find ourselves in the position of, you know, we're implementing a system and you know, when we talk about ingesting and ma'ams, obviously that's sometimes the ingesting of files and moving them onto a new file system. But sometimes that's just kind of making the database aware of them. And there's some really basic things that we probably deserve to get into more depth on. Like how do things show up in the ma'am database?
Speaker 0 28:30 What gets them there? What is the, do I drag it into a folder? Is there a user interface? What does that user interface look like? But I mean, people often don't even really dwell on that ahead of time and they're like, Oh yeah. So that's how it gets in there. I think there's, there's that. And the other one is, is if you have some specific file types with weird requirements, maybe not even weird, right? Or we have multi-track audio, we've got these embedded subtitles. I don't know, the subtitles actually live on some external file and we need to make these two. And so to kind of ask us how do we actually deal with the specific files that you're working with? Because as we know in the, in the video space, there's a lot of diversity there about how file, what, what can read, what and how data is associated with it.
Speaker 0 29:13 And it can be, you know, there's things that we do well and things we well especially well, a lot of the non flat file formats that often come off of cameras and tapeless workflows, they can be difficult for a man to work with. And I think about that, that's the where when we were deep into it and I'm like, Oh we just assumed you handled those kinds of files because that's the kind of file I live with. So I assume that it's a standard thing that everyone's using and we're like, Oh, we've never seen that before. And the universe, cause you're the only one doing it. And dot, dot, dot, dot, dot.
Speaker 2 29:42 And they're like, Oh well that's kind of a deal breaker. Like where it's a little late for that. So Mike, what are questions that you think are the right ones for people to be asking? You know, presales, you know, going into a project, you know, identifying if not which vendor they're going to go with, you know, how they're going to do their implementation strategy. Well, I think honestly there are a few business level questions that often get just completely glanced over what is the longterm cost of putting the solution in place. Yeah, it's a, you cut a PO, you get some stuff, gets all done and then it's been a year. Does it cost you more next year? Does it not cost you more next year? Do you have to spend that money? Do you not have to spend that money? What's your longterm goal for the system?
Speaker 2 30:26 What's the scalability level on the system? How much does it cost to scale that system? You know, these are the sorts of things that if you don't know upfront, you get what I like to call the golden handcuffs, right? You spend a lot of money up front and now you're stuck spending money in the future potentially because you didn't look at it across a three year, five year, seven year tenure, you know, depending on your use case, if you're looking at a ma'am system to be the front end for your archive, how long has your archive data valuable for? So how long should you be looking at ROI into the future for the cost of that ma'am system. If the, if your answer is only three years, well guess what? Throw them on. Let's see. Hard drives on the shelf. Cause guess that's going to be a whole lot cheaper than putting in a full on ma'am system.
Speaker 2 31:05 But if it's, I want to keep this stuff for 10 years. Okay, what's the migration strategy? How has this thing handled multiple different types of storage's because in five years the storage you have right now is definitely not going to be what you want to be running it on. And is that methodology for talking to storage even going to be viable? I mean, I like to think back to five years ago he were here, had even heard of rest capable storage and was using, you know, object based storage for distribution. And now it's, it's actually fairly common and it's becoming a usable workflow. So I think that's something that oftentimes gets missed. Everybody looks at the very granular, what's my budget right now to get this project done that I've got very specific on it. They don't think about the longterm. And if you don't think about the longterm, it becomes very difficult to actually plan a longterm strategy. John, what questions from a developer perspective would you want people to be asking? What, what clarification's would you actually feel good about if they were seeking them from you? You know, ahead of you supposedly making these wonderful things happen. Maybe even get somewhat specific about, you know, development work you've had to do that maybe someone has, you know, again, didn't ask quite the right question.
Speaker 3 32:19 Well it, it's kind of funny. It's when I was, when I was getting married, somebody told me that everybody, you know, bride groom would always have one thing that they care more about than anything else and I sort of want to know when I'm, when I'm in the beginnings of an implementation, what's your one or two things that you care about more than anything else? Because I've had cases where that's I want to pull metadata from a third party system. Well, all right. That's going to, that's going to take some, some figuring out potentially, depending on what that system is, you know, real time updates and things of that nature. If it's, I want to maximize uptime, if it's, I want to maximize my storage efficiency so that I could save money on disk. What are the things that are really, really important to the way that you do business? Because then I can try to figure out whether we're good at that or not good at that. Because in some cases the answer is you're not going to be able to get there with what I've got. Or you may be able to get there in six months.
Speaker 0 33:20 You, you spoke to the figuring out and you know this is an interesting dynamic of these types of projects. You may be XYZ customer and you use ABC vendors archive solution, which of course has its own software layer, its own database, uses its own formats, may or may not have its own API APIs for communicating with third party software. And I think there's this, again an interesting dynamic here between that. Let's say it's a a something you've never done an integration for. You know Frank's archive system. You're going to have to do figuring out to figure out how we are going to hook into it. How do we get things from the ma'am into it? Is there any interesting data we can then extract out of it to bring back into the ma'am like a tape of barcode number or label name or something like that.
Speaker 0 34:14 How do we initiate the restore? You know, I'm curious just that act of figuring out how to make it happen is consulting. That's, that's work. And I think, you know, there's this interesting dynamic too where we often have to kind of make guesses presales. About how long it might take just to do that. Figuring out phase and we don't want to like just give away all of that because that's real legitimate consulting. We're figuring out, we're getting documentation, we're pouring through it, we're learning some new API APIs. Have you found that there's a resistance to paying for even some of that discovery phase so you can be even more effective and more efficient when it's time to actually roll it out and do the integrations?
Speaker 3 35:01 Um, I don't know if I've seen a resistance to the business front end of it cause I usually come in after that, but my, my gut is that we try to build that in to the originalists or w which is why I need to know if you are using Frank's tape drive system or you're using something I've already implemented with. The other challenge is how do I test this? I don't have a Frank's tape drive system on my sixth Avenue office. Right? How do I play with this? Do I, do I get a development area on your tape drive in? Am I doing essentially development in shop
Speaker 1 35:38 To make that all work? And sometimes the answer to that is yes and sometimes it's, well we've done this before so we know these plugins work. Just configure them and they go, Greg, maybe you can kind of speak to that as well. I mean well you know sometimes things you have to kind of play with and massage to get them fully baked to work. It is often a little bit of a discovery process for us on our side as well to just make sure we're figuring out how to get it to work. We I think generally execute these things very well. I wouldn't be in a room with you guys right now doing this if I didn't think you know, you, you guys stood behind what you said you were going to do, but what can you say to just again, setting the proper set of expectations on the client side as to like what level of finagling and tweaking kind of once the system has even kind of rolled out should be expected.
Speaker 1 36:29 Because again, it can be hard to really frame out the whole thing in a lab. I think to speak to a little bit what you said before, we definitely see pushback for customers wanting to to pay for that discovery process. They'll be like, Oh well then you know, just do the whole thing as a proof of concept and then you know, after the proof of concept we'll decide whether or not we want to buy it and or, or they'll say, well you should be doing that anyway. So do it. Not realizing that their system is, everybody's system is unique and you know, there are some things that you see over and over again. Okay, yeah, we're talking to a, a store next sand on next SanDisk and okay, but that's pretty straight ahead. But all the other things, there is a lot of this, this, you have to have appetite for that.
Speaker 1 37:11 If you want to get the most ROI out of your ma'am system, you have to be willing to have a partner, have a developer that's going to work with you to build your snowflake, right? Because a lot of times it is a snowflake and so there has to be appetite for it and there really should be budget for it and if you're not willing to put the budget behind it or have the appetite to work with something that might not work at first it's going to, we're going to have to test it and massage it. You're going to limit yourself, right? Because then you're going to just get a product that does the few things that every everybody does and it doesn't necessarily meet your specific business logic for what you want to do. Like what do you think about the idea of pilot programs even even if you've committed to make a purchase, but just the idea that once this tech is stood up, we might not, we might deliberately hold it back from everyone. We might have a few kind of test users. Maybe there's some of the more advanced users. Do you think that's an appropriate way of going about this? Do you think that leads to better outcomes?
Speaker 2 38:10 Well, absolutely. I mean the, when I talked to like workflows and functionality that you know, the product can do out of the gate, I have two, two kinds of statements. Yup. We can do that or fear radically we can do that. And the second one comes with the caveat that costs money, right? Because somebody is going to have to figure it out. Yes we have an API. Yes they have an API. Yes. In theory they will talk cleanly because we understand the fundamentals of both of them. Have we ever actually done it? No, we haven't. You're going to be the first one and if you're okay with that, then you know there's no issue there. But if you're not okay with that, you know it's and, and it's a, it's a very interesting dynamic at that point because you know, if you're going to sit around and wait for somebody else to be the first one to do it, you may never actually get it because like Greg said, he used the snowflake term.
Speaker 2 39:01 I use that all the time. Not a single person in this room is going to have the same schema or design or storage infrastructure or backend ma'am systems layer on top of your business units. They don't layer on top of your software applications. So while yes, you may be using avid and you may be using a ma'am, the way you use it and the way you pipe it from one site to the next site and the people that use it is completely different from anybody else. So the expectation that you know, a truly vetted ma'am system can do everything out of the box is kind of a false reality. You know. And from a sales perspective, our marketing slides meant are meant to say yes we can do everything because in theory we can do everything, but there are realities to a lot of those situations. And if the functionality is there and you're willing to take the time to dive into it with us, then we'll go down that path. But it's definitely a, with that differential in place, it's very difficult to even say up front how much time something might take in certain cases.
Speaker 0 40:04 Yeah. Is there any key vocabulary that you wish every client and every vendor were completely on the same page with? Are there ways, you know, we were geeks for this, you know, three of us went out the other night and we probably spent half the night talking about media asset management systems. Cause that's how we roll and, but, but you know, that can lead to maybe, you know, sometimes, uh, taking for granted some of the complexity in these things. You know, we even use the word metadata, we talk about schema schemas, you know, to us that means something pretty specific. Right? You know, sometimes we, we, we, we, we've been talking about like the ontological approach of organizing your information and like suddenly we're just frankly not having, I think of frankly good conversation with the customer. There's, there's ways of getting them on the page. I mean, are there terms, phrases, way of thinking about things, but there's the the meaning of the actual words we use when we're describing these systems that you know would be good for people to be on the same page of,
Speaker 2 41:09 I think the number one is taxonomy, right? That's when you really get into mom's systems. Taxonomy is key. Your metadata now becomes your ability to search for things and your metadata is your business. It's not ours. So when I, again, I can't tell you how many times somebody has been like, so what fields should I use? I don't know. You know, I'm pretty, UNICEF and MTV have different fields to look up things within their systems and have different metrics for what is important and searchable. So I can't even begin to tell you how to define that. I can share with you ways people have implemented certain field types and the way that they have used the system, but the actual overarching taxonomy, which is the terms that the schema that you're using, when that's available, who it's available to take, it takes it. It's upper level, it's above the technology itself.
Speaker 2 42:03 It's really more at the business unit level and trying to understand how you locate things, find things and and above and beyond that there's really two different types of metadata you have what I would consider physical metadata, things that describe content and then there is functional metadata things that trigger automations and moves and triggers and various different things and they're two very different things. So you know that schema is interspersed in most cases. So I think that's like the single most important thing when you're going into a ma'am discussion. If you haven't had an internal discussion already about what your taxonomy is going to look like when that guy shows up and he's like, yep, systems installed, let's start building the schema and you guys just, the jaw drops and you don't know what's going on, it's wasted dollars at that point.
Speaker 0 42:51 Greg. A lot of organizations, okay, they may have some organizational systems that they've developed over time. They may even have key words that they've used, you know, deliberately in their project file formats when doing sub clipping or you know, naming conventions of folders and things like that. Which as you said earlier, are kind of that first level metadata that people have already been working with. But in your experience, how does an organization do the type of organizational level thinking that Mike was describing? Both in the words we use, I call it qualitative metadata. I actually think of three. There's like the intrinsic metadata. These are the formats of the files, the frame rate, the frame size, all of that stuff. There's the qualitative metadata that a human typically has to tag, uh, you know, in order to basically power search and organization. And then we a week, I call it process oriented metadata metadata that drives workflows, sets variables.
Speaker 0 43:50 If a workflow is, is doing its thing, it's drawing metadata values to tweak how that workflow is actually working. You know, this, this format is going to this delivery type. These people need a notification, all of that stuff. But I mean, Greg, how does an organization really go through that process? Who are the stakeholders who need to be involved with that? Who are the people in the organization who should be even part of the presales discussions in order to make sure that it's not just a jaw drop when you're like, okay, what tags do you want guys? Right. Well, I think the first thing to recognize is that it's hard, right? That's a real challenge. I think that's probably the biggest challenge of something like this. This is figuring that out. Especially
Speaker 1 44:32 If it, if it hasn't, you've never done it before. You've kind of done it in a ad hoc kind of piecemeal way. Right. And it's great if you have an organization that has a librarian or an archivist or someone who, who does this, that kind of thing for a living that can guide the process. But you know, pending that, I think it's, it's, you gotta have meetings that aren't meetings with your vendor, right? It's internal discussions within the organization and they can be informed somewhat. These, these are sort of parallel processes where we're talking about what's the, what's that phase one statement of work for the man and then that can help inform some of these other discussions about what some of these other metadata fields should be. Right. These, these sessions can inform each other but they, they need to be had separately and then brought together kind of at the end. And I think that that's, you know, where there are certainly consultants out there that can can help with that kind of thing. And there's, there's some value there. And then there's just value in bringing the people who are using the data on a day to day basis together to talk about what information they need.
Speaker 3 45:35 Especially the qualitative section. I mean I'm going to drive the, the, the process control metadata. I'm either gonna use metadata that, cause sometimes they're double, right? Sometimes the do not archive flag is both a qualitative statement and it drives whether or not I archive the workflow. But the most of the workflow driven metadata is stuff that I'm going to add after the fact. The intrinsic metadata is stuff that's in the file format. We collect that as a matter of course, but that qualitative, how do you do business? How are you going to want to get this stuff back later? What are you going to want to search on? If you don't put it in on ingestion or soon after ingestion, it's never going to get put on that asset.
Speaker 0 46:18 And it's, it's tough to find them because you know, an organization may be like, well we think these four fields will do it for us. And you're like, you probably want a few more than that because if you start coming up with a bunch of new fields, six months from now, you're going to have a whole bunch of content you put in there that need to be retagged. Now, wouldn't it be good to have something a little more fully functional right out of the gate? Well, well,
Speaker 2 46:41 And even worse than that, it's not even just retagging. It's the fact that, Oh, you're functionally orphaning media. Now if you add metadata after the fact because you, and it's not like it's the end of the world, but if you add very formal and specific and needed business unit metadata after you've been using the system for awhile, you have functionally just deleted all the files before cause the first person that searches for only that field is going to return none of the assets before its creation. And there really is no logical way for qualitative metadata to go back and script it. You know somebody's got to go back and audit all of your existing stuff because it's qualitative. No one ever does. So. And I almost think of that that schema and that qualitative metadata is, is as important as when on the of work it says, yeah the server has to be in the rack and I need to either net cables. We also need your qualitative metadata schema. And there are, there's a certain degree of, you know, each product handles the way those schemes work independently and what you can actually accomplish and what tools you have to do that. But you don't need to get into that until you already have a first pass discussion. And that's something that none of us up here even need to be involved in. You know, it's something that has to do with your business and the way you want to collect, find, search, and distribute your
Speaker 0 48:03 Assets. Yeah, and, and you know, there's also a risk in the other extreme of too much metadata like a user, unless they are paid to be the tagger, the logger, the librarian, they are the person who is in the ma'am all day long tagging things. And that's their job. They helped come up with the taxonomy and you're paying them to do that. I hate to say it, but at this point I haven't seen too many editors that you can pay to put 50 tags on a clip, right? So you have to have like the Goldilocks. It's just right. It's in the middle. It's going to be useful enough to power searches, power workflows, but not be so granular that you know, no one's going to use the system. I like to think that if you're coming up with a metadata schema that you know if you put just the right set of variables, you feel like you're always going to find the one clip you're looking for.
Speaker 0 48:56 You might be a little too granular. You get it down to 10 think of it like that first page of a Google search. If it's on that first page, you've done your job, you could find your ass. Yeah, you don't need to eliminate 99% of someone's time in a day doing searches. If you can eliminate 90% and have a system that people are actually much happier using, you've still just saved yourself a lot of time. I'm going to, I think at this point open up things for some questions in the audience so I saw some hands earlier and if you could give your name and organization or affiliation as well, that'd be fantastic.
Speaker 4 49:32 David Geschwind of a three dimensional media group without naming names, unless you want to, could you identify half a dozen customers in terms of what kind of business they're in, what are the assets they're managing? What is the Adam, in other words, are we talking about half hour sit-com episodes for syndication? Are we talking about individual frames at an animation house and order of magnitude? How many items do you have in the library before it's worth investing in a management system? Question?
Speaker 2 50:07 The answer is yes. Um, we've seen it all. Yeah. Yeah. Literally, I mean from a vertical market perspective, everything under the sun. I mean, just look around the room at everybody's name tags, you know? Yes, there's some traditional media in the room, but a lot of the people here are not from a traditional media and from those non traditional media environments, many of you are in the same business vertical. It's, it's very, very common to be, you know, across quite a few different, you know, the, the thing about asset management is it really is, as media becomes more and more important to your organization, it does become a replacement for something that you have been using for years. And that is the file system on your file server or your sand. It becomes the tool that allows you to track all this stuff, which this same problem happened with still images and Excel files and everything like that 15 years ago, but media was not as ubiquitous as it is now. Now we've got phones in our pockets and everybody here could be shooting an hour and a half of video right now. Have that checked into a system and now that that's happening, you know being able to recover that content and find it a file systems just a little antiquated for that. Can you do it? Yeah. Is it efficient? Not generally.
Speaker 1 51:19 Greg, can you speak to the numbers of assets and the spectrum that you've seen? Cause again there's a lot of diversity there as well. We have some small organizations that are seeking to do ma'am and we've got some very large one was with millions and millions and millions of assets. I mean I have customers where it's, we have 20 terabytes on an old Exxon somewhere that we want to catalog and or, or even if it's an archive only, we're not even using it for productions. We've got some stuff that's been archived using tool XYZ, we want you to bring that archive in and just be able to search it and make use of that stuff on up to customers with millions of assets and 15 petabyte libraries. You know some of our big customers go that high so it's all over the place and it's, it's finding, you know, I think it's when, you know as an organization with kind of what Mike said, that the idea of a, of a file based workflow where you have this file system and that's what you use to find things and as long as that's working it works.
Speaker 1 52:21 But then you get pretty quickly to a point, especially if there's multiple people touching that file system where that stops working and you have to kind of go away from the next heard this before from the file based workflow to a content based workflow where I don't care where the file is or what it's named or any of that stuff. I shouldn't have to think about that. I care about what it is and what I want to do with it. And then the storage and all that stuff, just who cares about that? I'm, and it's a much more human way to work and I think it's really, you know, as an organization we're not, things start to fall off and it, it happens, it can happen pretty quickly.
Speaker 3 52:58 Well I think it's multiplicative and I think you hit on the two sorta accesses it's number of assets and the number of people, right? If you've got a lot of assets, even if you're doing it on your own, trying to find stuff, you know, I can't even find, you know, baby pictures at this point cause there's thousands of them. Or if you have a whole team of people, even if your number of assets are small, that complexity can get to the point where you don't know who's using what got what locked.
Speaker 2 53:25 You don't know. Some of the check in checkout kind of workflows. That becomes important too. So those two factors can sort of drive you to a ma'am as opposed to files on our drive. Yeah. We just recently did one that's three users, but it's a petabyte and a half of storage behind it. You know, it's the, it's the librarian's front end for their entire corporate archive. And then we've also got ones where there's 30 people using it and maybe it's only 30 terabytes of storage, you know, so asset count and they don't necessarily have to be inversely proportional. But the reality is is that it starts to become valuable when you have a lot of people or when you have a lot of assets and if you have both it becomes double evaluable.
Speaker 0 54:06 Okay, who else over here?
Speaker 5 54:09 Um, hi, I'm caravan Molson from Avi preserve. We are a consulting firm and basically we do everything that you guys just described people need to do. So I mean I would be remiss not to say like that there are consultants who do this kind of work help you with the discovery, articulate your business needs, your requirements, your use cases, your taxonomy, your metadata schema, get the buy in of all the stakeholders. That's basically what we do. And we use that to help clients identify solutions that will work for their needs. And so what one of the questions, well, what, I have many questions but I'll just limit it to one, um, question that I have is that when you find potential clients, um, maybe you, you know, you haven't even, um, definitely gone ahead with them, but do you have alarm bells go off when people come to and they're like, we need a ma'am.
Speaker 5 54:59 Yup. Can you give us one and, okay, sure. I mean, they'd haven't gone through any of the things that you've gone through. Somebody at their company plays golf with somebody else who uses your product and they say, great, we want that. Yes. Thank you very much. Because to us, one of the answers to the questions that people might, the questions that you might be raising is maybe you're not the right solution. And do you ever come to that conclusion or how do you deal with that situation when you kind of realize perhaps there's more work to be done before we work with you? I mean, do you ever encounter that and how do you deal with,
Speaker 0 55:37 So I'm going to take the first stab at that. So the Chesapeake systems answer to this question is, this is why we work with multiple platform partners and, and that's actually, I mean a very big part of our philosophy. Number one, cause we've gotten burned in the past when a company Apple changes, you know, on a dime their strategy and discontinues their entire server and raid division or dramatically changes their editing platform, right? Or a company just sometimes goes out of business even unexpectedly. Um, you know, some of us used storage or worked for the storage companies that that may have happened. So, you know, we have chosen that we want to have multiple partners. You know, and I always talk about there's a lot of different spectrums that ma'ams on theirs. Theirs. Is it kind of outwardly focused for a larger set of users who are doing fairly basic search type stuff and it's really to identify assets and maybe trigger some basic workflows or is it a really post-production heavy work group and few of the platforms can do both of those things very effectively, although some of them can.
Speaker 0 56:42 But this is why we kind of have multiple partners and we kind of have a sense about which one of the partners that we work with may seem more appropriate, but we'll often present multiple solutions and go pretty deeply down that path. You know what you said about, you know, you guys and the guys that audio visual preservation solutions are another partner of ours and we have a lot of respect for them. They've been participants in some of our previous symposiums. And um, you know, it's tough because I wish every client kind of valued at that process of, of learning about themselves enough to inherently think, to work with your type of consulting company as well as us who kind of do the technical implementation. And it's a little challenging, um, because first of all, I don't think necessarily lots of people know people like you guys exist, so everyone in this room, they exist.
Speaker 0 57:40 But, uh, and they're great. Um, you know, but it's, it's also kind of a very brainy process. Right? And I think some people just are like, they're so used to being in the trenches of media production. This idea of kind of taking a step back and you know, getting meta on what they do is, is just not the type of work they always are used to doing. They're used to doing their job, they have deadlines, they're publishing content on the web. And so it's, it's, it's a tough dynamic. The other dynamic is you may be a small organization with a lot of legacy media content and you need that deeper discovery phase to develop your metadata taxonomy to come up with some of the workflows to even figure out like how long is it going to take me to digitize this legacy videotape collection? All of this stuff that you guys do consulting on.
Speaker 0 58:29 And yet they might not have the resources to bring in yet another consulting firm. And so, you know, it's a tough dynamic, but it's a very important one and one that we have certainly brought some people, you know, towards the folks who do that level of consulting. Just want to rephrase a little bit maybe cause you're absolutely right. And I know most people, maybe, maybe it's not most, but I know a large percentage of potential users of ma'ams organizations do not go through this process. We don't see those. We only see the ones that we work with. Right. And so do you, so what I'm curious about is how do the product vendors deal with this situation? Because I agree with what, and I know that you guys do great work of working with various partners and helping kind of mitigate this process or the risks, but how, what if you're confronted with it as the vendor? And this is a tough question, I think, um, how do you kind of help
Speaker 1 59:22 Them help themselves? Well, you know, I think when, when I sit down with an organization for the first time, we've seen it enough that you can kind of quickly vet whether or not their expectations are realistic or not, or whether or not we're going to be a good fit or if it's a, uh, you know, square hole, round peg kind of situation. Right. So I think that's, that's just a part of being a, shall we say presales engineer or someone who's been doing this kind of thing for a while. You need to be able to kind of quickly get through the process and then you can vet your mind. Okay, well we're, we're gonna it's a fit. Oh great. Okay. Now is this an organization that needs, do they have the resources to hire a consultant to talk about this stuff or is it going to be enough for me to bring in a partner, like a Chesapeake systems that can help them with it.
Speaker 1 00:09 And you know, we also work with a variety of partners and I have certain partners that I know do some things really well and others that do other things well. So it's then choosing what partner to partner them with and then that kind of informs how long this whole thing is going to be. Is this going to be a a, you know, a film festival, photo archive project that we're going to be able to nail out in six weeks? Or is this going to be a a, you know, a major sports organization that's going to take a year to implement. So I think it's just working with a customer. It's, it's, it becomes clear. Mike,
Speaker 2 00:42 What do you say? I mean the reality is is with what, what the products do. If you have enough time and money, the answer is always going to be yes. So having a realistic budget in place is going to really quickly define whether or not it's a viable solution or not.
Speaker 1 00:58 But that may mean like rewriting the software. But again, the man vendors are mostly came out of consulting groups that write a lot of software. So I mean their, their, their proclivity is to lean towards, sure, we can do it. We can.
Speaker 2 01:10 Yeah. The, the, the reality is, is that there are things that are just full on stoppers that when you hear them you're like, could we do it? Probably would you want to know? We don't want to. It's, it would eat up all of our time to do that. And even if you cut me a check for a million dollars, I'd lose all my other customers because we'd be too busy trying to, you know, birth another unicorn. Um, you know, yes, that's the second unicorn birth statement I've made today. And, and, and these guys are like Pegasus and unicorn manufacturers. So that's why, you know, I think to a certain extent when we talked earlier about the phased approach of, you know, rolling out something and understanding the fundamental core where you want to go with it and what it's capable, you know, what's core functionalities are, if it fits within the fork, the phase one desires fit within the core functionalities, then it's a go and the other pie in the sky stuff very well may be capable in a phase two, phase three, phase four, whatever the case may be.
Speaker 2 02:06 And then you team up with somebody that does custom development. Almost every single one of the, you know, man projects I've done in recent years has had some degree of customization to meet a very specific need within a very specific business unit. So if I said no to everything, nobody would ever buy the software. It's yes with an asterisk. Do you have the budget, do you have the time and do you have the proclivity to take that budget and time and use it? Cause sometimes you have the budget and the time, but you don't want to spend it on that thing. You want to spend it on something else. So you know, it's w I'll, I'm, I'm pretty clear about when we really can't do something, but the rest of the time it's, it is, it's a question of how much time are you willing to spend? And the answer may be that, you know, their stuff can do that little thing a lot better than weekend. And then now you have a direction to go to. But there's a lot of crossover.
Speaker 0 02:59 The other thing I'll say, Kara, is I think there's been, you know, we've been dealing with media asset management for probably eight, nine years now and I think there's been some maturization process that's taking place amongst the vendors. When we first started working with some of the man vendors that were catering towards really media users specifically, I think they leaned much more to sure, yeah, we can definitely do it. Oh it does it, here's how you would have to do it using it. But you know, you know, they kind of leaned towards yes a little too much and I think there's enough vendors out there that have different areas of strength and the vendors themselves know what their strengths are because they simply have more projects under their belts now. They don't want to get themselves into a terrible situation. They don't want that track record.
Speaker 0 03:52 They don't, you know, word of that gets around, Oh, we did an implementation of such and such ma'am, and it stunk. We have to replace it now. You know, they don't want that getting out there. They want their projects to be a success and to go smoothly and they don't want it to completely tax their resources because you know, these guys can stamp out a software license like this, but they can't necessarily, you know, make every customization that you want to have happen in order for their system to work for you to happen quite so easily. It takes a lot of effort. And so I seen them getting better about stepping away from projects that just don't pass their own kind of smell test and, and I, you know, I like to think that myself and the partners that we work with tend to be pretty clear cut about that and we, you know, again, it's not like a whispered asterix.
Speaker 0 04:38 We tend to just put those things really out there so people can understand, you know, what they might be getting into. But it's very, very worthwhile to be aware of those types of things. More questions, anyone? We've got time for a couple more, Justin and doing one of these deployments. There's kind of the, the, the functional side of it though, the workflow orchestration, how files move around. How things actually happen in the system. And there's also then the front end, if we, if we want to deploy a system that has potentially hundreds of users, designers, PAs, editors, uh, even people who are not, you know, people who are not directly in the departments create the content that's on the system. Is it better to start with that core functionality and get that up and running and then develop a front end for that? Or is it better to start with the front end in mind? Sort of the rough out that framework because the front end is kind of what makes it usable and what can get the broad acceptance. So we don't just deploy a tool that when it gets deployed, it looks crummy or it doesn't have all the right buttons and equal to or better than what people currently have.
Speaker 2 05:51 Well, I can speak to that a little bit. Um, I think to a certain extent it's an unrealistic expectation for your primary goal to be a customization. It's just not to say that it's not doable, but the cost in either human time or consulting dollars or both, whatever, you know, depending on your organization's capabilities to build something that is very specific to you as being a core functionality is something that you know you're not going to find that very easily. I think really what you want to be looking at is look at your own internal resources as far as if you want to customize and develop that front end to meet needs. If you don't have the internal resources, start to look outside and then look at the tool sets that are made available by the different vendors and pick the one that you feel like has the easiest fit for what your use case is. Because some vendors wide open, we can do anything under the sun when it comes to the front end development. Others are very, very rigid depending on, or their framework isn't very well vetted. So you're, you're starting from scratch really when it comes to devising a front end versus just kind of tweaking and turning knobs. And there is a kind of everywhere in between depending on, on who you go with. So I, Donald Gregg, if you got anything to add on top.
Speaker 1 07:10 No, I, I agree with what you said. I think that, you know, from, from our standpoint we have a, you know, it was a gooey when you log in and it looks a particular way and a lot of thought went into that and we don't allow you to, to kind of tweak that and that seems to annoy some customers and other customers really like it. And we provide an API so that if you want to build a something else on top of it that talks to the, to the product underneath, it's possible to do. And I think that most vendors, you know, will allow something like that. So then it comes back to, I think if you have a, a front end in mind, having that sketched out and in, in the back of your mind or maybe something you talk about upfront is there's nothing wrong with that, but that's, that's a phase two or maybe a phase three of, of implementing it.
Speaker 6 07:57 But does that affect the success of the project as far as the actual usability? Like do you have ever projects that fail simply because people will end up using it because it's, does that happen?
Speaker 2 08:09 I don't think so. If you go into it with the right ideals in place, um, if you go it saying, well, just pretend this doesn't exist because we're going to change it all in the future for you. That sets the expectation that they don't have to actually adhere to the standards that are within the system. If you go into it saying, our longterm plan is to tailor this to really fit the use case that you guys want, and then they get a comfortability with the way things kind of work, then you're going to have far more success because then you're kind of expanding on an existing knowledge base as opposed to saying don't bother learning this cause in six months it's just going to go away anyway and then you don't have buy in.
Speaker 1 08:48 And, and that, that change management piece I think is, is one of the biggest parts. I mean that's what we've been sort of dancing around. I think the whole presentation is that you've got to have the stakeholders in the room and ready to use the system. And so maybe a front end discussion is, is a way to get buy in. But I think that that's the wrong way to go about getting buy in. You need to have buy in on the concept as a whole and what it does and then
Speaker 0 09:17 This will fall into place. The other answer that I'll put out there is, you know, one of the points of a media asset management system is that it can abstract away a lot of that background complexity. It's not that the complexity is ever going away. In fact, it may get even more complex behind the scenes, but you're abstracting it away and I mean you're abstracting it away and turning what can be potentially very complicated workflows into essentially one of several things. You could be kicking it off by altering a metadata state. You could be kicking it off by either pulling something into or dropping it into a watch folder. If you kind of have a hybridized, you know, file system and database driven ma'am system or maybe you have an action menu that you click on to kick off a workflow. And again, it's either being fueled by metadata tags or it's giving you a little bit of a dialogue to tweak that workflow.
Speaker 0 10:10 But I mean these are not really difficult paradigms for people to wrap their heads around. Again, check a check box holds something from a popup menu, click on an action menu and kick it off, and so I think it's important to have a front end experience. People can begin to get used to using for even again, some fairly basic search use cases, maybe as the front end to an archive system, but that's just the bulk of it initially and get them comfortable with the paradigm of that user interface. Going into the ma'am and learning to search through the ma'am instead of delving through the file system, getting comfortable with that and making sure that your metadata is right and then focus more and more on the background. Complicated stuff. From a development and integration standpoint, there's, when it's time to teach the users about that new cool automated thing that they can do, it's just going to be a metadata check box.
Speaker 0 11:06 Something that they pull from a pull down menu or whatever. It's not going to be that difficult to teach them how to use that new functionality if it's done correctly. Like that's the reason we try to even mess with these systems, right? It's to make those workflows easier on people, so I think getting them used to that place that they're going to start to live more and more and then be gradually adding up more interesting background type stuff that they can be triggering in these very easy ways is probably the right way of going about it. For a lot of organizations, I mean again, some people use these platforms and are barely using the front end. You know a lot of the memes have a lot of automation tasks and stuff that they can handle in the background and you don't even need to interact with the front end.
Speaker 0 11:48 But for an organization that's going to be using the front end as part of their new tool set, I'd say yeah, get it up and running fairly simplistically. You don't necessarily still just choose a Mim for its front end. You have to know what its backend capabilities are and whether those are going to meet those eventual challenges, but get the people into it fairly quickly and again, get those easy, quick wins that get them comfortable in it and then give them new menu options. Once in a while, give them new process oriented metadata that kicks off more and more so more and more of their time in their day and their, their set of tasks are from that standardized user interface. I think we've got time for another question and I'll do Chris, how do you deal with project based workflows where the files have been abstracted and you may need to recover those files 20 years from now. So you've gotten rid of the folder structure, you've backed it up on the tape and all those files have been abstracted. How would you deal with that?
Speaker 2 12:49 So, I mean, the most common way I've seen that done is a qualitative metadata field that stores project information. Any one of these systems, if you really want to get into the fancy stuff, you can start writing XF metadata into the file, the files themselves. But if it's on tape somewhere, it's abstracted. And you, I mean there's, it's a pretty complicated, you know, uh, that's, that's, it's a lot more difficult to accomplish when you are thinking about it in the sense of that file is being completely disassociated with the thing that's creating all the logical links to it. Because my expectation would be, and maybe I'm crazy here, is that if my guys go out of business, are you jumping from one ship to the other ship? You're going to have some sort of logical trans fusion of information from one to the next. So the idea that I'm going to go away, it doesn't scare me at all. What would scare me is if I go away and there's nothing to replace me, you know, maybe in 10 years the file systems themselves actually can handle all of that metadata as a transport piece back in and through and we aren't necessary anymore. Chris,
Speaker 0 13:56 I'll give you a specific example that we've had to deal with a number of times now. We had this wonderful little product from a company called Apple called final cut server that a lot of our clients put in with various levels of complexity. Some of them bought it because it was a thousand bucks and didn't quite realize what they were getting into and some of our clients used it for extraordinarily complex workflows. We have a client in Baltimore that we are kind of in wrapping up stages of, I'm not going to name them that named them by name, but they're a, they're a for profit education, a higher learning institution, very big name, big company and they had a very sophisticated final cut server system and I believe it may have been tied into archive, but it also just triggered a lot of complex automated workflows.
Speaker 0 14:41 It was building playlists for online platforms and distribution of content to their student base and all of that. And we that was dead. There was no support for it at all. I mean, heck are there, how many people at Apple who were even associated with final cut server who are still in even vaguely analogous roles like one or two. But most of the others, it's one, it's a little crazy. We all know who it is, right? You can name him. So, so you know that was the reality. But we had a few things going for us. It was an open database we could get at the data. Anything that was put into their final cut server was available for us. So that really helped. We could migrate the database to whatever new platform it was going to be. In the other case it, it's rechanging.
Speaker 0 15:31 So we had access to the raw database number two, and it's not always the right way to do it, but in their case, a lot of their automations were external to the man platform. They were scripts and workflows that they with us, developed themselves that were simply kicked off by the man. And we had to kind of take a full accounting of those. We documented the heck out of it with them and figure it out. Okay, we're not really changing these workflows. We just need a new thing to kick them and we need to do it the way that reach engine wants to latch onto and kick those workflows. And we did that. And so we started to essentially kind of, it's like the X-Men Wolverine, have new skeletal structure overlaying like the, you know, the other one, but you really have to like rebuild the guts of it from the inside until the point you're ready to kick it over.
Speaker 0 16:23 And now all that's left is that new scaffolding that you built up kind of in tandem with the other one. Right. And so it's ended up going quite successfully. These things with the development side. And I think John even been involved with these guys, um, you know, can take a little longer sometimes than the people initially think. But at the end of the day we've stood up a new ma'am with those same automations. Now going just a little more specifically to your archive question, and I'm not going to take it from the end of the archive software side. I'll just take it from the side of the, ma'am, let's pretend the archive software still exists or you're using something a little more open like LTSS or just generic tars, right? You're going to have the database again, that's basically linked to that other archive database through metadata fields, right and through, again, ideally you were extracting some stuff out of the archive database as well, like the unique identifier for that object as it exists in the archive database, but you've pulled some of that data into that, that record in the ma'am as well.
Speaker 0 17:27 And so part of your data set in the ma'am database is the information that will link that record back to what's existing in the archive.
Speaker 7 17:36 I totally get how you could do it. I'm just wondering if there are ways that we could make it easier on ourselves. So you talk about LCFS so that it gives you the ability about an individual tape on your desktop, drag the media off. But if it's totally abstracted, again, all the files are abstracted. You've got no no file structure that you can look at. So do we throw out the baby with the bath bath water or do we preserve some of the old in order to make it make it so that you can totally migrate?
Speaker 2 18:08 Well I think I can answer that one with another like use case scenario. We just did a big yeah. Again, a final cut server migration, right? There's tons of these things out there. Final cut server wanted to manage data in a very specific way. It had a file system behind it and you put things into things called devices and then those devices could move things between other devices and so on and so forth. We migrated all that content in. We basically mapped all the devices as items on our world and then we just set up rules to redistribute it all and no user interaction had to happen whatsoever. There basically you kind of click the button, everything came in and then based on those rules everything got redistributed and then we kind of removed the unnecessary devices and remove the unnecessary folders and now we're in a new schema in the backend. Everything is still referenceable in the exact same way. With the same keywords, metadata, structure, everything like that. And you know, most of these ma'ams systems, not all of them, but most of them have a way to get out of their world as a PO and not just into their world.
Speaker 1 19:08 And I think that what you're touching on there, Mike, and and it's perhaps a separate and larger discussion, is that any time you're going into a, a catalog system or an archiving system or, or our ma'am, you have to look at an exit strategy, right? Because technology does change. Companies come and go, it will. That's yes. So what you're, if you have content like content that you might be, you know, responsible for that's going to have value in 20 years or 30 years, maybe even more value than it does now because somebody on that became a big star later on. You've got to have a strategy for that and that that's a discussion that is certainly worth having in, in a serious one. But it's a, it's tricky
Speaker 0 19:54 And actually I'm going to just plug a VPs again, again, there are firms that are very oriented, not only about, you know, bringing your archives into the digital realm, but the right way of, of managing, I mean even physical copies of the assets but also the digital representations of them. What are the right formats to keep things in that have longevity or multiple versions because you can't be sure of what the future is. And again, I think the short answer is you'll cover your basis for your basis from as many directions as you can because as you said, you can kind of count on vendors, changing technologies, changing approaches, changing and um, have an exit strategy is not a bad idea even to go into a discussion with a new vendor with, I think what I'm going to try to do, we could probably go on for weeks because that's again, just what we do. Um, but I'd like to transition this over. Now this is going to be a quick set change cause I want to go into the presentations. We're going to kind of go a little deeper under the hood, both with a Cantwell and reach engine to show some of the deeper level, you know, customization and integration possibilities. So stick with us just for a few as we handle this. Thank you everybody.
Show Notes
taxonomy
schema
object storage
REST-capable storage
watch folder
ontology
There was a consensus among the panelists that there were 3 types of metadata. Below is Nick's summary of that:
We invite you to check out the other informative episodes from our popular podcast series. Wish to discuss your digital video workflow situation with Nick Gold? Email him or call 410-400-8932.
