Michael Atkin

World Minerals: ERP Conversion Feasibility  

World Minerals is the largest producer of diatomaceous earth and a major producer of several other industrial materials. The infrastructure upon which their internally developed ERP system  was based had become obsolete. This included pretty much the whole stack: DEC VAX operating system, Alpha chips, the Rdb database, Cobol and green screens. 

They were contemplating implementing a packaged system when they contacted us. After a great  deal of research, we concluded: 

Because their current systems had some very complex built-in requirements that no ERP package supported, a package system would require a great deal of customization and extension. An automated conversion to modern architecture would be feasible, more cost-effective and less disruptive. 

They opted to go the conversion route. They contracted with an implementation firm who did a partially automated conversion, but who did come in close to our estimate, and they have been  using their converted systems since. 

Washington State: SOA Design and Ontology 

In our initial engagement, we did a rapid but detailed review of 200 applications, interfaces,  current initiatives, long-range plan, and a new system being proposed. We found several  areas where they could leverage work in progress to speed up their new project initiative,  and several areas where, with a slight change in scope and priority, the new initiatives  would actually reduce the amount of redundancy and inconsistency.  

We helped them build a high-fidelity depiction of their current “as-is” state. The content from an existing, unread 400-page report was rendered, and massively updated, to a very large graphic of the as-is condition. We then worked with them to define their long-term  SOA architecture with shared services.

Washington State: SOA Design 

The long-range plan at L&I called for organizing their future application initiatives around shared services and shared messages on a message bus. 

In this project we created detailed requirements specs for the dozen major shared services and created an inventory of the key messages they would need to form the backbone of their Service Oriented Architecture. 

One of the interesting early wins was with their Accounts Receivable system. They had just started an AR project, and we convinced them to think of AR as a service rather than an application. They had discovered that 23 of their 200 applications had implemented AR  functionality and this project was intended to rationalize this. The pilot application to be converted (Claims Overpayment) wanted to implement an AR message that was highly specific to claims overpayment and, therefore, would not be reusable. This was contrary to the idea of reusable messages. 

We did a bit of semantic modeling to find the commonalities and differences and constructed a common message that had variable payloads for the few fields that really needed to be specialized for each case. On a follow-up visit several years later, they  reported they have successfully converted all 23 of the satellite AR functions, which has  provided benefits including consistent revenue reporting and a single place to check to see  if someone owes the Agency money before they pay them from their Accounts Payable  systems. 

Washington State: Secretary of State 

We were engaged to perform a feasibility and requirements study for the Corporations and  Charities Division of the Office of the Secretary of State. In our proposal we included  developing a semantic model to help clarify the feasibility and requirements. Another key part of the requirements was to examine some 2,000 individual statutes to identify any rules embedded in the laws and determine if they would need to be reflected in the new system. 

If we had any regrets, it was that we hadn’t done the semantic work earlier. We believe that the explosion of schema complexity is a product of scale; most of our large clients have severely stove-piped systems which lend themselves to high levels of redundancy.  Our other operating hypothesis is that the widespread adoption of packaged systems is  another major contributing factor to schema bloat. But we found the same level of schema  complexity at the SOS, where the scope was small and there were no packages  implemented. 

Their existing systems, which were still highly paper- and manual workflow-intense, were supported by four databases which consisted of 250 tables and 3,000 attributes (columns).  We built a semantic model that unambiguously defined all their key concepts and then reduced it to a model they could implement with relational technology. Due to the language in the RFP we were precluded from doing the implementation and they were not ready to do a semantic implementation on their own. The relational version of their new system was completely online and had more functionality than their existing system and had only 20 tables and 110 unique attributes. This was a more than 25-fold reduction in complexity and was instrumental in their decision to build a custom system. 

We say we wish we could have done the semantic model first (there were other factors that dictated our sequencing) because, had we known how simple the semantic model would be, we would have been able to do the statute-to-rule exegesis straight to the semantic model terms. The extra effort we introduced with interim terms far exceeded the effort we spent in building the semantic model. 

The project finished on time and in budget, and they are now working on User Experience,  which they would like to solidify before they begin the build in earnest.

Washington State: Entity Identification

We were retained to help with this two-pronged project. One prong was to create a feasibility study to determine whether collecting additional data from employers would aid  in targeting workplace safety inspections. 

The other half of the project was to do a high-level redesign and feasibility study on how  they were tracking addresses and business locations in their many applications. It turned out that there were nearly 100 different places in applications where location and address were being maintained. This was a major issue as they were embarking on an initiative to provide customer self-service to many functions. The multitude of endpoints for potential address change was daunting. 

