Coding, code, programming, Computer, technology, digital, digits, numbers, blue

Many of our customers have invested in large, real-time, interactive, mission-critical systems that were originally acquired prior to the advent of open systems architecture technology. A consequence is that those customers find themselves dependent on large system integrators as the sole providers of such systems. A well-constructed Software Development Kit (SDK) framework enables customers to use the expertise of different, diverse providers, incorporate new technologies, lower costs and improve capability.

Opening the architecture is the first step. This means establishing an open framework as the core infrastructure for those large systems. That infrastructure software facilitates an open business model, providing an integration and compatibility framework to which many vendors can adapt their own innovative applications for inclusion in the base system.

Opening the architecture, of course, expands the supplier base to include small and mid-sized companies with relevant applications and capabilities. The potential for reduced costs increases with the lower overhead associated with smaller companies. In addition, there is the increased potential for early access to innovative technologies from a broader base of suppliers, and a higher potential for competition.

But merely having an open architectural framework is not enough. The suppliers you hope to attract must be enticed to do so. They need to know about and have easy access to the architectural framework. They need to see that there is profit to be made in becoming a supplier of applications to a large system. It must be clear to them that big investments in integration and test suites is not required. There must also be sufficient information to convince potential suppliers that the learning curve is required to adapt applications (or build new ones) that interface to the framework is not too steep.

The owner of one large system, seeking to move to an open business model, tasked his large system integrator to develop an SDK that could be provided to other uninvolved companies as potential application suppliers. The kit would include the architectural framework and other supporting materials. The system owner also tasked Rite-Solutions to perform an evaluation of the viability of the SDK. Our approach was to identify appropriate evaluation criteria and apply them in an empirical validation with a new application.

The technical literature provides virtually nothing in the way of quality assessment of SDKs. As a result, a methodology for SDK evaluation was developed based on more general software quality criteria in ISO/IEC standard 25030. Of primary importance was the definition of what should be included in an SDK. Without that, questions of sufficiency or completeness would be unanswerable. Four principal components in a good SDK were identified that contribute to the advantages and benefits described above:

  • The Architectural Framework: Tools and services usable in the operating environment of the base system
  • User Guidance Materials: Example programs, recommended design patterns, troubleshooting aids, SDK User Guide
  • Integration and Test Support Materials: Integration support tools, simulations or sample data sets to enable testing of the application with realistic scenarios and sensor data
  • Installation Support Materials: Identification of what is in the “SDK Box”, tools and scripts for building the operational environment the application must integrate with

Six dimensions of SDK quality were elaborated by Rite-Solutions to be used in the experimental assessment of the SDK being evaluated. We will discuss these in a future essay on SDK Evaluation.

Learn more about constructing SDK frameworks