Washington Department of Labor: Referral Tracking 

We were retained by the Washington Department of Labor & Industries to determine if it  was feasible to design and build an “Enterprise Referral Tracking System.” One of the first challenges was to figure out what constituted a referral. After a few straw man definitions and a lot of polling, we came up with a short list of about 60 different types of referrals,  which were being independently managed in over a dozen major, and about as many minor, systems throughout the agency. 

The agency already has a great deal of expertise in this particular functionality. Of the dozen or so systems described above with referral tracking functionality built in, three  (RTS1, RST2 and RTS3) were explicitly aimed at potentially broad-based referral functionality. It had proved harder than it would sound to grow any of these good starting  points into an enterprise-wide system, partly because of best practices and partly because  of agile development.  

The best practices angle was that they had a great deal of experience with traditional application development, where it is far easier to build functionality around local database instances. This has the side effect of causing the system to have an increasingly larger footprint of shared concepts with the rest of the agency to support what was essentially  MDM functionality. The agile problem emerged because inevitably one program had been funded to create the RTS system and their needs were driving other projects throughout the agency. Because there was no guard, any additional functionality that the program needed, if it were at all related to referrals, was added to the scope. Often these additions were an impediment rather than an aid in getting other programs to adopt the system. 

We designed a truly elegant system. The cost of building it was estimated at about 10% of the initially expected cost. As it turns out, the entire project will cost more than that, but  still less than half what they had originally thought because most of the effort is in integrating legacy systems through SOA messaging. Since they have the necessary resources in-house, the incremental costs are far less. 

This was another on-time, on-budget project with a much better outcome than had been anticipated at the outset.

S&P Platts: Identity Resolution 

If you turn on the news and hear that Brent Crude is trading at $19 a barrel (did it really get to $19 dollars? Yes, it did, we’re living in strange times), it’s very likely that it was Platts that determined this price. Platts are in the “price assessment” business. If you need to strike a contract for an amount of a particular commodity to be delivered at a particular place at  

some time in the future, you need a neutral third-party arbiter to price that commodity.  That would be Platts. 

Over the years, they have amassed a library of 300,000 of these “symbols” of specific combinations of commodity, grade, location, terms, etc. It was the belief that the metadata within these symbols would unambiguously identify a symbol. 

We loaded all the symbols and all the metadata into a knowledge graph and discovered  with simple graph analytics that about a third of them were ambiguous. By leveraging knowledge graph capabilities, our consultants are improving data quality symbol representation to disambiguating metadata for all the ambiguous symbols. 

The other thing we learned in the process is that there are about a dozen different “kinds”  of symbols. Not different in the way that coal is different from natural gas (although there  are differences there), but different in the way that a symbol in a different unit of measure  or currency is different from its base, and the futures are different, which spreads even more differences. 

We are working with them to create a symbol management system that recognizes these differences and can create and edit symbols that are unambiguous and conform.

Proctor & Gamble 

Research & Development 

Procter & Gamble have over 10,000 people working in Research & Development. They believe that innovations in one part of the organization might offer inspiration to researchers in another part but communicating that is a challenge. The main challenge is that these researchers are in a great many domains, each of which literally has its own language. In addition, many researchers are approaching retirement age and there is a fear that the firm will lose a great deal of its intellectual capital. 

As part of this project, we worked with two groups of retiring scientists. Part of this work was to develop methods for eliciting knowledge and part was to find where useful knowledge was stored, how it was organized and how it might be accessed. We built an ontology to cover all of R&D with a minimal amount of information specific to any one R&D function. One of the key aspects of the ontology was its modularity. Fewer than 500 concepts covered all of R&D, and each discipline can extend the core with its own specialized nomenclature. 

Subsequently, the client turned the ontology into a semantic wiki and extended the core ontology to cover two other disciplines. 

Materials Management 

