A 20:80 Rule

Summary

Systems have a lot in common but differ in few places. Service designs that are scoped to the common themes of a single system will be limited in its ability to interoperate with others. An interoperable service framework needs to incorporate a wide variety of interoperability issues. Consequently, the OSIDs are a different kind of API.

No Assumptions

Let's face it. We build the same thing over and over again with different names and data. Many development frameworks have risen up to handle the plumbing and plop in our own models and data. They're fast. They're easy. Then we need to do just one thing a bit differently. Let the hacking begin! Then another.

Much of what we build is the same. Only a small set requirements differ. It might be the need to proxy authentication, the need for real-time access, the inability to buffer information, or the need to constrain updates of specific data. If everything were really the same, we'd already have interoperability. It is the assumptions in the plumbing that ties us down. Hacking around these assumptions builds the ball of twine that becomes more expensive to manage over time. 

The OSID framework makes minimal assumptions about the nature of a service implementation. 

The Path Less Traveled

To achieve the kind of interoperability that OSIDs strive for, they must address uncommon integration issues. Some of the ways OSIDs do this in its specification are:

• Relying heavily on functional and integration patterns to avoid making judgements that may deem something unnecessary within a specific service domain. An example is that if assets can be organized among a hierarchy of catalogs then the same holds true for events, assessments, and resources. OSIDs are designed around models and patterns distilled from a large number of designs and use cases. Patterns get applied to the models blindly. It's the next implementation to depend on it to which we want to interoperate. It's the future proofing.
• Full modeling of the domain. If a possible "pivot" is identified, it often appears as a separate entity. Not surfacing the requisite number of managed entities is often a blocking factor in using someone else's stuff, but we can always figure out clever ways to ignore or bypass the parts of the model we don't care about. It gets more annoying when the OSIDs call for a many-to-many relationship when we don't need one, but in the end it isn't a large price to pay and often our simpler view of the world didn't hold up anyway.
• No DTOs. No assumptions about how an object is created or updated and more importantly, what is managed often needs to be different than what is viewed. The most difficult interoperability challenge is create. OSIDs do a lot to sort this out but can seem like overkill to someone used to retrieving and saving object models.
• Life is but a stream. This is probably the most criticized aspect of the OSIDs. OSIDs do not use arrays, lists, maps, or make any fixed-buffering assumptions. The OsidLists are effectively streams. We don't even know how many elements they contain. For such a simple construct they are very powerful. But they require a change of mindset.
• Defining explicit attachment points for rules. Unstructured rules are the largest contributor to balls of twine. Rules wind up everywhere in our code. Rules engines too often become the other bit bucket for a tangled mess. OSIDs have become pedantic about providing the opportunity of separating rules apart from the mainline entities at every turn.
• Last but not least, everything is an interface. Everything can be implemented differently including its own runtime environment.

Interoperability is King

It seems like a lot of flexibility but is it worth it? OSIDs are trying to reign in the 20% that differs and so there's a price tag to be paid for that other 80% when compared with other frameworks. In the OSID world, it's all about achieving interoperability even if it feels at first we are taking the long way around.

This is why contributed code is important for the success of OSIDs.  We want leverage the boring stuff and focus on only those pieces that make us different.