A Technical Architects Guide to the SIF 3 Infrastructure: Reliably Standard
- Pick your tools:
- Data Model
- Code Generation
- Choose your expert:
- SIF 2 expertise can be hard to find.
- Most developers are comfortable with REST APIs.
- Same tools, two hours instead of two days.
When I came on staff seven years ago, I was introduced to a vision for SIF 3 so obvious I instantly agreed to pursue it and I have ever since. The idea was simple, instead of inventing things and behaving like an oxymoronic proprietary-standard, we would strive to first use other standards in our work. The cry propelling us forward became a “standard of standards” and we have followed this mantra in the big things and the small.
Let’s start with something small but more impactful than we could have imagined. Our attempt to use GUIDs styled after a dominant market player instead of standard UUIDs had gone from convince to pain point. Rather than picking up a UUID library, developers were trying to meet the requirements on their own. With solutions that did everything from violate the rules to leak personal identifiable information (PII). Moving to UUIDs has proven easier for marketplace providers, safer for end users, and more enforceable by the community. Plus it has given those with challenges keeping data unique, guidance and options to do so. With out this seemingly small change, our ability to have a successful REST based standard would be compromised from the beginning.
Of course we also seek to be ready to move any data model necessary. For models that do not use UUIDs like the infrastructure does, we will use the unique identifiers the data model does identify. For data models that don’t have IDs, we have the option of wrapping the data in a service driven by an infrastructure standard job object. To get a data model on and off the wire properly we have worked a lot with popular code generation tools and labor to ensure our infrastructure payloads and our data model are defined in XML schema using the venetian blind style and recommend others do as well. While adhering to standards has yet to fail us, it has had an interesting indirect impact on the adopter.
It is generally agreed that to succeed with SIF 2 you should engage a company (or at least an individual) familiar with the SIF 2 infrastructure. It turns out there is a lot more people that are familiar with REST, XML, UUID, OAuth, and other standard technologies. This means there are a lot more people ready to dive into SIF 3 projects. Once these people are engaged, they have choices. Just as they can code directly to the data model or leverage code generation tools, they can start with their favorite tools or grab ones already built out to make SIF 3 development even easier. The bottom line is it is simpler to find experts and they can usually produce solutions faster.
So by seeking and leveraging the usual, you should find the SIF 3 infrastructure a standard of standards. By building on these standards, you should find it scalable. Yet our next topic will make keeping true to this formula, significantly harder.
Great SIF 3 developers are out there please let them know it.
To find out more about the SIF 3 Infrastructure Specification, please go to: http://www.a4l.org/page/Infrastructure