Terry Roach: Building Ontology-Based Enterprise Operating Models – Episode 179

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Spotify | Android | TuneIn | RSS

Terry Roach helps enterprises build a “web of connectedness” that helps them understand what’s happening across the span of their business

Built on an ontological understanding of business that is expressed in a knowledge graph, his methods and technology help enterprises develop a holistic understanding that can be expressed as an operating manual that all stakeholders can consult.

We talked about:

• his work as the founder and chief product officer at Capsifi
• how they do business enterprise modeling
• how business modeling helps businesses develop a holistic understanding and dynamic representation of their enterprise
• his definition of an enterprise ontology: “a conceptualization of a business, a common, universal model”
• the importance of enterprises having an operating model
• the role of a knowledge graph
• a framework that he uses which grew out of his academic work that accounts for business capabilities and value streams and tracks customer journeys
• how he measures the success of his work
• the challenges he has overcome in helping businesses develop a mental model of a business operating model
• his observation that the work to generate the operating model for any one business can almost always be used as a template for any business in its industry
• the extent of work that goes into the development of an enterprise ontology
• how his work as an enterprise solutions architect exposed him to the need for the work he currently does
• his belief that “the combination of knowledge graphs, enterprise ontologies, and AI can really bring the future and the potential to the enterprise.”

Terry’s bio

Terry Roach is the Founder of Capsifi and lead architect of the Jalapeno business modelling platform. He holds a PhD from the University of New South Wales where his 2011 thesis developed “The CAPSICUM Framework”, a semantic meta-model for the design of strategic business architecture.

Connect with Terry online

• LinkedIn
• Capsifi

Video

Here’s the video version of our conversation:

Podcast intro transcript

This is the Content Strategy Insights podcast, episode number 179. Any reasonably complicated product that you buy, like a car or a washing machine, comes with an operating manual, a comprehensive representation of the product that helps you understand and use it. Many enterprises operate without that kind of comprehensive understanding of their business. Terry Roach has developed a framework that helps organizations holistically and ontologically understand their business operation and all of its moving parts.

Interview transcript

Larry:
Hi, everyone. Welcome to episode number 179 of the Content Strategy Insights podcast. I am really happy today to welcome to the show Terry Roach. Terry was the CEO, he’s the founder and now chief product officer, at a company called Capsifi down in Sydney in Australia. Welcome to the show, Terry. Tell the folks a little bit more about what you do there and what Capsifi does.

Terry:
Hi, Larry. Thank you so much. I’m really pleased to have this opportunity to chat with you. Capsifi, we’re a software business down in Australia, a startup about 10 years old now. Hard to call us still a startup. We do business enterprise modeling. We help organizations bring together all the fragmented information that explains how a business functions, tie it all together, and give them a live, interactive, dynamic representation of the business operation in such a way that there’s a common conceptualization of what the business is, how it’s performing, where there are opportunities to optimize, and really drive an innovation and transformation agenda for an organization.

Larry:
That’s it, because every organization in the world seems to be in a perpetual state of adaptation and advancement and change and transformation. The way you just said that, it sounds like you’re talking about capturing all the business stuff that’s going on there. How do you do that? What’s the practices and technologies that permit you to get all that together?

Terry:
Well, that’s exactly right. It really is this situation where most organizations are so complex that nobody has the full, holistic understanding of how everything works. Every different person in an organization has their own role, and that role has its specific interests and their specific perspective on their part of the business, but each of them are producing visualizations and diagrammatic representations that are often completely disconnected from one another. There’s common elements in them, but there are very different levels of abstraction, different levels produced at different points in time, and the traceability and alignment, the impact analysis, if I change this, what’s going to be the impact to everywhere else, this is really something that is hard to get your hands around.

Terry:
As you say, organizations, they’re in a constant state of change. We’ve been riding this wave of transformation for the past decade or so, and everybody’s aware that actually, it’s not really about transforming so much, but building a capacity to continuously transform. That’s what we talk about. The only way to do that is to really have a good conceptual representation of the current state of the world. If you don’t really know how things are functioning now, where there are pain points, where there are maturity gaps, where there are opportunities to optimize, if you haven’t got that picture, then we are really taking stabs in the dark at every single attempt we make to try and patch things up. You can patch something here, and you’re just constant whack-a-mole of problems popping up elsewhere.

Terry:
The idea that you could have this enduring, incrementally evolving, dynamic representation of the current state of the business, it’s very similar to this concept of the digital twin of an organization. Every business stakeholder in the business has their own canvases through which they’re accessing common underlying content that represents, as they bring up a canvas, queries the content, queries all the states of all the information in the business, represents that back to them, and they can then get a view of how things work, tweak things, and the impacts are felt everywhere else.