Through ontological design, we first helped them clarify the differences between a work location, a work site and an address. We also created a high-level design that accommodated the many different needs for addresses and locations without being overly burdensome.

Washington Department of Labor: Web Services

One of the shared services we designed in the Department of Labor & Industries’ long-term  plan was “Web Facing Services.” When it was time to implement this, they asked us to help them define the requirements and select a software product on which to base the service. 

Our original concept featured a service that would consume SOA messages off their message bus and compose them into a browser. This was essentially the design of a mash-up service, long before the term had been coined. We created a set of requirements and helped them select and configure the Plumtree product (which was essentially a portal product) to do what we intended.

Washington Department of Labor: Security

The Department of Labor & Industries, like most organizations, has implemented security separately for each of its applications. The more applications you get, the more  redundancy is introduced, and the more likely it is that you are inconsistently applying the  law and your own internal policy. 

We began this project with an exercise we called the “exegesis.” In this case, it was an exegesis of all the laws, regulations, and policies that applied to data security within the Department. In addition to a lot of reading and excerpting, this required semantic analysis,  as each of the laws had a different aspect. Some of the laws (such as HIPAA) discuss patients’ rights. A special subclass of workers, injured workers who have been treated by medical professionals, are patients under this definition. There were dozens of such nuanced distinctions. 

From this we constructed a set of rules that needed to be implemented in order for the applications to comply. This was also at a time when the State was beginning to open up its system to the general constituency, and therefore the number of users was about to go from 3,000 mostly internal users to up to 3,000,000 total users (workers, employers, and providers in the State). 

We built a set of requirements and brought in all the usual security software suspects. At the time, the business models of these companies did not allow them to separate  Authentication from Authorization (they priced their products based on number of authenticated users). However, the State was mandating the use of its own Authentication service. We found no vendor who could solve the Authorization requirements we had without including a redundant Authentication service. While we were disappointed, one of the analysts on this project was elated. “In the past we would have selected one anyway  and dealt with the fact that couldn’t handle our requirements separately.” 

As a result of our findings, we designed a custom shared security service, which was then let to an implementation company in a competitive bid. In our original design the service would have relied on a rules engine to evaluate the authorization rules. Perhaps because we had done such a good job on the exegesis and significantly reduced the number of rules, the implementation team hard-coded the rules. The service has been in use for over five years; all new applications use it, and existing systems are being retrofitted to it.

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 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. 

With a successful 200-year track record in developing extensive and diverse product lines by leveraging chemistry and science, this global innovator was embarking on a new era of discovery to shape a better world. 

Categorization of products and the relationships between those named entities were difficult to describe in traditional taxonomies and “systems of systems”. Over the course of  2 centuries massive amounts of complex information had been arrogated, however it didn’t give a full picture. The patterns of data intersection for decision-making were lost within the siloed systems. For greater predictable business insights based not only on structured data but unstructured documents the need for easier access and interoperability was a primary goal. 

A CoE (Center of Excellence) was formed to accelerate R&D development, analytics and  finding of data to advance innovation with greater speed and reliability. A secondary mission was to socialize this capability to the broader community. Ontology development and tools to harmonize information were a foundational part of this data enrichment strategy, but in-house skills and data-centric modeling expertise were insufficient. It was necessary to develop as a core competency. 

Semantic Arts consultants were engaged to bridge this critical ontology and semantic capabilities gap. Our strategic advisory service offering brought over 25 years of practical implementation learnings and educational workshops to deliver a series of focused topics that met broad expectations of a teaching library. Recorded videos are now available on  the company’s enterprise intranet to traverse the complexities of information silos by enabling knowledge graphs, ontologies, and data-centric thinking. 

Topics include – Introducing Semantic Technologies and Ontologies, Introduction to OWL,  Introduction and Hands-on with Protégé and Property Rules, Understanding Class Relationships,  Expressions, and Property Restrictions, Semantic Triple Visualizations, Ontology vs. Taxonomy,  Topic Extraction and Weak Signals, and UI Visualization with Knowledge Graphs 

In parallel Semantic Arts are engaged with a division focused more on enriching and unifying 19 different data repositories into an ontology. The goal is to model relationships between the concepts, substances, and components for describing the products in a disambiguous manner to eliminate data duplication, increase metadata clarity, and eventually incorporate ML and NLP capabilities. We’re collaborating with the client to structure a roadmap for implementation. A projected iterative, agile approach by using our  predictable (rinse and repeat), Think Big / Start Small methodology will be employed to  guide and instruct in this digital evolution.

This effort to interconnect information assets for discovery complements and aligns with the broader digital transformational for bringing “miracles of science” to realization.