In software development, there are two common approaches to architectural design. One school of thought, un-opinionated, is to make software agnostic and be as flexible as possible to allow the developer to make decisions on how to design and solve problems correctly. On the other hand, some believe the best software, opinionated, should only realize one true vision, the right way. This design paradigm suggests software should pick a side and stick to it. Following the opinionated approach, design decisions have been made already limiting the options available to the developer.
Opinionated Software
Some examples of highly opinionated software include Ruby on Rails, AngularJS and Ember. These software packages share the common characteristics of making certain tasks simple to the developer by following the already predesigned path, sometimes referred to as the “Golden Path”. Following this approach can be advantageous to a developer when a problem or task maps directly to one of these predesigned paths. This can, however, present challenges to the developer when functionality outside of a package’s design is desired, creating additional effort to solve.
Un-opinionated Software
In contrast, un-opinionated software such as the .NET technology stack offers the developer freedom in design choices. Some choices available to the developer include which language they prefer working in, be it C#, F#, VB.NET and virtually any language that is .NET compatible. Flexibility allows the developer to choose the right tool to accomplish a task. The potential downside of this is that with so much flexibility it may be difficult to develop a solution the framework does not provide assistance with, leaving less experienced developers with sub-par solutions.
Our Vision
Our vision is to offer developers the flexibility in the decisions they choose to make in integrating our services. Naturally, since our services are exposed over HTTP, they can be integrated with any language or platform that supports HTTP connections. The applications that are consumed by our clients follow best practices in architecture and input/output structures. This ensures flexibility in request/response formats as well as simplicity in obtaining results. As well, we are bound by the WSDL contracts we deliver to ensure consistency in response format.