We worked with P&G to build an ontology for their Materials Management functions. This project showcased extensibility, one of the great aspects of semantic design. We started  the project with their Product Safety and Regulatory departments, but the project then  spread to all Materials Management functions. 

We built the ontology which has now become the basis for a project to replace many of their existing systems with one semantic-driven system.

S&P Global Commodity Insights (formerly known as Platts) provides benchmark price assessments for the physical commodities markets. As we have noted before, if you hear  on the news that Brent Crude is trading at $100 a barrel, it’s likely that S&P Global  determined this price. 

The price of a given commodity – be it coal, crude oil, or steel – depends on several factors,  and in large part it depends on the commodity’s chemical characteristics. Crude oil, for  example, comes in a variety of “grades.” A quick look at this periodic table of crude oil grades will give a sense of how much variety there really is. If you hover around and click on some of the boxes, you will see that each crude oil grade is associated with a technical specification related to characteristics like sulfur concentration and API Gravity. These characteristics determine whether crude oil is “sweet” or “sour” (depending on its sulfur concentration) and whether it is “heavy” or “light” (depending on its API Gravity). 

While crude oils have other characteristics, the market has determined sulfur concentration and API Gravity to be the most important for the purposes of price assessments. The same thing holds for other types of commodities—there are “key market characteristics” for any commodity that will be important for pricing purposes. 

While this knowledge about commodities is commonplace at S&P, pinning down the  precise meaning of “commodity grade” turned out to be a significant challenge internally to  define. This is one place where Semantic Arts was able to provide value. We identified and analyzed the various concepts underpinning the idea of a commodity and produced a clear definition. 

One might think of a commodity grade as a “leaf” in the hierarchy of commodity types.  Crude oil is the general type, while the Saharan Blend is a specific grade at the bottom of the hierarchy. This is a good first pass definition, but it fails to get at the essence of what a commodity grade really is. 

To make headway in clarifying the definition, our strategy was to learn from subject matter experts about how the concept is used in practice. A key question was: When people talk  about commodity grades at S&P, what are they truly talking about? 

It turns out that whatever else people might mean by a commodity grade, it always includes the specification having features that the market cares about. Additionally, it is specific enough to be priced in the marketplace (by S&P or anyone else). With the hindsight of this analysis, we were able to create a clear and formal definition of the concept of a commodity grade using semantic standards (W3C) to express. 

This was the first step. It provided the basis for deeper data quality checks. This becomes critical to Commodity Insights; whereby S&P’s core business is selling accurate data under constantly changing conditions. 

The second step was to create a means for validating S&P’s data that commodity grades had specifications for the relevant key market characteristics. For example, any crude oil  grade should have a specification indicating an acceptable range of sulfur concentration.  To achieve this, we developed a solution using SPARQL & SHACL that returned validation  

reports to indicate which grades might be missing specifications for certain characteristics.  This semantic method proved significantly more efficient than using Excel spreadsheets,  manual entry (mistake prone) processes. 

While we used crude oil as an example to illustrate this idea, the framework we developed can be applied to all commodities. Most importantly, it instilled automation, data interoperability and consistent meaning across multiple teams that previously interpreted commodity grade with a different lens. The solution offers easier value change implementation saving countless man hours in aggregating spreadsheets with greater data integrity and traceability. 

There were a few important takeaways. First, it can take years of working on a project to  determine what something means with confidence. Delivering a semantic layer brings data reusability and data centric principles is solving a core challenge of dissolving data silos. 

Second, it’s possible to live with an unclear definition but once you’ve cracked the semantic code puzzle across the enterprise … efficiency and accuracy of knowledge reaches new realization. A tangible benefit of being confident by knowing exactly what something means is that problems arising due to the persistence of ambiguity will be a thing of the past. It’s  now built into the standard S&P operating procedures inherently with a data-centric,  semantic driving solution. 

On a previous project we worked with Sallie Mae to build an enterprise ontology for their loan business. After the ontology was complete, they decided to outsource a new line of loans to a third-party SaaS vendor. Shortly after making that decision, they realized that the new system would have completely different screens, and completely different messages and APIs from their existing systems. 

