This website uses cookies to store information on your computer. Some of these cookies are used for visitor analysis, others are essential to making our site function properly and improve the user experience. By using this site, you consent to the placement of these cookies. Click Accept to consent and dismiss this message or Deny to leave this website. Read our Privacy Statement for more.
Print Page | Contact Us | Sign In | Join the A4L Community
Chapter/Locale: North America
Group HomeGroup Home Blog Home Group Blogs
Search all posts for:   


View all (26) posts »

Unitys Ecosystems

Posted By Penny Murray, Monday, June 1, 2020
Updated: Monday, June 1, 2020

Unity’s Ecosystems


Before you consider if you are going to build, buy, or partner to get your application into one or more Unity Ecosystems, you are going to want to figure out what role your software will play.  In order to gain an appreciation for these options and expectations, this article lays out an overview of how integrations using the global SIF 3 Infrastructure may look.  Based on experiences from our international members, you're going to want to make it all the way to the end before you make any decisions.



The diagrams in this article use symbols the reader should know about.  Along with these symbols, various roles are also explained.  Overarching assumptions that form a lens for viewing the diagrams are also enumerated.





Whether a Consumer script pulling down data or the most sophisticated Data Provider on the planet, this symbol represents an integrated Application and its adaptor’s REST API capabilities.




While your Consumer may need multiple connections, you should expect it to be directed to a bidirectional REST API to a single network endpoint, regardless of the typology being discussed.




The software that (when present) connects agents together for a specific data scope by providing SIF Global Infrastructure Services through REST APIs.



Operational Data Store

This represents an ODS that readily provides and accepts the SIF Global Infrastructure and Unity data through REST APIs.




 Infrastructure Provider:  

The Provider of the SIF Global Infrastructure’s services to the integration.

 Data Provider:  

One or more Applications that service Unity data requests.


Applications that make Unity data requests without servicing them in return.


 [1]The SIF Global Infrastructure requires that all Applications participating in an integration be registered as Consumers, however for the purposes of this document we use a narrower definition in order to make a greater distinction between roles.



  >  Requests for data from and to impact data in Provider systems may be made by Consumers.

  >  All Consumers may participate in any one of these typologies without change, given that other systems are providing the SIF Global Infrastructure and Unity data services needed.

  >  Integrated Components may be combined or extended over time to support multiple needs at once.

  >  Existing Components may take on different complementary or even reduced roles to better fit with the growing capabilities of other Applications and their impacts on the Ecosystem.

  >  Diagrams represent certain ideal typologies and are used to create common points of reference.

  >  Components in each diagram have been arranged so that data predominately flows from left to right.



Direct Solutions

Both common in the world of the technology as the client-server model and largely inaccessible to the North American market of SIF solutions previously, direct solutions grant Consumers access to the Provider without the need for a middleman.  This makes Unity appropriate for the smallest of integrations, empowering handling synchronous data requests in both directions.  Direct Data Access means activities such as a teacher taking attendance on a tablet computer could be recorded on the Student Information System (SIS) with immediate feedback and recall.



  >  The simplest ecosystem possible

  >  No additional components necessary

  >  Enables simple interactions with apps

  >  Clear growth paths to take



  >  Only one Provider per ecosystem

  >  Only as strong as the Provider:

          +  May burden the Provider

          +  May limit the Consumers

  >  Growth requires additional components



Infrastructure Provider:  

Application on Left 

 Data Provider:  

Application on Left


Applications on Right


In this diagram the Application on the left is the server playing the roles of both Infrastructure and Data Provider, while the client Applications on the right play the role of Consumers empowered to read and write certain data directly to the Provider.  Sticking with our attendance example, imagine using your tablet with a Consumer application to load up the roster for your section and adding attendance information with both sets of data living on the Student Information System (SIS) Provider.  A very simple example, however you can take this a long way as long as you only need one provider.



Brokered Solutions

