Semantic Arts exists to shepherd organizations on their Data-Centric journey.
Our core capabilities include:
• Semantic Knowledge Graph Development and Implementation
• Legacy Avoidance, Erosion, and Replacement
We can help your organization to fix the tangled mess of information in your enterprise systems while discovering ways to dissolve data silos and reduce integration debt.
What is Data-Centric?
Data-Centric is about reversing the priority of data and applications.
Right now, applications rule. Applications own “their” data (it’s really your data, but good luck with that). When you have 1,000 applications (which most large firms do) you have 1,000 incompatible data silos. This serves to further the entrenchment of legacy systems, with no real motivation for change.
Data-Centric says data and their models come first. Applications conform to the data, not the other way around. Almost everyone is surprised at the fundamental simplicity, once it’s been articulated.
It sounds simple, but fifty years of “application-centricity” is a hard habit to break. We specialize in helping firms make this transition. We recognize that in addition to new technology and design skills, a major part of most projects is helping shepherd the social change that this involves.
If you’re fed up with application-centricity and the IT-fad-of-the-month club, contact us.
Read More: What is Data-Centric?
What about those legacy systems?
The move to a more data-centric architecture requires thoughtful planning. Early phases look more like a surgical process of dealing with legacy applications in a way that realizes quick wins and begins to reduce costs, helping to fund future phases. Usually, it looks something like this:
-
Legacy avoidance: The recognition that a firm has slowed down or stopped launching new application systems projects, and instead relies on the data that is in the shared knowledge graph.
-
Legacy erosion: Occurs when firms take use cases that were being performed in a legacy system and instead implement them directly on the graph. Rather than wholesale legacy elimination (which is hard), this approach allows the functionality of the legacy system to be gradually decommissioned.
-
Legacy replacement: Once enough of the data, functionality, and especially integration points have been shifted to the graph, legacy systems can be replaced. Not with “legacy modernization” systems, but with lightweight standalone use cases on the graph.
Read more: Incremental Stealth Legacy Modernization
-
ABOUT US
<p>Learn more about our mission, our history, and our team.</p> -
THOUGHT LEADERSHIP
<p>See how we are leading the way towards a data-centric future, and those who have taken note.</p> -
PROBLEMS WE SOLVE
<p>Discover how we can help you along the journey.</p>
Taking a different path STARTS NOW. Become Data-Centric to simplify and enhance your enterprise information landscape:
5 Business Reasons for Implementing a Knowledge Graph Solution
1. Comprehensive data integration
2. Contextualized knowledge discovery
3. Agile knowledge sharing and collaboration
4. Intelligent search and recommendation
5. Future-proof data strategy
Integrating semantic capabilities into enterprise business processes has been the foundational shift that organizations such as Google, Amazon, and countless others have leveraged. The results are tangible: increased market share and revenue, lower costs, better customer experiences, reduced risks, and the promotion of innovation.
Semantic Arts’ professional services deliver true solutions (not gimmicks) for current and future information management challenges.
FROM OUR BLOG
How to Run a Project Over Budget by 300-500%
A Playbook you Don’t want to Follow A while back, I was working for a large consulting firm. When I was returning to the US from an overseas assignment, I was allowed to select the city I would return to. I told my boss, who was on the board of this firm, my choice. He...Continue reading→
Supersumption: Solving Common Object Oriented Problems
The idea of supersumption may solve some common Object Oriented problems. We’ve been doing training in Semantics and Description Logics lately, and have decided it’s worth emphasizing the concept of supersumption. Of course, supersumption is nothing but the inverse of subsumption: that is, if we say A subsumes B, then we have also said B...Continue reading→
The Treaty of Tordesillas
What history can teach us about semantics. Lately we’ve been grappling with the issue of how to get a Semantics Inference Engine and a Business Rules Engine to play nice in an Enterprise Architecture. Some long dormant neuron fired and the Treaty of Tordesillas was invoked as a possible exemplar. For those of you whose...Continue reading→
Systems Development: Assessing Risk Factors
System project failures are a well-known part of systems development; however, all the potential risks of planning and executing a project effort are not. This white paper offers heuristic guidelines to help IS managers assess these inherent risk factors before initiating and while executing a project. Case examples illustrate how a particular risk factor can...Continue reading→
The Problem with Default Values
Are there hidden problems with default values in software? Virtually all information systems have “default values.” We put them in our systems to make things easier for the end-users as well as the system itself. As we will investigate in this white paper, there are many hidden problems with default values, some of which first...Continue reading→
Three Value Logic: The Case for an ‘Unknown’ Value in Software Logic
Relational databases, relational theory, relational calculus, and predicate logic all rely on a two-value truth. That is, that a given proposition or predicate is either true or false. The fact that the results of the query can be proven to be correct rests on the fact that it can be established that each part of...Continue reading→
The Magic Number in Complex Systems
Somewhere around 200 items seems to be the optimum number of interrelated things we can deal with at one time, when dealing with complex systems such as computer software. In 1956 George Miller wrote an article for the Psychological Review called “The magic number seven plus or minus two: some limits on our capacity to...Continue reading→
System Project Failure: The Heuristics of Risk
An Evaluation of Risk Factors in Large Systems Engineering Projects This article was originally published in the Journal of Information Systems Management, Volume 8, Number 1, Winter 1991. It is reprinted here by permission of the publisher: www.crcpress.com System project failures are a well-known part of systems development; however. all the potential risks of planning and...Continue reading→
Deplorable Software
Why can’t we deploy software as well we did fifty years ago? The way we build and deploy software is deplorable. The success rate of large software projects is well under 50%. Even when successful, the capital cost is hideous. In his famous “Mythical Man Month,” Frederick Brooks observed that complexity comes in two flavors:...Continue reading→
A Minimalist Upper Ontology
Gist is designed to have the maximum coverage of typical business ontology concepts with the fewest number of primitives and the least amount of ambiguity, known as a minimalist upper ontology. A title guaranteed to scare off just about everyone; if you’re not familiar with work on upper ontologies, the title is just opaque. If...Continue reading→
gist: 12.x
gist: is our minimalist upper ontology. It is designed to have the maximum coverage of typical business ontology concepts with the fewest number of primitives and the least amount of ambiguity. Our gist: ontology is free (as in free speech and free beer–it is covered under the Creative Commons 3.0 attribution share-alike license). You can use as you see fit for any purpose, just give us attribution.
