Work

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

This investment bank is required by regulators to assess the adequacy of their controls on a quarterly basis. This is a very labor intensive process, as there are more than 5,000 controls that have to be assessed independently.

In the process of building an ontology of financial risks and controls, we discovered that while everyone “knows” what risks and controls are, the act of creating formal definitions for these core concepts shone a light on the fact that there were multiple definitions of risk and control that were being used interchangeably. We were able to build a very rigorous ontology in the area, and gained agreement on what all their terms meant, and how they mapped to current concepts.

As far as we know they haven’t yet incorporated this into their evaluation systems, but they have the materials they need to should they choose.

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

We were retained by L&I 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 had 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 to build 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.

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

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.

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 end points for potential address change was daunting.

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

Sentara is an integrated health care organization, including hospitals, clinics, home health, assisted living and health insurance. They employ 23,000 people, primarily in Southern Virginia. We worked with them to build what we believe to be the first integrated ontology for healthcare delivery.

After building the ontology we worked with them and 3 Round Stones to build a proof of concept mash up for asthmatics. This proof of concept took data from their EMR systems on asthmatic hospital admissions and combined it with data from other sources. The admission data was real, but anonymized. A full roll out would have essentially the same functionality, but would need strict security to ensure that only the patient had access to this data. The mash up brought data from EPA collection sites on detailed composition of the chemicals in the air. The mash up allowed patients to review exactly what was going on with the air in their neighborhood on the day of their admission.

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

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 we were promoting 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.

We are building a distribution system for this wine importer and distributor. The system is based on an enterprise ontology of their business that we built, and is being executed in a fully semantic environment.

L&I, 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.

We worked with this leading providing of legal and medical knowledge to build an enterprise ontology for their wide-ranging content. In addition to building an ontology for their case law and statutory product lines, we worked with their Master Data Management Initiatives. They have over 30 MDMs in various stages of development with logical data models. These models (and therefore the MDMs themselves) were integrated manually, in a somewhat ad-hoc fashion. We built tooling to convert their existing logical models into a single integrated ontology, where the integration points were far more obvious. From there we built tooling to convert the ontology back to a set of similar, but now conformed, logical data models.

One of the shared services we designed in the L&I long-term plan was "Web Facing Services."  When it came 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.

OFM was facing the prospect of replacing their aging legacy financial system. They were considering implementing a packaged ERP system for this purpose. They also recognized that such a system would need to interoperate with dozens of existing systems.

We were called in to help work through the logistics of how this interoperation could be achieved. Because of the scale of most ERP projects, most people assume that the new system will cover much more of the existing functionality and that traditional integration will be far less important. That was not what we found at all. Many of the functions of existing (and in-development) applications would not be replaced, and therefore systems integration would be a key issue. We designed a high level Enterprise Architecture both with and without an ERP package, and showed what the key messages would be.

We also did some ontological design of their coding block as the ERP system would have drastically overhauled it, and we needed to understand what aspects of it were essential going forward.

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

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.

Our first project with Labor & Industries started as an investigation of what dependencies their many applications had on technology that might become technically obsolete, thereby putting them at risk.

We did this, and developed a high-level conceptual model, "as-is" architecture and a detailed dependency diagram that revealed many deep and subtle risks to their system.

We were then retained to construct their long-range vision and strategic plan. This was the first time we had built an information system plan with a ten-year duration, but this was what was appropriate. They have been working toward this plan, with adjustments as things change, ever since.

"Semantic Arts were crucial to helping us define and stick to our Service Oriented Architecture plan and implementation. They have been pleasure a to work with; and always had our interests and capability foremost in their minds. I wouldn't hesitate recommending them for any task, particularly those that are design intensive."

Shelagh Taylor
Deputy Director [CIO]
Washington State Department of Labor & Industries

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 a mature SOA 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.

We have done a series of projects with Colorado Child Support Enforcement to help them understand, at a high level, how their future systems might look when they are partitioned, when they incorporate an SOA architecture and when they conform to a common semantic model.

We are currently working with COCSE  to help them create a strategic alternative to the conundrum many agencies face. They are being encouraged to implement a "transfer system" which is software that has been developed at another State's Child Support Division. While the software price tag of $0 is tempting, the implementation price tags are quite steep. Most states are spending in the $100M to $150M range to implement systems which are arguably only marginally better than the ones they are replacing.

Stone River was the workers compensation division of Fiserv. (It has since been spun off.) They were interested in applying semantic technology to their Enterprise Architecture. We taught them OWL and RDF and assisted them on their domain modeling and high-level architectural planning.