At the other extreme of the data integration world is the middleware model, which is the traditional typology for SIF integrations and is still the most capable.  This makes Unity appropriate for large scale integrations as the Broker manages the other components including connections and security.  Brokers allow States to flow data up for reporting and back down in order to positively impact administration and education.  Schools and districts use them to enable the near real time sharing of data across their systems, ensuring things such as each student being picked up and dropped off at the right place each and every day.



  >  The dedicated Broker provides management of the entire integration

  >  All Applications may consume and/or provide data

  >  Mix, match, and configure Applications to create the strongest ecosystem



  >  Ensuring well matched quality Providers for each data domain, takes additional deliberate effort

  >  In order to maintain robustness, data may need to be exchanged asynchronously



   Infrastructure Provider:  

Broker in Middle 

   Data Provider:  

Some Application(s) 


Some Application(s)


This typology brings home the advantages of utilizing a Broker.  One of these advantages being that from any one application’s point of view the simplicity of a small integration is maintained.  Instead of seven sets of certificates, credentials, services, access control lists, connections, and more, it has one set for the Broker.  This encourages more Applications to participate in the integration.  So, when the Transportation Department verifies and shares the best addresses for a student and their contacts, it doesn’t just help bus drivers keep kids safe, it positively impacts other systems as well.  Systems like Food Services, which now have a good address to send a lunch balance report to, which in turn leads to a student getting a good meal on a day they had state testing.  Strong systems make everyone stronger and when it comes to large data integrations, the strongest have this typology.



Data Hub Solutions

For a mid-sized integration, we have found that the Global SIF Infrastructure lends itself well to a data pool style.  We often refer to an integration of this typology as a Data Hub because it creates a place to put data so that it can be queried using the Data Hub as the source of truth.  The ability to control the source data set for reporting is often a desired feature for helping ensure data quality.  This makes Unity able to evolve to meet a growing integration’s needs, as the ODS carries the load of being both the Infrastructure and Data Provider.


  >  No Application need be a Provider

  >  One source of truth for all queries

  >  Queries that span multiple Applications’ data can be answered



  >  Query results are only as up to date as the data sent to the ODS by its Consumers



  Infrastructure Provider:  

ODS in Middle 

   Data Provider:  

ODS in Middle 


All Applications


The picture shown conveys the Consumers on the left supply data through requests to the ODS in the middle which can then handle queries from the Consumers on the right.  While these are artificial limits, it helps convey how an ODS can help create a Unity Ecosystem by taking on the burdens of being the only provider.  When it comes to growth, notice that the right half of this example is exactly the same as our direct solution.  At the same time, you can see that if the two Consumers on the left-hand side became providers and the ODS was swapped out with a Broker, we would have a Brokered Solution, albeit not as large as the previous.



Hybrid Solutions

Having a common REST API and supporting services opens the door to many possibilities.  When putting together solutions, one shouldn’t be afraid to mix and match approaches in order to construct the best solutions possible.  Here is what it might look like to combine all the functionality discussed above.



Here we have an ODS that can store whatever data isn’t provided elsewhere, linked by a Broker managing the integration, and a Direct Provider hosting additional Consumers.  While an integration like this one is best rolled out in phases, growing to this level of sophistication is a very real possibility.  In fact, many projects, both here and abroad, have used brokers as Infrastructure Providers in front of one or more Data Providers to create a more modular Data Hub.




When looking to enter a Unity Ecosystem there is one clear place to start and that is creating a solid Consumer.  Not only is this the least amount of work, the Ecosystems you encounter may very well already have other systems providing data so you shouldn’t assume this will be one of the roles your software will fulfill.  In such a Unity Ecosystem, your Consumer may contribute to the data by making create, update, and delete requests.  If it becomes necessary to beef up your Adaptor in order to fulfill the role of a Provider, you will be in a much better position to understand what that will take and what features are important for you to support.


Tags:  2020  brokered  data hub  direct  ecosystem  hybrid  Specification  Unity 

Share |
Permalink | Comments (0)
  • SIF Association (dba Access 4 Learning (A4L) Community)

  • PO Box 1024, New Albany, Ohio 43054-1024

  • Phone: +1.202.621.0547