In Enterprise Architecture, Relationships are Everywhere

Pete Aven
Pete Aven
Sep 4, 2018 · 4 min read

TOGAF defines architecture as :

“The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.”

There are different enterprise architecture frameworks, but they all have many similar elements in common. They all help manage the job of integrating the people, processes, and technologies required to meet business needs. They provide a language and methodology for defining architectures for software technologies and aligning them with business objectives across multiple stakeholders having differing responsibilities and viewpoints.

Look at the TOGAF spec, or work on any enterprise software development project, and it’s easy to see that relationships are everywhere!

  • Relationships with business, data, application, and technology domains
  • Relationships with business views, strategies, products, policies, initiatives, and stakeholders
  • Relationships with the requirements, deliverables, and artifacts generated
  • Relationships with projects and timelines
  • Relationships with organizations and their hierarchies
  • Relationships with management frameworks
  • Relationships with critical data entities
  • Relationships with a baseline architecture
  • Relationships with a target architecture
  • Relationships with stages and transitional architectures
  • Relationships with the conceptual, logical, and physical models of data and architecture
  • Relationships with data, business processes, and information exchange
  • Relationships with underlying systems
  • Relationships with entities and their attributes
  • Relationships with teams
  • Relationships with architectural and physical patterns
  • Relationships with capabilities
  • Relationships with metadata
  • Relationships with events
  • Relationships with geographies
  • Relationships with processes and sub-processes
  • Relationships with industry standards
  • Relationships with actors and roles
  • Relationships with consumers and providers of business services
  • Relationships with validation of data and processes
  • Relationships with applications
  • Relationships with consumers and providers of application services
  • Relationships with application components
  • Relationships with requirements management
  • Relationships with architecture components and solutions
  • Relationships with governance
  • Relationships with security

And more!!!!*

But what happens to them? Where do they go? What happens to these relationships in a project? They get documented and placed into requirements docs, deliverable docs, architecture docs, and other diagrams and artifacts. And these disparate docs get filed away somewhere. There’s likely a repository for architecture documents and another for requirements. However, the actual implementation of the relationships is severely underrepresented in software projects due to the nature of the technologies used.

In a graph database, relationships are a first-class citizen. As such, information about all the relationships listed above can be baked into the structure of the data model itself. The rules for those relationships can be enforced and the data that accompanies those relationships can be persisted within the database so that all the relevant architecture development information is available along with the company data that is persisted as part of the data architecture requirements and deliverables.

This is tremendously useful. While the relationships for software development projects are often documented, the documentation is usually incomplete to a degree. It’s not uncommon, when defining a baseline architecture, to have to speak to the tribal elders in the org. These are the people who’ve been there for years and were in the meeting where decisions were made, and then had some hand in implementing past projects. You have to extract the knowledge they’ve stored in their heads to help define the baseline for a project and inform how the team can move to a target.

A Concrete Example

I once worked on a project to help integrate two “Customer” silos of data. One silo was stored in Oracle, the other in SQL Server. They both contained overlapping information about different sets of customers, but one system had attributes such as: firstName, lastName, Address1, Address2 and the other had givenName1, givenName2, givenName3, Street, etc. There was also no master customer identifier between systems. Understanding the mapping required me speaking to a subject matter expert who had the mapping in his head of how which fields from one system mapped to a set of fields in another. This person was also able to tell me the seven attributes the company used where if the values were similar across silos, they knew it was the same customer. This helped us for de-duplication of data as we integrated the silos.

This is a typical case and a simple example. I’m currently involved in a government project where understanding the mapping and transformation of data through a pipeline requires extracting info from twelve different people’s brains.

Using a graph database, the type of information that’s stored in people’s heads, the architecture repository, and the requirements repository, can all be baked into the data and its structure, in a way that provides for operational efficiency, improved communication between groups, and an immediate hands-on audit of why systems were created the way they were. Now we don’t have to track down Bob and Sally after their vacations to answer some questions for us on the POS system, or hunt for a doc in a repo, we can go right to the system and ask, and know.

With the right application that uses a graph database for its persistence layer, the conceptual models of a business view of data can be implemented, decoupled from any existing underlying sources. Existing sources can then be mapped to the model to make it physical, aligning the data with the requirements and persisting the entities and relationships all in one fell swoop, without anyone having to write any code to start.

image via techseen.com

* There is no order to the importance of the above list. I purposefully put governance and security last because orgs and frameworks typically put governance and security last. If you know what you’re doing you address these earlier in your development cycle.

Pete Aven

Written by

Pete Aven

Connecting people, information, and systems. Fights for the users.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade