An overview of the ontology-derived Enterprise Data Model for retail and commercial banks.

The presentation derived from a custom overview of the FIBO data model for a European retail and commercial bank. While every bank and data architecture team is different, challenges and solutions apply to most banks of similar size and semantic technology sophistication. This general introduction addresses the generic Everyone’s Midsize Bank, EMB.

You can read the presentation or download the PowerPoint here.

Rough transcript

The presentation you’re about to see is true. The names have been changed to protect the innocent.

Welcome back to FIB-DM. You probably already watched the Semantics for series: Semantics for managers, for data architects, for finance users. This latest installment, I called it Semantics for midsized Banks.

True, last week I met with a European retail and commercial bank and gave their architecture team, an overview of the Financial Industry Business Data Model.

Looking back at the deck, I found that a lot of the architecture team’s questions, the current state, aspirations, and the possible solution and roadmap to Semantic Enterprise Information Architecture applies to most banks of a similar size.

So, then I took the deck; I changed the name to EMB, Everyone’s Midsize Bank to make it generic. I hope you find it useful and enjoy it.

The FIBO is the authoritative model of the Financial Industry Concepts the Definitions and Relations. The Enterprise Data Management Council, the EDMC, is a global association of more than 200 Financial Institutions. They have data management best practices, and they develop and implement data standards.

Now, the EDMC  members and they’re mainly the large Financial Institutions, developed the Financial Industry Business Ontology, FIBO as a business conceptual model. It has more than 1,600 classes for Financial Instruments, business entities, and business processes.

One word brought about midsize/large size: The EDMC membership Tier A starts at 200 billion in assets under management. Midsized banks, for FIB-DM licenses, (I just copied the EDMC Tiers for my pricing), and in this document are banks with assets between 50 and 200 billion US Dollars.

Everyone’s Midsized Bank data architecture team: What you

Do: You probably do logical and physical data modeling, data management, and data integration. You have policy rules and in-house standards, and you support programs and projects. In other words,you design models and database schemas for the projects

How you do that?
You already have ERWin, PowerDesigner, Sparks, or any other data modeling tool. Maybe you have licensed a vendor data model like the IBM model, Or the Teradata model. Maybe you already engaged with the EDMC to do the Data Management Capability Models, The DCAM exercise. What are you trying to achieve next may be looking at FIBO, getting up to speed with Ontologies and Semantic Technologies, and incorporating, adhere to industry standards.

About myself, I think I’m recognized as a FIBO and Industry Data Model Expert. You’re welcome to look up the references below on my LinkedIn

profile: What Mike Atkin from the EDMC had to say: He called me a key

Participant in the work on FIBO. He invited me to speak at FIBO conferences. Before that, at Deutsche Bank, Shannon Walker wrote that I trained her team of data architects, and indeed, some of them she now calls ontologists. And before at CITI, that was still conventional data management. I was an IBM consultant for the Banking and Financial Markets Data Warehouse for seven years. After that, I consulted CITI on the BDW implementation. There, Vin Siegfried, he called me game-changing, but also, what I found nice, a good colleague and a good business partner. If you want to read it up, all look at my LinkedIn profile.

There is a chasm between semantic and conventional data management.
The large financial institutions already implemented the FIBO. However for midsized banks, for smaller institutions, there are high barriers of adaptations: The tooling, database systems, and foremost the required human expertise. That is because the EDMC specified the FIBO in ontology web language, in OWL. That is absolutely the right thing to do. However,

OWL needs highly-specialized ontologists. OWL runs on specialized databases, the so-called RDF Stores, or Triple Stores. IT departments must still support and design Relational databases. And frankly, to my knowledge, no midsized bank has an RDF store in production. That really creates a chasm between very large banks and smaller banks; and

also between Semantic Centers of excellence and the rest of the

Organization. And one word, whenever this pops up in the upper right corner: That is the education module where you find further information and more detail in this case semantics for managers.

FIB-DM is a bridge across the chasm. It makes the industry-standard available in your data modeling tool.

Looking at enterprise information architecture: From a logical perspective, we can look at the design artifacts by their Use,  by the Type and the levels they apply to. You already have data models and DBMS; you have messages; you have processes, maybe process models in BPMN. Of course on the object side you have UML. And now the new thing is RDF/OWL, and that gets deployed on RDF stores. The standard for that in the financial industry is the FIBO. Now, here is coming up FIB-DM, a twin of the FIBO, as a conceptual business data model at the enterprise level, and another twin of it FIB-UM, the Universal Model is the FIBO in UML, and that is used to create object code in Java and elsewhere. The latest model, FIB-CM, concept maps, that is a simplified, reduced semantics model for Business and Finance Users. It is in sync with both the FIB-DM data model and the ontology. What we achieve in the Semantic Enterprise Information Architecture is Model-Driven Development from the ontology down to data, message, process, and object. We have common names, definitions, and design patterns across the enterprise.