Larry:
The way you said that, that it’s more about the capacity to continuously transform than… Because I think it’s like, I heard you talk somewhere else about the difference between business analysts and business architects, and that the analyst is more project-based and the architect is more buildings. You’re definitely in the architecture camp, it sounds like.

Terry:
We are. In fact, our tool is an enterprise architecture platform, except our nuance on that is that most people think of enterprise architecture as a technology-centric function, and in fact, for the most part, it is. People, when they’re doing enterprise architecture, they map out all of their technologies, how they all connect, and then, almost as an afterthought, they push up and say, “Oh, and yes, and this is how the technology supports the business.”

Terry:
We’ve come at it from a very different perspective. We try to explain how the business functions, what are all the moving parts of the business, how are they all connected? Of course, the technology enablement is just one part of that larger perspective.

Larry:
You mentioned a minute ago the idea of a digital twin. Usually, the foundation for that is like an ontology, first, you have an ontological understanding of all that stuff you just talked about. Can you tell me, is that the foundation of your model?

Terry:
Absolutely. That’s exactly where we came from. In fact, I think 10 or 12 years ago when we began, we were talking about these words, ontology and enterprise ontology and knowledge graphs, and we were feeling like we were having to really educate the world, whereas things have come so far in that decade, where this is now becoming really mainstream. Basically, the way that our product evolved was it was an academic exercise initially to try to figure out an enterprise ontology.

Terry:
What does that mean? It’s a conceptualization of a business, a common, universal model that should be applicable to any business, says, “How do all the moving parts of a business connect?” It’s quite interesting. We often ask customers when we meet them for the first time, “Where do you keep your operating model knowledge?” Most organizations don’t have such a concept. They don’t really have a tangible thing that represents the conceptual view of how the business functions. That was what we tried to set out to do.

Terry:
We said to ourselves, “If you want to build the model of a business, what are all the things that you need to consider, and how do they fit together?” That’s how we stumbled into the world of ontology, which is a conceptualization of a domain, all the concepts, all the things in the domain, and their interrelationships, the semantics of those relationships, all of the attributes of the things, and that’s what we have created. That’s the foundation, the technology behind the platform. It sits on a knowledge graph, and we load the content into that graph.

Terry:
We load in an application catalog, we load in a process catalog, the business capabilities, the goals, the strategies, the policies, projects, requirements, epics, user stories, everything has a place in the ontology, and we load it in or we connect to it via open APIs, so that wherever people are working, as they’re updating the statuses of those documents or those artifacts, we are able to query that, get the status, pull those threads on the ontology, pass it through a query layer up to interactive visualizations that represent the current state of the business. That’s the stack as we’ve built it, with the ontology really as the foundation.

Larry:
All that stuff, I understand how it can be represented ontologically, but a lot of the things you talked about, for example, strategy or epics and things that are in your Confluence or Jira instance, and pulling this out, how granular is this? Because you mentioned knowledge graph, and typically, a knowledge graph is going to have every instance of all those things you just mentioned represented in it. That sounds like a really daunting technological project.

Terry:
Well, how do you eat an elephant? One bite at a time. Exactly, the whole ontology is based on a framework, and that was the academic pursuit, could we come up with a common framework for how these ontological concepts could be organized? Our ontology has two parts. One is the business operation, and that’s basically the common concepts you’re familiar with, people, process, and information, and technology and how all of those things connect. We map them up into something that we call a business capability. A business capability map breaks down everything a business does into more and more granular parts, and then each business capability is an anchor point for people, process, information, technology.

Terry:
If you imagine you’ve got this functional decomposition with all these threads connected into it, and then we take those business capabilities and we look at how do you use that in an interaction with a stakeholder? We call that a value stream. A value stream would be the high-level processes or journeys that you go through on your business interactions. Let’s take a great example we always use, insurance. Settling a claim in insurance would be very perfect example of a value stream. We’d say, “What are the stages that you go through in settling a claim?” You probably break it down into five or six stages, and under each stage, let’s say, receiving the claim, what capabilities do you need? Stack those capabilities underneath the stage, and then each capability is mapped to the people, process, technology behind it.

Terry:
You can then heat map the capability. Say, “Let’s have a look at how well that value stream is doing. For each capability, how strong are the people? How strong are the technologies? How strong are the processes, red, green, or amber, for example?” Suddenly, you’ve got all these beautiful colors popping up across your value stream canvas, showing you where all the potential pitfalls are. Where you see red, you go, “Oh, there’s a maturity gap here. Tell me what the actual real pain points are.” You’re kind of putting your Post-it notes onto that red thing, and you’re collecting the insights from the business. And then for every pain point you go, “Well, how would we fix that? Ideas?” Pop the Post-it note for the ideas on, and you’re gradually building up the scope of change and you’re driving a method for how you can continuously update and monitor the performance of that data stream. That’s just the point.

