In the past few weeks, Semantic Arts, hosted a new Data-Centric Architecture Forum. One of the conclusions made by the participants was that it wasn’t like a traditional conference. This wasn’t marching from room to room to sit through another talking head and PowerPoint lead presentation. There were a few
PowerPoint slides that served to anchor, but it was much more a continual co-creation of a shared artifact.
The agreed consensus was:
- — Yes, let’s do it again next year.
- — Let’s call it a forum, rather than a conference.
- — Let’s focus on implementation next year.
- — Let’s make it a bit more vendor-friendly next year.
So retrospectively, last week was the first annual Data-Centric Architecture Forum.
What follows are my notes and conclusions from the forum.
Shared DCA Vision
I think we came away with a great deal of commonality and more specifics on what a DCA needs to look like and what it needs to consist of. The straw-man (see appendix A) came through with just a few revisions (coming soon). More importantly, it grounded everyone on what was needed and gave a common vocabulary about the pieces.
Uniqueness
I think with all the brain power in the room and the fact that people have been looking for this for a while, after we had described what such a solution entailed, if anyone knew of a platform or set of tools that provided all of this, out of the box, they would have said so.
I think we have outlined a platform that does not yet exist and needs to. With a bit of perseverance, next year we may have a few partial (maybe even more than partial) implementations.
Completeness
After working through this for 2 ½ days, I think if there were anything major missing, we would have caught it. Therefore, this seems to be a pretty complete stack. All the components and at least a first cut as to how they are related seems to be in place.
Doable-ness
While there are a lot of parts in the architecture, most of the people in the room thought that most of the parts were well-known and doable.
This isn’t a DARPA challenge to design some state-of-the-art thing, this is more a matter of putting pieces together that we already understand.
Vision v. Reference Architecture
As noted right at the end, this is a vision for an architecture— not a specific architecture or a reference architecture.
Notes From Specific Sessions
DCA Strawman
Most of this is covered was already covered above. I think we eventually suggested that “Analytics” might deserve its own layer. You could say that analytics is a “behavior” but it seems to be burying the lead.
I also thought it might be helpful to have some of the specific key APIs that are suggested by the architecture, and it looks like we need to split the MDM style of identity management from user identity management for clarity, and also for positioning in the stack.
State of the Industry
There is a strong case to be made that knowledge graph driven enterprises are eating the economy. Part of this may be because network effect companies are sympathetic with network data structures. But we think the case can be made so that the flexibility inherent in KGs applies to companies in any industry.
According to research that Alan provided, the average enterprise now executes 1100 different SaaS services. This is fragmenting the data landscape even faster than legacy did.
Business Case
A lot of the resistance isn’t technical, but instead tribal.
Even within the AI community there are tribes with little cross-fertilization:
- Symbolists
- Bayesians
- Statisticians
- Connectionists
- Evolutionaries
- Analogizers
On the integration front, the tribes are:
- Relational DB Linkers
- Application-Centric ESB Advocates
- Application-Centric RESTful developers
- Data-centric Knowledge Graphers
