 So, good morning everybody. My name is Jim Logan. I'm from NoMagic and we're a tool vendor. We build architecture tools. You might have heard of some of these specifications like UML and SysML and UPDM and BPMN and whatever. Our tool does all of that and now we have some capabilities for the FIBO team and for the Semantic Web in general. And so, I'm the principal architect and the product manager. So, today I'm going to talk to you about how to bridge the gap between the Semantic Web ecosystem and the OMG ecosystem of architecture. I want to talk about inefficiencies in organizations and how FIBO comes to the rescue. Some practical ways to bridge the gap between these two ecosystems that don't normally talk very well. And then I have an example where I'm going to drive down from FIBO down to a typical information model just to kind of give people the gist of how things work and how things map. And then I'm going to wrap up and kind of reiterate my recommendations for how to go forward and how to map between these two ecosystems. And then I'll have a slide on the other tools that I used. So, I think that a lot of organizations are kind of resigned. They shrug their shoulders and they say, well, you know, this is just the way things have to be. We have to have a certain amount of miscommunication. We have to have ambiguous business processes. We have to tolerate some amount of misinterpreted system requirements and some, you know, build systems are not quite the right system. We have to have a way to put up with some misaligned schemas. I don't think that's really true. I think that we can do better than that. And part of the trouble with systems is that business people know business. IT people know IT. IT people don't really want to know much about the business and business people don't want to know much about IT. And so we typically build architectures and models with a particular system in mind. And we have this perennial miscommunication between IT and the business people. And we tried some things in the past. We tried doing analysis. We've tried doing glossaries and business processes and functional requirements and information models and user stories, you know, agile. And architecture and design kind of went out of fashion for a while while we kind of swung the pendulum towards agile. I think the pendulum is kind of swinging back now because we realize that you can't really build a battleship in an agile way, at least not with the original user story kind of approach. And so typically architecture is done with a system in mind. And there's actually problems with having that approach. And I'll talk about that in a minute. And so what do I mean by architecture? ISO and ANSI, they have standardized definitions of what an architecture is. And in general it's just what are the big chunks? How do they interoperate? What are they responsible for? And those big chunks can be people interacting with hardware, running software, exchanging information with other systems. And so an architecture is about how does this stuff work? What is the concept of operations? And so forth. So it can include business architectures. It can include information architectures, hardware architectures. And still it's all constructed with a particular system in mind. And so what are some examples of architectural models? Here we've got architectures of people, processes, capabilities, nodes, systems, information, you name it. And it could be that in an enterprise data world that you all will be more familiar with the information-centric things. Conceptual data models, logical data models, physical data models, and maybe even process models. But there's a lot more to architecture. So some of the consequences, the technical consequences, are that your business processes get ignored. Your databases have shortcuts. They don't align with the business. They're too expensive to refactor. The business person says, you know, hey, I want this new feature. You say it's going to take you at least six months to make that change. Why? And probably because it's misaligned with the business. System architectures have misunderstood requirements. They have integration misunderstandings where the things that are put into the information exchange were misinterpreted and the things that get pulled out of the information exchange are misinterpreted. And then mismatches for services between the sender who wants to get some sort of a service and the service provider who provides the service, they're not on the same page. They're not well documented and so forth. And so you get a misinterpretation of exchange information again. And so there's some pretty dire financial consequences of misalignment. And, you know, Gartner talks about, you know, 25% runaway budget and 50% higher failure rate for projects that are greater than 1 million. One in six have an average cost over on 200% and a schedule over on a 70%. Why? Why are these so bad? We're losing 100 up to 150 billion per year in the US. So is this due to miscommunication and misalignment? I think it has a lot to do with it. So what if we could create a durable model of the business without a system in mind? What if we could kind of ignore a particular system and model how the domain works? Not just the business processes in BPMN, but what do the things mean? Well, we actually have that. FIBO has done this for us. It is doing that for us. So they're bridging the gap between business and technology by precisely defining what these concepts are. And it's a model of meaning. It's not a design model for a particular database. It's not a model for a particular system. It's a model for any number of systems, and it allows us to semantically integrate systems if they all pin their definitions of, say, columns and tables to the same concepts in FIBO. If you have a couple of systems that do that, then you know that this column means the same as that column, and you know that you can interoperate and that you can send information between the two systems. So what is it that makes FIBO so different and so useful? Well, it defines things using criteria and logical axioms, which is kind of a technical gobbledygook way of saying, basically, it's criteria that when you're examining something, you can apply and say, does it meet these checkboxes? Yes. Okay. I know that this sort of a thing, and the light bulb goes off, and you know what it is. And it works in reverse, too. If you look at something in FIBO and you look at the criteria, you can figure out what in your data or what in your architecture meets those criteria and is that sort of a thing. So just some examples are, you know, if you say that that's something that gives live birth and produces milk implies that something's a mammal, then when you examine something and if it produces milk, you can say, ah, it's a mammal, because my criteria tells me so. So we can use this to define architectural elements. All the different kinds of architecture I talked about, not just information architecture. And we can also define data elements for semantic interoperability. And we can also constrain the possible interpretations of a model. Usually, an information model is very open to interpretation. And I've actually worked on projects where there were six different groups of people all putting data into the same tables in different ways and pulling it out in different ways. And there was no interoperability, even on a team that was sitting next to each other for months. So it helps to identify false interoperability and constrain the possible interpretations. So how is an ontology different from a data model? An ontology is about unambiguous meaning. What is the criteria? What are the terms and these things are vetted with business people experts? They say what's true about a domain would exist in a domain and they're all about clarity. Whereas a data model is about how to organize and structure data. How do you put things in the fifth normal form? What data are you going to record? So, you know, this is an example. And ontology might tell us that a person's eye has measurable visual acuity. That's something that's measurable. It doesn't tell you that you must measure it. And it doesn't tell you how often you're going to measure it or how you're going to structure the measurements or how you're going to encode the bits. That's what a data model is about. So another example is that a personnel record doesn't go to jail when somebody breaks the law, a person does. So an ontology, the subject of an ontology is things in the real world. When we talk about a person, we're talking about these people. We're not talking about data records. And so, people in IT have been conflating these things for a long time, and that sort of works, but it can lead to miscommunication and confusion. So, the bottom here is a famous painting called The Treachery of Images. And it says in French, this is not a pipe. Well, it's true. It's not a pipe. It's a picture of a pipe. And so we conflate the picture of the pipe with the real pipe, and this can cause all kinds of confusion. So, FIBO exists in the semantic web ecosystem. Architecture exists in the omg or ecosystem largely. And these things, they haven't done so well in terms of interoperating. So the omg, by the way, the omg ecosystem is responsible for things like the business process, modeling notation, the unified profile for dodaf and modaf for dod, sysml, the system modeling notation that's used for JPL to model rockets, for example, and the unified modeling language. And so, how do we bridge this gap between the semantic web ecosystem and the omg ecosystem of architecture? So there's a couple of bridges, and there are still others that are sort of forming. So, by the way, the omg ecosystem is also based on MOF, the managed object facility, and the unified modeling language. And so, when I talk about uml profiles here, I'm talking about ways of extending the unified modeling language to be able to model a domain in the real world. So there's a couple of bridges here. One is the uml profile for the ontology definition metamodel. That's called ODM. And the bridge number two is the uml profile for semantic information modeling for federation. So, ODM has been around for a while since 2008. And it's a faithful graphical representation of l2. And it's used to produce parts of FIBO. So here's an example in the lower right. And here's an example bigger of what that would look like. So this represents all of the axioms in al very faithfully. Bridge number two is the semantic information modeling for federation. This is in the standardization process at the omg. It provides semantic interoperability. And it provides more of a molecular approach rather than an atomic approach to semantics. So there are things that you can say which is boxes and lines that mean a lot of things in al. So you don't have to say all those things in al. The cameo concept modeler, that's my product at no magic. It's a growing subset of stem. So we are actively contributing to SEMF and we are the reference implementation right now. And so here's an example of what that would look like. And this notation is something that's been successfully used with subject matter experts for a number of years. I started using this particular kind of notation around circa 2005 with the general services administration. And we put this notation up on a wall. And we would visually take notes while the subject matter experts were telling us about their domain. And we'd walk away with notes that we could do something with. And that we could assimilate into a larger model. And then we could generate natural language glossaries that would read the models and read the models in plain text out to the subject matter experts and they could go through and say that's wrong, that's wrong, that's right. And they can do that without even looking at the human typed in definitions. If you have the criteria specified well enough. And so the subject matter experts would actually see their notation, see their domain on the wall and say that's not right. That thing is not a kind of that thing. And that thing doesn't have that many things. They would correct us and we'd get this immediate feedback. So this notation is actually field proven. So here's a side by side example just so that you can get a feel for the two notations. The one on the left is ODM, the one on the right is SINF. And there's a relatively simple example. The one on the left is actually lifted straight from the Fibre Foundation specification from the OMG. I've literally just copied and pasted out the specification for this. And then I reworked it in CCM. Those are identical semantics. Here's a side by side, a more complex example of a person having a variety of different kinds of names and how some of these names are equivalent to other kinds of names and how some are sub-properties of names and so forth. And then here's an automatically generated glossary. And this is just one example of how we can read out in plain natural language to a subject matter expert and go through with a red pen and say, no, this is wrong. And so we've got something called the Cameo Collaborator that allows us to publish this to a website and the user can go in and they can actually draw red Xs and mark things up and type in the correct definitions and that goes back into the model through a person. So the Cameo Concept Modeler it imports FIBO. It makes FIBO easier to learn because you can drag and drop onto a diagram and it automatically lays out a diagram for you. It helps you kind of swim through the concepts and the properties. And it's proven to be understandable to business users. So if you customize FIBO for your own purposes, which you should do if you're using it in your enterprise, you want to have these nice tidy diagrams that you can confidently show to business users and know that they're going to understand them. And it generates natural language glossaries. And it's familiar to architects because it's just plain UML. And I shouldn't say it's plain UML. It's kind of an interpretation of UML. When you put the profile in the package and you say that this is a concept model, it changes the interpretation. And what that allows you to do is it allows you to align with a variety of models. Analysis, architecture, OO models, information models. And it allows you to define things in those architectural models in one model of meaning. And so here I'm showing CCM generating AL, importing from AL. And you can see that there's a lot of overlap between CCM and UML. There's only a little sliver of additional expressivity that we've had to add. The rest is all just an interpretation of UML. So now on to the next part, which is the practical solutions for how to avoid all this wastage and how to bridge the gaps. So the most fundamental thing is align with a model of meaning like FIBO. Align your processes, your requirements, your services, your databases, your software. Align all of these concepts. Customize FIBO for your own organization. Make it something that is specific to your line of business, for example. Generate a natural language glossary. Have the subject matter experts validate the model. Make sure that they're on board with what you're modeling and that the terminology feels right to them and that sort of thing. Although you may not always get 100% agreement across all the lines of business and so forth. That's part of why FIBO and the Semitic Web is better is because you have logical definitions for things and you can largely put aside the terminology. And then use tools that bridge these ecosystems. Use ODM, use CCM, whatever you like, but bring the Semitic Web into the architectural OMG ecosystem. And align all of your definitions. Align your models. Transition FIBO. Okay, then you want to take FIBO and transition it to analysis and information models. You can do this easily in CCM because they've looked just like normal UML models. They can look like analysis models, information models, whatever you like. And then generate software and schemas from one information model. You can generate from one model by convention. You can generate DDL, you can generate XML schema, you can generate JSON-LD, you can generate AL, whatever you like. And then map your existing information models from the bottom up. You know, read in your relational schemas and your XML schemas in your national information exchange models and map them to FIBO. That'll help you to get some significant interoperability. You can start easy and just do the classes or you can make it more complete and do property chains through FIBO and say that this property chain is equivalent to this column in a table. So here's an example of FIBO foundations in the pink on the top. And what I've done is I've specialized this for some fictitious purpose so that I can have an organization, basically a company that acts in a role as an employer employing people who act in the role of employee. It's a pretty simple example and this is actually probably going to be largely unreadable. Basically there are things that play roles, an employer plays the role, is the role played by an organization and the role that it plays is as an employee or I think I said there's actually a problem that we're resolving in FIBO about roles and things in roles. But the gist is that we've got several things that have been kind of broken apart or atomized if you will. They're going to get conflated for an information model and here for an employee you can see employed person and employee and person down there at the bottom and in position and so those turn into an information model that looks kind of like this where you've got company and employee, you've got a position and this thing can generate DDL, XML schema and whatnot and so the way that you do that is you cherry pick from FIBO. You say that for example that you want has given name and has surname and those are the things that that exist. So can I point? So we have surname and given name and those would map to FIBO and so you also want to collapse FIBO. A lot of times you either don't want or don't need all these atomized details and you can kind of combine things and conflate things and a lot of times people go too far in this and they conflate too much. So these three things, person, employee, person and employee get conflated into employee which is just one which would turn into one table with an ID, a surname and a given name for example. And then we get into the class traceability. This is for the simple example of how to do some semantic interoperability mapping. So down here on the bottom actually I have a little LED thing. There we go. So here we've got the example information model. We got company, employee and position and here we've got FIBO. We've got company, employed person, employee, employer, employing company and position and we're showing in this traceability matrix just by double clicking here you can say that company maps to or realizes company and employee realizes a couple of things that maybe are being conflated. One is employed person, one is employee, position, maps to position. So that's a simple way to start mapping your model of meaning to your architecture. And by the way this works for all kinds of architectural models not just for information models. You can do this for your BPMN processes and you can do this for your systems and your services and everything else. Oh another thing to point out just to produce any confusion. These numbers here are basically summarizing how many things are in this column and this is how many things are in this row. So one, two, three, mappings and the reason I point that out is because it gets more complicated on this next screen here. This is actually different levels of nesting and different levels of nesting of numbers and so forth. But the gist here is that under company there are some properties ID and name for example and employee ID and surname. By the way this employee and this yeah this this employee here is actually would be would get replaced in a relational database with an intersect entity or other things. This is basically a foreign key primary key thing but the gist here is that ID and name and ID and surname. I have a mapping to something in FIBA. So surname maps to has surname. And so last slide is the tools that I used here the cameo concept modeler and magic draw for the for all the diagrams. So that's it. Thank you. Okay I'm going to have time for questions. As I said this is cameo this is the tooling that right now only no magic has but that's not the goal. The goal is that this is based upon a standard so all of you can who are tool vendors can actually do exactly the same thing that's what I'm expecting. Questions for Jim. So I have a question. Okay. So really good. I think the simp and it's some simplicity. You've taken a very complex mapping and you made it readable which which is very good. Question that I have is are you do you have on your roadmap are to our ML mapping. So if I have for example a need to map between my ontology FIBO and my physical instances through DDL because I want to do a virtual federated query using my ontology to my legacy data. Are you able to generate the art to our ML for those mappings. That is a goal. Yes. We want to be able to generate if you say that. Okay let me Yeah. Sorry about that. So just to be quick. I've asked Jim if he is able to generate our two RML mappings so that I can map between my ontology FIBO and my relational tables for example. Right. Thanks. So the answer is yes that is one of the goals of simp is to be able to generate that that our two RMF and so our ML sorry and and not be limited to just that. We want to be able to degenerate code if need be that will transform for example a relational database into the national exchange information exchange model and then back from the information exchange model to another relational database. So it sort of transcends all of that and is more technology neutral. But the idea is that you would be able to generate all of these things from a simp model when you when you map the information model to the concept model. Any other questions? So there are some people who say that you need an alt mail in order to get a good meeting. Does it seem like there is a quality reference for a quality reference for a meeting? Right. It seems like you haven't got it. Oh well. Okay. So I think the question let me restate it. I think that you're saying that there are two schools of thought. One is that you need an alpha male who says this is the way things are and subject matter experts who as a team tell you the way things are. Too many of them. I'm sure. And I think that the answer is that you need a combination of both. You need somebody who understands what the subject matter experts are saying and uses it to inform the model and then that you create this model and you can use things like natural language glossaries to get their agreement. And you can use things like these simplified diagrams to get their agreement. And in my experience it's all about the way that you present this to the group to get the heads to nod. And so if you can rather than present a big horse blanket, you know like an ER diagram you might have seen that takes up a wall. If you can have these little focused diagrams and say do we get agreement on this little bit right here? Yeah. Okay. Let's move on. And you move through this thing and you get everybody. The General Services Administration was like this. We had different offices all across the U.S. that didn't agree with one another. They did business differently and they used the same terms to mean different things. We got agreement across the whole U.S. So I think it's a combination of you know having an alpha male, somebody who's strong enough to understand what's being said and is strong enough to kind of yank out the abstractions and simplify the model and then bring it back to them and say are these things correct? A formal approach. A formal approach. So would you recommend the issue that we were going to start with glossary? Do you recommend going to this approach? I would. Well you can start with yeah okay so I think with the question is about governance and you know would I recommend using a glossary kind of an approach or would I recommend more of a formal approach? And I think that you start with an informal approach getting the definitions and what not and you can like I say you know up on the wall you can actually make a scratch model of what they're talking about and then incorporate this and abstract this into a simpler model and then give this back to them in a natural language and they should see that natural language reflected back at them. Okay thank you very much Jim.