Image source: https://flic.kr/p/6Du7DL, Creative Commons License
In the last decade, requirements for business software have changed drastically. First, monolithic industry solutions had to become platforms to enable tailoring to customer-specific needs. Next, architectural changes were necessary to fully use the advantages of cloud computing. Today, software products have to become Microservices that can be combined by customers into larger systems. This article summarized this evolution of business software and describes how our strategy for time cockpit fits in.
Monolithic Monsters
Two decades ago, software products used to be large, feature-rich, monolithic systems. Specialized software vendors were competing by offering holistic solutions for certain branches, often referred to as “industry solutions”. Over time, the solutions that were widely used, became unmanageable monsters with an endless number of configuration options and extensibility points. As a customer, you always got the whole system with all its complexity even if you needed just a part of it.
Platforms Instead of Ready-Made Products
Once it became clear that adding more and more features and options to a product is a dead-end street, vendors of commercial off-the-shelf started to build platform-products. These platforms provide a basic set of ready-made functionality. Additionally, they had mature extensibility mechanisms like for instance
- customizable data models,
- APIs (based on e.g. .NET, Java, COM) with logic specific for the domain for which the software has been built,
- possibility to inject customer-specific modules (logic and UI),
- scripting capabilities,
- workflow engines.
The platform is used to tailor a product to the specific needs of a customer.
Our own product time cockpit is an example for such a platform. It comes with a basic set of common features our customers need for project time tracking. For some small customers, the out-of-the-box feature set is sufficient. However, most customers have specific needs. They can use time cockpit’s extensibility features (e.g. data model extensions, validation rules, permissions, Python scripts, etc.) to add the necessary functions. Customers can decide whether they want to do the customizations themselves or hire us for support.
Par-baked Products
The big advantage of the platform-approach is that extensions made for one customer are not shipped to another customer with different needs. From a customer’s perspective, the software offers exactly the functionality that she needs. It is not overloaded with irrelevant features other customers’ might be interested in. Classical software-development concepts like object- and component-orientation replace a confusing multitude of options and settings.
One could say that platforms are par-baked software products. They are done to a large degree but you have to finish baking and add ingredients according to your taste. Approval and confirmation processes are a good example in our own software time cockpit (see also article Learn From Best in Class: Confirmation and Approval Processes). Every larger customer needs them for e.g. confirmation of time tracking data, email reminders, budget overrun warnings, violations of working time policies etc. These processes differ greatly from customer to customers. Time cockpit does not contain ready-made workflows for such use cases. However, it contains everything needed to quickly setup customer-specific processes or integrate with an existing business process management tool.
Multi-Tenancy as a Game Changer
Platform-products had to evolve to get ready for cloud computing and SaaS. The most important reason is that large-scale SaaS solutions are typically multi-tenant. That means that multiple tenants (=customers) are served by a single server or cluster. Nevertheless, tenants must be strictly separated. If you allow tenants to upload and run custom code (e.g. .NET modules, scripts), this code must be sandboxed so they it access other tenants’ data. Additionally, the server infrastructure has to be protected from overuse (e.g. endless loop in custom script consuming all CPU resources leading to an unusable system).
Building secure and robust sandboxes is difficult and expensive. Only recently, leading cloud providers like Microsoft have started to incorporate features that support tenant separation on the server-side.
A few months ago I wrote an article about building multi-tenant systems on Microsoft Azure. You can read the German version of the article or use Google Translate to get an auto-translated version in English.
Time cockpit has been built with multi-tenancy in mind from the very first day. Our platform contains mechanisms for tenant separation on all levels (e.g. authentication, data access, APIs, etc.). However, the Microsoft Azure platform that time cockpit is using has made great progress since its launch. Over the years we could rethink some components and architectural designs to fully benefit from advances in Azure. An example is the transition to Azure SQL Elastic DB Pools which we described in the article Hello Database Pools!
SaaS Microservices
Nowadays, customers have learned to love SaaS. Instead of buying an expensive, monolithic industry solution, they use specialized services like Office 365, Salesforce, Dropbox, time cockpit, or Zendesk in the cloud. However, they don’t want information silos. They demand integration across system and vendor boundaries. They want to form a larger application by combining smaller, independent systems. The building blocks are often referred to as Microservices.
This trend challenges traditional software systems. Here are some examples why:
- The SaaS products are implemented on different platforms with different technologies. Therefore, support for cross-platform protocols and standards is required.
- Platform-independent standards for authentication and authorization system must be supported.
- The overall solution must not break if an update of an involved SaaS product happens. Careful versioning on a serve-level is needed.
- Finding the reason for a problem is harder in distributed systems.
A few months ago I wrote an article about the importance of web APIs for SaaS solutions. You can read the German version of the article or use Google Translate to get an auto-translated version in English.
Time Cockpit is a Microservice
We are constantly improving time cockpit’s ability to work as a Microservice. Here are some examples:
- Customers can use the same Web API that we use in our own HTML 5 client.
- We use OpenID Connect for authentication.
- We integrate with popular SaaS offerings like Office 365 out-of-the-box and/or offer samples for custom integrations (e.g. with Power BI).
You can read more about one of our partners who built a powerful custom solution using time cockpit’s web API in our article Differentiate with Transparency.
This month, we have made an important step regarding extensibility in our HTML5 client. Time cockpit now supports adding custom modules written with web technologies like HTML5, CSS, JavaScript, TypeScript, AngularJS, etc. These extensions can be seamlessly integrated in time cockpit’s HTML5 client. They can not only use time cockpit’s Web API but also combine data from other sources. In our article What's New in Version June 2016 you can read about the use of this brand new extension method in a customer project we are currently implementing.
Would you like to build your own custom extension for time cockpit’s HTML5 client? Contact us at support@timecockpit.com. We have a private preview program and we would like to talk to you about your ideas.
comments powered by