Their existing loan servicing systems had, collectively, about 50,000 attributes. The enterprise ontology we had previously designed had 1,500 concepts. They decided to use their ontology as a unifying principle to conform the old and new messages such that their customer-facing systems would not look schizophrenic. They had mature service-oriented  architecture but had not done much to unify or rationalize their messages. 

We helped them select the DXSI toolkit from Progress Software. We created a set of programs that converted the ontology into a form that DXSI could consume. (There were  many issues around translating multiple inheritance to single and converting many fully expressed notions from the ontology into flatter representations.) 

Much of our work for the remainder of this project involved discovering at a very specific level of detail: exactly what each of the fields in each of the new system’s messages actually meant. In many cases this required extensions to the original ontology, but for the most part the extensions were consistent with the original design. In the end we extended the enterprise ontology by only about 10%. 

The new system was implemented on time with a set of conformed messages that allowed a single presentation to the customer.

Broadridge: Legacy Understanding

This firm processes some 70% of all the back office of Wall Street. They have three major systems, for different types of financial instruments and jurisdictions. The three systems are barely integrated. Bringing a client up on any of their systems is a multiyear endeavor.  Getting combined reporting from these three systems is nearly impossible. 

They have embarked on a major initiative to create a path toward integration, initially integrating the systems they have, ultimately delivering a fully integrated system. 

One of the barriers is the complexity of the existing systems. They are massively complex and built on completely different architectures. 

One of the systems was designed with an extremely table-driven design. While this made it  very flexible, it also created performance problems as well as understanding problems.  There are only two people in the world who understand all the intricacies of the system. 

We built an ontology of the functions that the system covered. We then took all the metadata in the tables that drive the processing and loaded them into a triple store. We  constructed a series of SPARQL queries that allowed relatively new personnel to pose and  get answers to complex questions regarding how the existing system works. This has become a key input into their project to understand and integrate their systems to create legacy understanding.

Teacher Retirement System: Enterprise Architecture

The Teacher Retirement Systems is one of the largest pension funds in the country, with 1  million active teachers and 250,000 retirees. They run the organization on a series of aging mainframe systems. In the late 90s, they attempted a major upgrade to their technology, but finally had to abandon that path. Since then, they have mostly been front-ending their existing systems with newer proxy systems to deal with web-based clients and the like. 

We worked with them to design a future enterprise architecture, featuring SOA and ontology-driven messages. They have begun work on some of the early projects in the plan.

Investment Bank Risk and Controls

We worked with a large investment bank who are embarking on a series of projects to further automate their back office. One of their first tasks was to understand in greater detail what all the 5,000 people in the back office were doing. They built an “Economic Architecture” that was essentially the equivalent of a continually running Activity Based Costing project. They asked managers to estimate the percentage of time each of their reports spent on a standard list of activities. However, the activity list was not stabilizing, and many managers had difficulty deciding which of the many activities they should use. As this was slated to eventually become part of the reporting and perhaps eventually the charge back to the front office for the activities performed to settle some of these very complex instruments.

We were called in to create a rational basis for the activity taxonomy. We ended up decomposing the working list of 800 or so activities into a set of orthogonal facets. What was fascinating was that the facets were far, far simpler than the long complex list of activities. Once someone knew the facets (such as financial product, market, as well as a simple set of verbs and modifiers) they would know what all the activities were, as they were just concatenations of the facets. More interestingly we discovered as we performed this that the facets provided a level of categorization that it would be possible to instrument in the workflow and source systems. (The list of 800 activities were too arbitrary to allow for automation, but he facets were closely aligned with primitive concepts found in most systems).

We completed the redefinition and got agreement on the new activities. The new activities are in production, and they are looking at applying this concept beyond the back office operations.

Email: [email protected]
Phone: (970) 490-2224