Larry:
As you talk about that, I am a service designer, as well as other things that I do, and the way you just described, I don’t know if you know the field of service design, but it’s like-

Terry:
Oh yes.

Larry:
The way it manifests, for example, in tracking customer journeys, you have phases and touchpoints and you’re talking about pain points, and what was the other thing? Oh, and Post-its, like service designers live with whiteboards and Post-its.

Terry:
Yes.

Larry:
Are you familiar with that discipline, or is there a discipline like that that undergirds this, like the design process for the ontology, or something like that?

Terry:
Yes, exactly. We love the intersection with that community, and in fact, we often look at them and what they’re doing as hugely insightful. They’re approaching this from the right perspective. Who are the customers? What are the personas? What are the journeys we have with them? And let’s go and get some feedback from them on their experience across those journeys. The interesting thing about that is they produce really high-quality, beautifully graphical maps of interaction journeys. Yes, similar thing, you’ve got all the pain points mapped across them, but what’s missing, Larry, is what do I do about that? How do I move the needle on that experience feedback? What are the levers in my operating model that I can move that needle?

Terry:
If I’ve got a persona going through a journey and they’re telling me, “There’s a problem here,” and they can give me all the reasons for there’s a problem, it’s really hard to translate that into action, unless, and here’s the thing, you use this concept called a service blueprint. The top half of the canvas is the journey map, with all that feedback from the customer, the bottom half, the inside out, is the value stream. You map the journey stage to the value stream stage, and then you go down to the capability and you plug directly into the people, process, information, technology. You click in, pop up, here’s the detail about the technology, here’s the detail about the process, and you can exactly see where the opportunity is to affect that experience feedback from the journey.

Larry:
As you’re talking about that, I’m wondering, in your kind of practice, are there ways to… Because that’s something that my current business partner and I, he works on, like we’re constantly trying to figure out the metrics and measures that assure us that we’re on the right track and that we’ve understood the journey and the persona and the problems and are providing, in our case, the right… I think in this sense, we’re kind of like one of those small business unit you talked about.

Larry:
My role in the service design world and journey mapping and omnichannel content delivery is like, here you are with your customer, you’re at this point, you need this thing. Here’s the content you need that’s going to be mixed in with a bunch of other experience stuff. This long-winded way of getting to my question, which is how do you measure that? How do you measure what you’re just talking about and be confident that you are easing the pain that they’re feeling at those pain points?

Terry:
Well, the interesting thing about journeys and value streams is that every one of them is so different. Firstly, they don’t have to only be customer journeys. They could be all sorts of value streams, like internal stakeholders or partners or other communities that you need, but the same canvases apply, the journey, the value stream that underpins it, the capabilities, and the operating elements, people, process, technology. That structure can be applied to any of your value streams.

Terry:
Now, measuring. In every case, you’ll be measuring different metrics. Often, you can be measuring something like the time it takes settling a claim. One the common things you’d want to know is are we doing that in the time that we would expect? The structure, what it does is it allows you to really break things down. Instead of just saying, “We need to get a claim out the door in 10 days,” you can say, “Oh, well, each stage has its particular target in timeframe that you want, and we can measure the actuals for each stage so we can narrow down where’s the bottleneck across the stages with such a thing.” And then when you get to where that bottleneck is, you’ve got an immediate perception to see, is it a system technology issue, is it a process issue, and which process or which technology do we need to delve into?

Larry:
As you’re talking about that, it’s like, I can’t remember, you said something earlier where once you’ve done this and you have a understanding, you always have a current state understanding. Then, and my question about metrics becomes like a duh kind of question, it’s like, well, we understand where we are, we did something different. Here’s the change and here’s the time or-

Terry:
Yeah, exactly. That’s the great thing, because we often… An epiphany for me at one point was I was trying to figure out, how would you represent a business operating model to an organization? How do people conceptualize this thing? It’s absolutely bizarre to realize that as an industry, we don’t have a commonly accepted universal mental model for what is an operating model. How do you visualize and conceptualize it? It’s so strange. The hard part often is to try and generate that mental model.

Terry:
The way we see it is the building blocks of the mental model are the capabilities, the scaffold for the operating model are the value streams, where you put these capabilities into these stages. The lovely thing about that is there’s only generally about a couple of dozen value streams, in general, that will give you the high-level view of any given industry, and they’re very common. They’re very consistent from one business to the other within that industry. You could come up with a set of value streams for an insurance company, and you could be pretty sure that they’d be the same ones for the next.

