Our new patterns include the rosetta stone.  This pattern provides a path to link disparate systems and their data formats.  It comes from the historical rosetta stone which was a multilingual text used to decipher ancient languages.  We use this as a sort of pathway to a common language for our application.

The Rosetta Stone Pattern Defined

Modern software often has multiple other systems that need to be integrated with.  That means we need to pass data back and forth.  The format and structure of the data we send can be challenging to map across multiple systems.  The rosetta stone pattern approaches this problem by designing a single format that all of our data will transform into or be exported from.  Thus, we always map to one set of data when pulling from other systems.  Likewise, we have one format we generate that other systems are provided.  

That avoids us having to map from each disparate system to every other system.  We create a hub and spoke rather than a mesh network.  Therefore, we have a dramatically reduced number of integration points that need to be addressed.  Also, we have a set format to convert new systems into. 

Applying The Pattern

There are two main ways to apply this pattern.  One can either build a master format that combines the data from all of the desired integration systems or build what the solution needs as the master.  The latter approach tends to be better as it focuses on the solution rather than other systems.  We also are driving the format and structure instead of reacting to other systems.  Finally, we have a static universal format that does not change based on external factors.

Challenges

Data types and labels are always a challenge for this pattern.  Date-related fields in particular have a number of challenges including time zone mappings and a multitude of formats.  When the central structure is created it helps to make it as similar as possible to the external systems.  However, organizations and lines of businesses use that data in different ways and often have different views of the related labels.
For example, take a field called “name.”  That can be the name of many things and likely is helped by a qualifier.  The disparate systems may all have only one thing that is named in their data set while we have dozens.  The more external sets we have to inform our central creation, the better.

Rob Broadhead

Rob is a founder of, and frequent contributor to, Develpreneur. This includes the Building Better Developers podcast. He is also a longtime student of technology as a developer, designer, and manager of software solutions. Rob is the founder of RB Consulting and has managed to author a book about his family experiences as well as a few about becoming a better developer. In his free time, he stays busy raising five children (although a few have grown into adults). When he has a chance to breathe, he is on the ice playing hockey to relax.

Leave a Reply