A question came up recently about using canned schema models like NIEM, OAGIS, HRXML, cXML, etc. I posted the following thoughts in response:
I sat on the OAGIS 10 working group for a short while so I have some insight specifically into OAGIS, but I can also speak to using other schema such as cXML, NIEM, and others.
I find it useful for this to break up the dialects into levels [1].
1 – Atomic dialect. This is the lingo that the system speaks when you bought it or built it. Maximo speaks Maximo, PeopleSoft speaks PeopleSoft, Hank down the hall wrote it using Hank-speak. It is what it is.
2 – <Reserved> This layer is reserved for wrapping naked databases or bringing other funky systems up to the HTTP world.
3 – Domain dialect. These are the business dialects of the organization and it’s up to the organization to come up with something that is unsurprising to each other (Principal of Least Surprise).
4 – Enterprise. This is where the edge of your company meets another company. And it’s here only that I would introduce a canned (e.g., OAGIS) schema.
Each of these levels should expect different namespaces, using your integration framework to convert E<->D<->A. The E-D is your enterprise service bus, and your D-A consist of one or more domain busses.
My experience is that whoever pays the piper calls the tune. So for example if you’re communicating to the US Federal systems you’re going to use NIEM. If your business is >90% federal you might want to get good at NIEM so it’s worth bringing in house. Chemical houses like OAGIS so that just might be the thing to bring in house if you do lots of chemical business.
Inside your company domains (e.g., finance, hr, accounting, maintenance, procurement, parking, whatever) I think it’s very reasonable and maintainable to use your own common schema. This includes a complete and versioned namespace and I keep schema and validation rules in source control always.
I have created domain schemas on OAGIS before with mixed results. There are some limitations in modeling anything with XSD that are inherent in the root-tree structure of XML. One of the deepest rabbit holes I’ve seen folks fall into with OAGIS is the attempt to model reality with it. XSD is not a sufficient structure for ontological modeling.
OAGIS has a few issues. These are echoes of the below in any canned schema (take a look at HL7v3 or NIEM for some of the same woefulness, though at least NIEM brings CAM).
- It’s not wonderfully tool friendly. So expect to get very very good at XSD debugging to get it to work. Your junior integrators and developers will dislike you intensely. So be ready for that.
- It’s highly complex and sometimes doesn’t make immediate sense. So factor in a learning curve. Again exactly what do you think of your coworkers?
- It’s not really what we think of today as “open”. That’s an artifact of history. OAGIS predates our recent (as of this writing) understanding of what “open” means. I think of open as “open source” and all that entails. At the bottom of it all OAGIS sells standards that they would like you to pay for (IEEE or ISO do it too). Unlike today’s understand of open source you can’t contribute and extend unless it’s within the constraints of their license. Pay attention to that.
- It’s not a great implementation of its own standard. There was a small debate while I sat on the group about doing a better job of creating the business model (maybe RDF or an ontology-based approach). The idea would then be to express or generate the schema as a set of artifacts. This didn’t happen while I was there so the implementation was the model was the schema. If you buy into the idea that XSD is completely limited in its ability to model (that’s not what XSD is for anyway) then you can see where it will fail.
But what OAGIS does do is eliminate the fight. We’ve all been there. I add an element to a PurchaseRequisition called “OverlayField05” and we fight for weeks about why we didn’t call it “PurveyQualification” (those are made up!). When things look odd or strange you can all together blame OAGIS. And you will. The problem is you’ll likely be fighting each other for different reasons, along the line of “who made us use this canned schema?” Still one less fight is one less fight.
So maybe it comes down to the question of “Who made us use this canned schema?” If it is your chief architect, an external owning company, the federal government, or someone else with more muscle, then at least you know. I’ve often thought that these canned schema should come with prewritten letters to give to your managers apologizing for when the inevitable comes, and he or she wants to know why you’re so behind farting around trying to get the canned schema to work.
Finally I think the world has moved some in the last few years towards the API mentality that simply states that the edge of your application is _your_ edge. If you expose your services using a funky schema that’s what it is and the consumer is responsible for sucking it up. That consumer might _also_ be you, but change your hats, get a decent integration framework and keep on moving. I mentioned a tool above called CAM and it’s used a lot with NIEM. It’s not perfect but it forces the conversation of modeling versus API and is super helpful in a more API-centered world.
[1] I took the idea of the numbers for levels from chapter 12, Definitive Guide to SOA, Oracle Service Bus (Davies, Schorow, Ray, Rieber) but have modified the levels somewhat.