Development

opendms

building it... and using it

hard decisions had to be made

The hardest thing for any IT startup to do is pick the framework to use for their development and this is no less so for the opendms project. We had to consider where technology was in 2020 and where it is likely to be in 2025. It used to be that a 10 year plan would suffice for IT/IS development but over the past 10 years we’ve seen so much advancement in so many areas of information technology that it is almost impossible to see beyond 5 years and even that is a huge guess.

To try to get a handle on this we break the opendms offering into three distinct section;

  • applications – the user facing solutions to business problems (e.g. Project Forward). Applications may be those developed by and included in the opendms project, external third-party services (e.g. Xero, Zoho etc.) or those developed by third-parties specifically to complement the opendms ecosystem (community developers), and applications may be broken down into;
     
    • browser based – where the application works within the confines of a web browser (Chrome, Edge, Firefox etc.);
    • progressive web applications (PWA) – where the application takes on the appearance of a native application on the target devices (desktop, laptop, tablet, phone) and may connect to the target devices services; or,
    • native platform – where the application is compiled to a specific native platform (Windows, iOS, Android);

  • portal – the administration portal of the opendms project (i.e. Project Terra) and designed prominently for browser deliver but may be responsive using a CSS framework (Boostrap, Material etc.); and,

  • middleware – the enterprise layer that sits between the applications and portal and the database or databases these applications and the portal require.

In essence we need to consider three technology stack but the truth is each of the above sections has many layers and components and, regardless of what we decide on at the start, it will change and be open to criticism from day one. We’ve quoted Peter Drucker elsewhere so never miss the opportunity to do it again

“people who don’t take risks generally make about two big mistakes a year. People who do take risks generally make about two big mistakes a year”

The decision of what technology stack to apply to each of the above is a risk no doubt but it’s a risk that needs to be taken or the project will flounder waiting for decisions to be made.

APPLICATIONS

There is no doubt that successful software companies (Microsoft, Google, Adobe, Affinity etc. Et al) spend a great deal of their time focusing on the user experience of their product. The customer facing aspect of their applications is just as important as the functionality for the most part.

With this in mind we can see that the application level has two elements that need considering;

  • what the application looks like; and,
  • what technology the application should use to provide the functionality required.

Seems simple enough but each of the above has any number of options. Further to that, the concept of applications is broader than just opendms offerings. As we mentioned earlier the application layer may consist of;

  • core offering – applications built by the opendms team;
  • community offering – applications built by third-parties (perhaps by a dealer or dealers’ IT support or independent IT companies) that are designed to be included in the opendms ecosystem; and,
  • external offering – “global” applications build by non-associated companies and providing software development kits (SDK) to provide external interfacing (e.g. Xero, Zoho CRM etc.).

Core and Community Offerings

In this case it makes perfect sense that solutions build by the core opendms team or those built by the community to be included in the opendms ecosystem should follow the same look and feel and possibly, although not mandatory, use the same frameworks.

In almost all instances these applications will follow a similar design precepts. We mentioned above that decisions had to be made so here they are. opendms applications (core and community) should use;

These applications may have their own Bootstrap library or additions to the core Bootstrap framework to enhance the applications functionality (i.e. specific features requiring specialized styling) but, for the most part, browser based applications will try to share the opendms portal Bootstrap styling.

The React, Bootstrap and React Native frameworks are open source and attract no cost as such and community developers will need to read the various products’ license conditions to make sure the meet their requirements (and commercial requirements).

External Offerings

In most cases, external offerings (e.g. Xero, Zoho CRM etc.) are rarely cases for development as these offerings are usually fully functional within their own ecosystem. Most commonly, the opendms middleware will include end-points that the opendms team or community developers can access to pass through to the external offerings and visa versa.

The benefit of using the opendms middleware in these instances is that the application can access it’s own data store and any community or external offerings through the opendms middleware in a seamless manner.

PORTAL

The opendms portal (Project Terra) is a cloud-based application that provides the administration of any opendms or community applications and community developers may emulate the look and feel of the portal in their own applications and, with the cooperation of the opendms team, have their application specific administration pages either embedded in the portal’s code base or, through the middleware layer, have their administration pages loaded via hyperlinks and, visa vera, load opendms pages directly.

The portal, as with the middleware layer, will always be under the complete control of the opendms team but community developers are welcome and encouraged to make use of the portal.

In the fullness of time, with opendms internal development, community offerings and the interfacing with external applications, the portal has the potential of becoming a replacement for dealer members’ existing Dealership Management Systems; this is the vision of the opendms organization and, we hope, your vision to.

As with the opendms applications, the portal uses;

  • the administration template;
  • the React framework; and,
  • the Bootstrap CSS framework.
MIDDLEWARE

Middleware is software that provides common services and capabilities to applications outside of what’s offered by the operating system or core application layer. Data management, application services, messaging, authentication and API management are all commonly handled by middleware and this is exactly what the opendms middleware layer is expected to do.

Middleware makes it easier for developers to implement communication and input/output, so they can focus on the specific purpose of their application and rely on a single set of service end-points to do the heavy lifting.

We expect the opendms middleware to provide many types of service extensions including (but not necessarily limited to);

  • access to the opendms portal data store so community developers can add value to existing opendms applications;
  • extend community developer’s data layer to allow their applications to be shared across the community;
  • provide a single point of addressing with a Remote Address Translation (RAT) system behind the RAT firewall;
  • allow community developers to embed functionality in the portal and access it accordingly;
  • allow community developers to call portal pages directly from their applications, giving the opendms ecosystem a fully integrated look and feel;
  • providing asynchronous integration with external applications;
  • logging and monitoring of access through the RAT; and,
  • the list goes on and will be expanded as the project grows.

The opendms middleware layer uses;

  • Microsoft .NET Core;
  • RESTful API design;
  • Micro-service architecture where applicable;
  • Microsoft SQL server;
  • OData;
  • GraphQL; and,
  • when applicable NoSQL via MongoDB.

That said, this list is current now, as mentioned above, who knows what this list will look like in 5 years time.