Terry:
Industry templates are quite easy to generate. They give you a great start to get yourself going. That overwhelmingness that you kind of into that early on, where do I begin? How do I start? You can come in and you go, “Here’s a template.” How well does that represent what you do? Immediately, you haven’t gone to trying to build it. You’ve gone straight to how close does this match us? Oh, change that. Yes, I can see myself, and gradually, you get it. Once you’ve set it up, that is it. Your capacity to transform is done. You’ve got it. Now, it’s just the ongoing measures and using that structure to drive the conversations in your workshops.

Larry:
While you were just talking about that, I’m reminded, I want to quickly, I’m going to back up and talk about how we met, because I woke up on New Year’s Day this year with this crazy brainstorm about enterprise content architecture. One of the discussions that ensued from that was a conversation with Dean Allemang, who is big in the ontology… He literally wrote the book on the Semantic Web for the Working Ontologist, and he connected with you. Again, I’m really good at long-winded questions today, but one of the things that Dean has been involved with is FIBO, the industry standard for an upper ontology for financial mechanisms and stuff. Is that kind of what you’re talking about when you talk about this common mental model? Are those upper ontologies one of the ways that this kind of common understanding of an industry is ensconced?

Terry:
That’s a great example. Exactly. Every industry has all kinds of different reference models that different business stakeholder groups have been applying to try and help, particularly organizations like banking and insurance and finance, where you have a lot of interoperability and you need to be able to share information across organizations. Standards are hugely important for doing that. FIBO, for example, what it is, Financial Industry Business Ontology, it creates a reference model for all of the core information concepts in a bank, in the financial industry, so that we can all agree on what those objects are, what the data structures are, and we can have ways of generating exchange of information between the ecosystem.

Terry:
The interesting thing about FIBO is it operates just at the level of data, but there will be another standard called BIAN, which is the banking industry architecture network, which talks about all the services that a bank offers, and there will be others that’ll have a process catalog and others that will have a business capability map and others that will have security controls.

Terry:
All these different standards represent different… These are some of the different perspectives that I was mentioning that everybody’s looking at the business from their perspective, but there’s no tying together saying which data is used in which service, on which process, on which security standard, on what application. That’s what the ontology ties together so that suddenly, these things are all connected. If I change my data here, it’s going to affect that process on that application, and that might be the security control that will be impacted, and so on.

Larry:
Got it. As you talk about that, I get the benefits of an ontological understanding of your business, but it sounds like a lot of work. Who is the kind of person who’s typically charged with that? Where does an enterprise ontology come from?

Terry:
Well, in our case, it comes in the platform. You get it as part of the tool. If you’re not, if you’re trying to do it yourself, yes, it is a huge job to try and come up with one of these, and one of the things that you can accelerate. Even if you did build it, you’ve then got all the tooling to try and turn it into something attractive. That’s the journey we’ve been on to get to building our platform.

Terry:
Our customers, we bring the product in, we’re right already at the stage they’re not just saying, “Give us your catalogs, load them in, or connect to them, wherever they are, plug our API into your ServiceNow, your Jira, your Cienaga,” whatever it is, and then we can just immediately read from where they’re at. All we are doing is we’re kind of like the central nervous system that’s tying all those other systems together and surfacing the insights to the business. It can sound and feel like this is overwhelming, but the great thing is, as I said, it’s templateable in many… The industry templates can just help you accelerate enormously.

Larry:
As you talk about that, I get the benefit of that, like as the starting point and the foundation of a platform like yours. But there’s also the fact that every business is bespoke and unique and has unique strategic concerns and customers and founders and all that stuff. How is that kind of variation and variance and uniqueness accounted for in these kinds of systems?

Terry:
It’s the parameters that are unique. It is not to say that every insurance company doesn’t do claims management. Every insurance company has to figure out how to settle a claim, but it’s the actual details in the actual… How do we do that? What are our particular risk scores that we look at? What are the ways that we judge whether something should be this price or that price, and how do we differentiate and compete on the parameters, not on the structure of what we’re actually doing and the things that we need to get through to manage our business? It all comes down to the finer details.

Terry:
You can almost think of this as our vision has always been, if you could get these universal models fully instantiated for an organization, where the whole organization is plugged in, is connected, and the knowledge is connected and aligned so that any change is sensed everywhere else. The vision is a management cockpit, if you will, where all these dials and measures are being represented, the current state of the business, and you’re pulling levers as you’re reading the dials to make your fine adjustments to those parameters, and that’s how you control and optimize your business. But the mechanics of it, it has to be in place for people to get to that level of control.

