PODCAST: The Role of Entity Modeling in Business Process Management
Podcast: Play in new window | Download
Welcome to Just Clarity, a periodic podcast about Digital. Just Clarity is produced by the team at Digital Clarity Group. We help leaders transform the experience they deliver to customers, prospects, and their employees through the effective selection, integration, and adoption of customer experience management technology. Learn more at digitalclaritygroup.com
Connie Moore (CM): Welcome to Just Clarity podcast sponsored my Digital Clarity Group. I’m Connie Moore; I’m the Senior Vice President of Research at Digital Clarity Group, and I’ll be moderating our call today.
Our guest is a very good friend of mine and someone I rely upon when I want to brainstorm or think through issues around Business Process Management, Customer Engagement, or business transformation, and our guest is Derek Myers who is a Principle with a structured talent based in London. Prior to that, Derek and I worked together at Forrester Research for a number of years, supporting Business Process Management professionals on their journey to business and customer transformation, and before joining Forrester, Derek was the founder and Principle of Enix Consulting where he advised large organisations and software vendors on all aspects of Business Process Management.
So, Derek I would like to welcome you.
Derek Myers (DM): Thank you, Connie.
CM: Today we’re going to be talking about Entity Modeling and its role in Business Process Modeling and Business Process Development. So Entity Modeling has been around for a long time and is a familiar term to anyone in the Information Management field, but it’s still relatively new to the Business Process Management Practitioners Lexicon. So could you take us through what Entity modeling is and why it’s surfacing now in the BPM circles?
DM: When you say it like that, workflow, I’m not sure it really is surfacing that well. There are some vendors who have got the hint around it and you could argue that it’s pretty central to what you would think of as Case Management that you know we will come onto that I’m sure, but let’s go back to the information Management domain.
You know in the 1980’s when relational databases first appeared, this whole idea that you would construct a pure model of the data that you needed and somehow rather that wonderful model would permeate all your systems and all the programmers would get down and bow down to it rather than creating local variables for their… you know some of the products talk about global variables for example that are available to the other processes as well and then, of course, you get to this point of saying, “Well Hold on, I’ve got all these global variables and they all sort of relate to each other”, but by looking at the structure of the data you could actually say that a person has an address, you know the address is held in an address table because you might have more than one address and a person, obviously salutation, first name, what have you, but the address table, you could then have three addresses, or five addresses and you wouldn’t be limited necessarily in your user interface, and ultimately that’s the core of Entity Modeling is that you’ve got relationships between the entities that are important to you and you can use that to act as the basis for your processes and what have you to work on, and in a way I’m segueing now to almost to modern day, but some products have had it since the get go.
If I think back to the approach and the product that I killed off in 1992, we had a core central set of entities that were reused across all processes and that way you never had to map your local variables and process A to process B, they all just shared the same data space and therefore, when I needed to from the calling process to call a second process, you know I didn’t have to do any mapping, it was very, very simple because that all shared the same data space, and that data space was defined through a set of entities.
Now I suppose where we get to right now is that, you know we had a sort of a hiatus in the middle and I’m talking about 90’s and most of the 2000’s where vendors sort of ignored that for awhile and they always, the hard part to standardise was always the data and you ended up with very complex process variables in you know solution A being completely unusable again in solution B that you might be developing to take to support your business, and that’s really where Case Management comes in. Shall I go there now Connie or do you want to?…
CM: Yeah, I think Case Management would be good because when you do talk to vendors about Entity Modeling, they’re usually discussing it in terms of Case Management, so why is that?
DM: So ultimately if you think about a piece of work you’re trying to support with processes, it’s going to context, that context in the old days way of designing processes, you’re trying to design one process to do everything to do with that context and that’s why you’d have this very arcane and complex variables attached to the processes. Now with Case Management, actually what you’re really saying is, we have this rich data space that we’ve described with a set of entities, documents, relationships or what have you, and these things are all related to each other and then now instead of declaring each set of variables for each little fragmental bit of a process that had to deal with these things, you’re able to sort of use that central context if you like and then have multiple processes acting on that data and that’s why it’s become much more important because people have realized the primacy if you like of the data structures behind the processes too because it’s not just about, “Oh I can move activity A,B,C,D”, it’s “Activity A I’m manipulating this piece of data, activity B I’m doing that, and I can totally see Well actually that’s a whole new process”, and now rather than having to map all those variables from A and B and then into this whole new process we can just call C for the moment, they all share the same data space so therefore you can just call them and the variables are the same and the names are the same and the forms you are using are the same and all those sorts of things are all certainly completely reusable across them. Does that make sense Connie?
CM: Yes it does, and Case Management is so rich in terms of the entities that are supporting the process and the process fragments are sometimes quite sophisticated in how they’re designed to support a process. So Entity Modeling, it is particularly well suited for Case Management. Although it’s relevant for all processes correct?
DM: Well yeah. When you come back to this point, a lot of these discussions are so vendor specific, how would I phase it? You know some of the vendors and take a vendor like Bizagi for example. They have a shared dataspace at the core of their product, and really you know, their whole raison d’être if you like, that product was about the way in which you design this data as almost a virtualization of the underlying databases and things you are interacting with, and your process is then and the forms and things that are a part of that process are all insulated if you like, from the backend applications where that data comes from.
Same sort of approach you might find in something like Payday. You know there they talk about fused data model which is Object Model which is fused with the processes and the rules and everything else that operate on it. Same sort of thing in one level or another inside Bizagi, for example.
Now if I go back to for argument sake for the products that you know, the ones that OpenText have inherited for example. If you look at Global 360 that was rolled up with the other roll-up of roll up and things that were going on there, they’ve now rebuilt sort of entity based model concept of the core of the way in which processes work because they’ve realized that it’s needed.
Now I’ve just mentioned three; there are probably 300 vendors if we were to sit down and try and detail them. At various levels of sophistication some of them have got this shared data space entity model at the core of what they do, others just completely ignore it. So you could say, for example, I don’t know Sharepoint, let’s choose another one. You know Sharepoint’s data stores are in a way it’s data model that it’s got available to you in the context of the workflows that you’re building in Sharepoint, but you know they’re pretty limited because you always have to name then and they’re actually related back to the Sharepoint lists and all those sorts of things that are part of that workflow. When you try and reuse them in another one, it starts to get very, very, very complex and hence force you’ll find products like Agilepoint, or K2 or what have you that are starting to access that sort of data and what’s coming across it.
We could carry on here about different vendors and their different approaches. Some of them have a much deeper appreciation of this, some of them it’s just, “Well why would you want to do that? We can name variables,” and you’re going, “Yeah, but show me, and what does that do?”
CM: Right.
DM: And there’s always a lot of rubbish out there as well.
CM: Always. I want to shift gears… that was helpful to look at the different levels of maturity that vendors have about incorporating Entity Modeling from core to nonexistent. Let’s take a look at the skillsets. When you look at changing the mindset so that maybe you start thinking more about things in the organization that the variables versus flow, do your process modelers need different skill sets, do they need retraining, do they just need a short course, and they’re off to the races? What’s required to make the shift from a staffing point of view?
DM: Well you know I always used to say, Object Orientation which is part of really what we’re talking about here, the things in the domain that you’re dealing with. Object Orientation is a state of mind. If I think back to Office Engine, a product I killed in 1992, we had an abstracted object sort of repository that’s set under the hood, and you build a model of what you want to do, and you had built the system.
Now there’s nothing particularly new in that. Now on the other hand if someone has grown up with programming and they’re used to writing a program and declaring the variables for their program and then they’re going to undo some things in their program and then their program is finished, and it’s going to produce a result on the screen, whatever. Then the whole idea of having named variable pairs as part of your program, I’m using that word rather than a process for the moment, makes a whole lot of sense.
On the other hand once you start to say, “Well actually I’ve got this process” and let’s think back to the 90’s Connie when you were looking at I don’t know, a FileNet application at the time, you had these really, really 300 step processes with lots of redo loops and feedbacks and what have you whether it’s Filenet or anyone else or Staffware or whatever, and they all had named variable pairs in there and you know it was very easy into a mess because you know, would updated would taken the I don’t know, would’ve taken the amount of account and then some were done some manipulation and then would’ve updated the account and then we still had that working memory and then the client had gone ‘blah’ I want to change things, and actually it’s’ not longer a short running processes, it’s now a long running process that maybe spans minutes, hours, days, weeks, months, years, whatever. The point is that the state of those variables changes and is updated and you can’t always rely on that.
But coming back to the point about those amorphous programs that were written or those amorphous processes that were written to solve a particular problem, you know that’s in a way gone with the Dodo bird in the sense you really want to have a bunch of process fragments that interact with the same Dataspace.
Now your question about “Do the folks need retraining?”, Yeah if you’re a Java programmer and that’s all you know, then the whole idea of dealing with an Entity Modeler that’s shared across a number of processes is a bit foreign because you’re dealing with the… you know well I suppose it’s a bit foreign in the sense that you might have an XML path description that takes you to the XML structure that you want to work with, but you see where I’m coming towards? The point is it becomes a state of mind and you have to start thinking about it’s not just about the processes, it’s also about the data, and it’s the data in the states of that data that you’re worried about and the way in which you change state on that data.
You could also think about the roles that are involved and the states of those roles. There are so many different angles to what you think of as the process that you know just taking a unidimensional view is where you start to get into trouble.
CM: Yeah. So you do have to look at the skill, the mindset, the approach that the developers take as you incorporate Entity Modeling into your design approach.
DM: Hold on let me just pick up on a point here.
You know I said if you had lots of multiple process fragments and a robust Entity Model underpinning there that all shared the same data space, that actually the integration of those process now becomes an order of magnitude or two, and order or magnitude of two simpler because when you’re changing from process A to process C for example, if they share the same data space, you don’t have to worry about mapping them which is what you do when you’re writing programs because they’re already sharing the same data space and managing that context.
That means that your business people become the developers of your process fragments rather than necessarily them having to be software developers right? It’s only you need software developers when you have this, you know named variable pairs all the time going on and the complexity that goes with that. So it makes the whole thing an order of magnitude or two simpler by having the shared the data space that we think of now when we talk about as Entity Modeling.
CM: I think that’s a very important point in terms of simpler which turns into time and money.
DM: And just to sort of hone down on that for a second it just occurred to me, sorry to talk over you. The point in a way is like this, it’s almost like an inversely proportional, the further you get away from the real business need to the point where you know, the code is developed, then you know you’re talking almost a log of arithmetic scale in terms of the cost maintain and cost to own.
I remember in the 90’s doing some work for one of the big banks and they had built lots and lots of different workflow systems, and they were about to go for workflow, and in the U.K. this was, plus 30-40,000 employees, right? They were trying to work out the cost of ownership and they actually, we found that you know at that point and remember this was the 90’s, using the prevailing approach that they had on the go there it cost them something like, I can’t remember if it was 4,000 or 10,000, but it was several thousand Pounds, 10,000 dollars for argument sake to change a letter in a process.
Now today we think that’s laughable because we all just get in there and hack Word right? You know you hack your Word template and away you go, but in the same sort of thing in a way is happening with process changes and the process modeling and what’s going on because if you have to involve a long chain of developers and consultants and people to check and da, da da, this, that, and the next thing. Sure you’ve got to have ways to manage the governance of all of this, but you’re talking a massive increase in the cost of ownership for an eventual application and that has big implications for the sort of democratization of process in the world of today and the need for it.
CM: That’s a great point. So I’d like to wrap up by let me repeat what I believe your message has been this morning and then you can close by disagreeing or amplifying it or whatever, but Entity Modeling is an important capability for Business Process Management software and is something for any buyer of these solutions to look for. It’s particularly important if you have Case Management processes that you are going to be automating and I’ll add something that we’ve talked around, but haven’t said explicitly: If you’re in a big program, a big initiative to redesign, reinvent, transform multiple processes, it’s an absolutely requirement otherwise you’re going to have a heck of a time when you start putting multiple processes out when you start really developing let’s say, five, ten, fifteen, processes as part of a major redesign effort. Is that a good way for listeners to think about it?
DM: Yes and yeah I’ll amplify it. It goes a bit like this: When we hear the word transformation, there’s a lot of people that you know, want transformation, “Oh yeah I need transformation”, and actually what they actually want as much as anything else is they want someone else to change their processes, but them not to change. It’s a bit like I’m dealing with process A, process B, process C, you know 20 processes whatever. Those processes and need for processes have to be derived from the business need itself rather than how can I fix process A and process B.
It’s the question becomes one of, is it a bandaid you’re looking for or a wellness program? Which one? If you’re looking for a wellness program, this approach to actually getting around the data entities of the business, the Entity Modeler that really underpins the way in which work happens is of paramount importance. You are going nowhere until you do that.
Secondly, the point I suppose also comes back to why do we need these processes in the first place? Let me give you an example. Yesterday I was talking to a big brand, and they were involved in a transformation of their partner process and actually from you know the way it was initially scoped, what they really meant was this change the CRM system that unpinned the partner onboard and you guessed who that was to all about right? You know, “Can we please improve our Salesforce application?”. On the other hand, if you really wanted to reinvent the way in which you managed and onboard partners and managed them through their lifecycle. You know it’s a bit of like the choice of Salesforce almost becomes an afterthought really. It’s like “Well let’s actually think about why we need these processes, where they fit and how they’re gonna work first before we start saying, “well let’s just manage the pipeline that funnels if you like of partners we’re trying to put through this process”.
That’s a sort of a microcosm example of the need for starting with a more holistic view of the way in which processes work rather than just running straight towards a solution, and I think that’s true for many, many change programs and it’s not just you know the role of a BPM implementation of workflow products X or BPM product Y or Case Management product Zed, you know on what they want to call them, but ultimately you have to get to grips with. “What’s the data? Why do we need to do this stuff? How is it going to work? Who’s it for? What’s the experience we’re trying to deliver”, and it’s not about one process, the sales process, or the partner funnel onboarding process, it’s the, “How do we deliver value and make that?” and from there you get to the process you need rather than the ones that just reflect the org chart that you’ve got already in your business which is where most people when they think about process, actually are stuck. They’re stuck with the silos they’ve got, and this is our day, and this is how we see things, and the approach that we’re talking about here, Entity modeling is one way of breaking that down because you have to start looking more holistically across the value chain. Connie, I’ll stop there.
CM: Excellent, I think we’ve done a great job of covering, you’ve done a great job of covering the topic of Entity Modeling from the technology development angle all the way out to the business strategy level and where it fits in strategically. So I thank you so much for being our guest this morning, and I look forward Derek to many more times that you’ll come back and be a guest on our program so thank you.
DM: No problem Connie, thank you very much.
CM: So this wraps it up for today’s session on Entity Modeling for Business Process Management, and I’m Connie Moore, and I hope you’ll back and listen to many of our future recordings. That’s it for today’s Just Clarity recording, thank you.
You have been listening to another episode of Just Clarity. Produced by the team at Digital Clarity Group. For more information on the topics we discussed today or the subject of customer experience management, please visit us at digitalclaritygroup.com