FIB-DM has 15 concepts, and they all come with an icon and abbreviation. So that it’s easy for the business to remember,recognize and internalize the concepts. From a data architecture perspective, these concepts, they are all ultimate supertypes in the data model.70% of FIB-DM entities are a subtype of one of the concept entities. The proposition is that these 15 concepts are enough to visualize design in user-friendly concept maps. In other words, we can define all banking using these 15 concepts.

The concepts and vocabulary directly derive from the data model. On the left-hand side here,for the business users, we have a concept map about a depository institution, which is a stock corporation with an LEI and has issued capital. It has an address, and also it’s regulated by the FDIC. It has a license number, which is held in a registry. So, the left side is what the business user looks at, and here we did that in MS-Visio, (everybody who has office as Visio). On the right-hand side, we see the

One-To-One correspondence to the data model. That is what the data architect looks at. In this case, you see this snapshot is from Sparks

Enterprise Architect. I left it in the deck just to show: While the other education materials usually show PowerDesigner, you can use

FIB-DM with any data modeling tool. The concepts and the vocabulary also directly correspond to the ontology. Here we have the exact same concept map on the left-hand side, and then what the ontologist looks at -the graph. (Here I took a screenshot from Protege because that’s what the European Bank is using, instead of the TopBraid that you see in the usual

Education materials. It is the same thing — a direct correspondence between the simplified business-friendly concept map and the more complex, detailed ontology graph. The 15 concepts come with a reference sheet that has the icon, the number of subtypes, the Top levels of the subtype hierarchy. And then with explanation examples. And by the way, on the FIB-DM website you can download fully scalable diagrams of the complete hierarchy. The diagram has all 81 subtypes of Autonomous Agent, in this case. The second part of the reference sheet has the most important concept relationships, again with explanation examples of the concept.

Yeah, and here is just one of the reference card as an example. We see Autonomous Agent, who is a Person,Organization, Automated System. We see that the Autonomous Agent is identified by a Reference. It governs, potentially, a Location; it is classified by an Arrangement, and Agreements may govern the Autonomous Agent, and foremost,the Thing in Role – what agent does has an identity as the Autonomous Agent. And,again look for more detail in the upper right corner – click on the education deck.Semantics for Finance Users.

Yes, this all sounds great, but what are the barriers to leveraging the FIBO for data architectures? These are some cases from my experiences. A year ago it was a New York bank that needed a schema for a new Security Master System. Of course, as a FIBO advocate, I wanted to use the FIBO as a blueprint for that system. The challenge was that the data architects are not familiar with RDF/OWL, and they have no experience in Protégé or Topbraid. My manual workaround was to write SPARQL queries to extract metadata from the FIBO into Excel sheets so that the data architects can review the definitions and content. Needless to say, that manual workaround didn’t really work out. Another case was with a Connecticut

Hedge Fund: They needed for Security & Exchange Commission compliance, a relational platform. They had my operational ontology of some 200 FIBO and Hedge Fund classes. And I had to create a database schema, relational schema out of it. And here the manual workaround again was transcribing the ontology graphs into ERWin diagrams. In other words, I spent three weeks typing in entities into ERWin, connecting them with relationships, and copying & pasting definitions from TopBraid into ERWin. Needless to say,  that was dreadful,boring, unproductive, and very error-prone. I think you at EMB will have similar challenges when you try to use the FIBO for your design. Because you probably are not yet RDF/OWL experts, and maybe have just downloaded and looked at Protégé or TopBraid as an ontology development tool. You would face the same manual workaround, meaning manually transcribing ontology design into your data modeling tool,then copying & pasting FIBO definitions. That is not productive.

That is when I was looking for solutions, so how can I get FIBO into my data modeling tool. One sidetrack: Out of the box solutions, imports into Sparx or elsewhere; they simply didn’t work. They didn’t yield a usable data model.

That is when I invented the Configurable Ontology to Data-model Transformation,CODT. How it works is that CODT extracts metadata from the ontology into an ontology metadata set. Then it’s basically ETL, Extract

Transform Load. The Transformation is in two steps: From the ontology metadata set to a generic entity-relationship metadata set, and from there the second step, converting the generic ER into a data model tool-specific ER. PowerDesigner here imports Excel spreadsheets, and here Sparx Enterprise Architect has an import for CSV files, and that is how it works. Now, maybe one last word about the Large versus Midsized banks. Well, large banks are looking at FIB-DM. You can see that for yourself with Likes and Comments on LinkedIn posts. Just a point, for them a standalone FIB-DM is not enough, simply because they already implemented the FIBO because they extended and customized the FIBO. So they need FIB-DM together with the transformation technology. For that reason, I filed a patent application with the United States Patent and Trademark Office. With that, probably next year, I will look at licensing the transformation as well.

What I found, when I first looked at the generated data model in PowerDesigner was that the domain ontology generates a perfect CDM. So here, we have an ontology graph of the FIBO with a bank that provides a bank account. The bank account has an account number. Looking at the generated CDM data model, and we see it is the best representation of the bank account, its provider, and the ID. So, the two are equivalent. As a data modeler, we can see, there are no missing or no unneeded entities and relationships in the diagram. Yeah, and here is the FIBO in Sparx Enterprise Architect. This, for a change, is a different data modeling  Tool.

I mainly use PowerDesigner, but that European bank; they don’t have PowerDesigner; they have Sparx. You can see it is for any data modeling tool. Here in the object browser, we have all the FIB-DM entities, and the packages, the hierarchy, At the right-hand side we see; in Sparx it’s called tagged values, in PowerDesigner these are Extended Attributes, ERWin calls it User-Defined Properties. So that is where CODT places the FIBO metadata. Here we have the FIBO annotations; we have special tags about the import, in particular, what was the URI for the source ontology class, or object property. We capture here semantics that are beyond the data model. So we don’t lose it –  it’s preserved as a documentation item. We can pass it on to the Physical Modeler, and the application developers. And these are in the ontology called class restrictions and equivalent class expressions.

FIBO / FIB-DM modules and packages: The top layer where, there is the generic layer, also known as Upper Ontology. We have Languages Countries & Currencies; we have SM and SKOS for annotations mainly. Here’s the domain core. The first module is FIBO Foundation. That really is the basic Lego blocks, the common bricks. These Foundation classes, they are used by all more detailed modules, like here Business Entities and FBC. So, just like you have more specialized Legos for windows, wheels, and so on. But they all need the basic bricks to build something. So, this is the domain core and extensions are for Securities, Derivatives, and Indicators. The domain core is in the Open Source model and the extensions; they available with a commercial license. More to come for the extensions: These are packages that are still in FIBO development, so they are still in DEV and not in Production. There will be Loans, Market Data, Corporate Actions, and Collective Investment Vehicles.

There were questions about version support and maintenance.Just here out of interest: As of November10, there were 143 download form submissions.

Most of the downloads were from banks and investment companies on ERWin and PowerDesigner. Now, as you can see, there are other tools. Sixteen

percent on Sparx, you see Paradigm, E/R Studio, and IBM InfoSphere Data Architect.

FIB-DM has a major annual release.We follow the EDM Council production schedule. There may be interim model upgrades when a new ontology module releases into production. Licensees with the maintenance contract get the FIB-DM version six weeks after the FIBO production release. The current FIB-DM version is s of FIBO Q4 production that was released in January 2019. The next major release comes in February/March of next year. Usually, the EDMC packs new modules into the end of year release.So, I expect to have some more of the upcoming models in January, and then by March, I have it extended to FIB-DM.

This is a path and special offer for Everyone’s midsize Bank. Our end state is to have Semantic Enterprise Information Architecture. The way to get there; you can start already this year: Adopt the Industry Standard, the FIBO Data and the Concept Model. As you are using the data model, and train data modelers in Ontology Web Language. As they become proficient, customize the FIBO to make it Your Enterprise Ontology. The difference between this approach and the approach that Large banks took is that you as a midsize bank, you don’t have to spend a million dollars and two years in training and infrastructure. You can use the FIBO content and design patterns from day one. Also, I believe, as a data modeler you will find it easy to learn a new language,OWL, and learn the tooling if you already know the content and design. Yeah, and finally, become a reference implementation, and I can teach and advise you.

Well,that’s it. Further reading and watching: On the FIB-DM website, you find the scalable diagrams of the subtype hierarchies, and also of FIB-DM modules, and also diagrams of the concept maps. There’s also there’s an educational path and visual guide to FIB. This is the track you can follow starting with Semantics for Managers for Data Architects. It also shows related articles, and so on.

Follow the FIB-DM LinkedIn page and subscribe to the FIB-DM Education Channel on YouTube. Well, thanks again for watching.