Larry:
It’s almost like analogous to like the configuration thing, you sign up for some SaaS app and you configure it to your needs, those parameters in this context, are the thing that… There’s both of that, the practical, pragmatic, genuine, real-world look at it. There’s also just, I think, the human thing of like, “Oh, we’re so special and unique,” and it’s like, “No, you’re still in the insurance business.”

Terry:
Yes, you can do special and unique things, but generally you are not… Well, but there may well be whole new ways in which you go about selling your product. Maybe, for example, going digital. That was a transformation in the way that you… But what that meant was just the how, not the what. We still had to receive a claim, manage the claim, assess the claim, book the claim. We were just doing it through a different channel or a different mechanism, but the structure of what we’re doing, that’s what we’re talking about. Let’s get those structural definitions of the architecture in place, and then how we layer it, paint it, design it, configure it, that is where the creativity and the differentiation comes in.

Larry:
As you said that, you’re reminding me of the benefits of architectural thinking over analytical thinking. Is that something you’ve done? Because you had a transition, you had been working in industry, you were at Oracle and doing CRM stuff, and then you went to grad school, and you said a couple of times that it was an academic exercise. I want to point out that that Capsicum paper, that literally was your PhD thesis, so it literally was an academic exercise, but can you talk a little bit about that? Does that make sense, what I just said?

Terry:
Yeah. Well, that was it. I used to work for large global software companies. I was a solution architect trying to help implement technologies for big organizations. In that role, you’d be sent into a couple dozen customers in any given year, where we’d be trying to understand their business and say how would we implement technology to improve your business, and all we knew was the technology. We didn’t know what the business was about. I’d be left behind when the salespeople all celebrate and go on home, and then I’d be sitting on a table with a bunch of business people and trying to figure out what promises had been made and how are we going to deliver on these.

Terry:
I’d say, “Well, can you explain what you do?” And that was the epiphany, when I was like, every single time, they had almost nothing to explain what they did. They would come and get up on a whiteboard and draw stuff, and that was the best they could come up with that explained how their business functioned. It was that frustration of seeing that over and over and over that led me to say, “There must be a better way. Surely, we could at least give these people a template to say, ‘This is the sort of way you could give us information about your business that we could then automate.'” I started looking for frameworks for describing the business and I couldn’t find any, and eventually stumbled across some academics who said, “Well, come and do a PhD on that.” Off I went, and then discovered the world of ontology, and that’s how it began.

Larry:
There you go. That’s so interesting. Terry, I could literally talk forever about this, but I realize we’re coming up close to time. But before we wrap up, is there anything that’s come up in the conversation that you’d like to revisit, or you just want to share before we close?

Terry:
Well, Larry, it’s been great having this chat, and it’s always exciting to me to meet anyone that’s remotely interested in the topics of ontology and knowledge graphs. I think the thing that to me is exciting and that’s coming up in this space at the moment is the opportunities that some of the new AI technologies offer. I see such great promise for the Knowledge Graph Foundation in bringing those technologies into an organization. I often use the analogy of how the big paradox being that as individuals, as consumers, in our personal day-to-day decision making, we have access to such incredible technologies, that we can just go and ask a question on Google or now with ChatGPT, and get any kind of insight into helping us make those decisions.

Terry:
Again, we go into companies and our businesses, and it’s like we’ve gone back two decades in the capacity we have to ask questions about the state of the business and what the business is doing, just because knowledge is so fragmented by design, so disconnected, that we haven’t got the ability to query it nicely. To me, the promise of AI in the enterprise requires us to be able to pull those threads and bring them all together and create this web of connectedness that we do have outside in the consumer world, but we don’t have in our organizations. Once that’s in place, I believe the combination of knowledge graphs, enterprise ontologies, and AI can really bring the future and the potential to the enterprise.

Larry:
That’s been the talk at the Knowledge Graph Conference the last couple of years, so I think you’re definitely onto something there. Very cool. Well, oh, one very last thing, Terry. If folks want to stay in touch or connect online, what’s the best place to connect with you?

Terry:
Well, thanks for that. Our company is Capsifi, www.capsifi.com, or I’m on LinkedIn, Terry Roach, look me up. I’d love to get in touch with anybody who’d like to explore these topics. Thanks very much for the opportunity, Larry.

Larry:
My pleasure. I’ll get that stuff in the show notes, as well. Well, thank you so much, Terry. Really enjoyed the conversation.

Terry:
I did, too. Thanks for the opportunity. All the best.