ESD manages Unemployment Insurance and Claims and have a very active program to help people get back to work. We were engaged to help them determine a strategy for integrating what had become three major systems all geared toward getting out-of-work workers back to work.

One system was essentially an extension of the State's Welfare system and dealt with TANF recipients. Another was an extension of their claims management system and the third was a system for the general public. Pretty much everything about each of these systems was different, down to what they called the person who was looking for work: in the TANF system he or she was a ‘parent,' in the Claims system he or she was a ‘claimant' and in the public system a ‘job seeker.'

We built an ontology that reconciled all these views. This project occurred just as the recession was picking up steam, and the State had put a moratorium on capital spending on software projects. To address this, we created a plan that divided what was needed into 19 small projects budgeted at a few hundred thousand dollars each. They were able to fund the initial projects out of the operations budget and were able to proceed despite the capital spending freeze.

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.

We were retained by the leading provider of Student Loans to build an Enterprise Ontology.

We conducted over a dozen workshops and facilitated brainstorming sessions and many dozen more one-on-one interviews, and reviewed reams of documentation. In the end we built an Ontology that represented the complexity of their business in just over 1,000 concepts, including classes and properties. This is a dramatic reduction in complexity from the data models of the systems being used to run their business which have far in excess of 50,000 tables and attributes.

The value of this reduction in complexity is a great strategic asset. Going forward, it means that new systems built to conform to the shared model will automatically be in conformance with each other. Integrating existing systems to each other can be done through the lens of the shared ontology, which, besides being much simpler, has the benefit of not being tied to legacy concepts. This truly is building a data bridge to the future.

One of the open questions with something as broad as an Enterprise Ontology is: does it really cover the breadth of the organization and does it have sufficiently granular data to represent all the details that are involved with the many applications that it represents? Our original test case was to be a document management system that was being implemented in parallel with our Ontology. The idea was that if the tags that were going to be implemented in the document management were aligned with the concepts in the ontology that primarily described data in the structured systems, it would then be possible to achieve one of the holy grails in this business: the integration of structured and unstructured data.

Unfortunately, the document management project was cancelled before we could test the theory, but as we describe in another use case, another project came along and provided a different use case: use the Enterprise Ontology as the basis for alignment of SOA messages between legacy systems and a newly outsourced service.

As we describe in the SOA case study, we were able to use the Enterprise Ontology to drive down to field-level detail for the SOA messages. It required about a 20% increase in the core ontology (mostly in creating a bit more detail for specific financial transaction codes and the like) and we added two other lower-level ontologies, one specifically for mapping to the legacy systems, and one to help describe concepts that only occur in the SOA layer (message headers and the like).

We worked with the CIA on a project that including long-range architectural planning as well as strategic planning on how semantics could be applied to the Agency's mission. Due to issues of national security we are not able to reveal any more of the details of this engagement.

ISPC retained us to help with risk assessment and planning for their upcoming ERP conversion.

Harvard Pilgrim is a major healthcare insurance company in New England. We had done some training and high-level design with them. When it came time to begin designing their SOA messages they asked us to help them select tools to enable this. We prepared requirements unique to their situation, scouted for and found all the products that could help with this. (At the time, Message Modeling was not a vendor product category,)

After reviewing the vendors' purported capabilities, we narrowed the field down to three and led a "bake off." We constructed a representative scenario and had each vendor model it and demonstrate the production and maintenance of messages based on it.

Prior to the housing bubble bursting, Freddie Mac had three separate Enterprise Architecture groups. We were participating in a project that attempted (with only partial success) to find some common ground between these groups. In the course of the engagement we built one of the few artifacts that has persisted, as least as of the last time we checked in, which was a detailed "as-is" diagram of the major applications and their interrelationships.

Commerce One was one of the early players in the on line marketplace space. They had hired over 500 sales people to promote their site and services, but few understood the economics and technical details of this new paradigm.

We designed and built a corpus of data to provide the context that this sales force needed.

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

"Dave McComb is brilliant, easy to work with and delivers what he promises."

-Bob Blewis
IT General Manager
World Minerals, Inc.

We have conducted our Ontology Design Training or other customized workshops for the following firms:

• MD Anderson
• Mimos Malaysia
• IRM Sweden
• SPAWAR (US Navy, Space and Naval Warfare Systems Command)
• Reed Business, Inc.
• LexisNexis
• Fiserv
• Joint Planning and Development Office
• Chevron
• Sabre
• Lockheed Martin
• APM Music
• Eli Lilly
• Port Townsend Paper
• IBM
• Sentara
• Wells Fargo

We also co-founded the Semantic Technology Conference and have delivered dozens of sessions through that as well as at Enterprise Data World and many DAMA chapters in North America.