Also with SaaS, first choose your own software architecture

Using APIs and SaaS solutions in the cloud offers organizations many opportunities. But there is also a downside to this development. Many companies and organizations lose sight of their software architecture. This can lead to proliferation of (emergency) solutions and fragmented data. Prevent this by reversing the development process. Start again with your own software architecture. That’s better for your business case, the software that fits and to remain in control of essential data. The privacy legislation (AVG) also requires this.

The danger of SaaS and the API

You can just forget about it with all those handy interfaces, APIs (Application Programming Interfaces) for accessing data and attractive SaaS solutions (Software as a Service). But it remains important that an organization first thinks about its own software architecture.

If you don’t, all kinds of functionalities with APIs and very specific (SaaS) solutions for certain business processes (such as e-mail marketing, CRM or tracking) quickly create a diffuse landscape of interlinked software. Then there is no longer any question of an underlying software architecture. Or even worse: one of the components becomes dominant and dictates the ‘architecture’. The other components then have to conform to the unintentionally dominant component.

Company data captured by dictated choices

Such a dictated ‘choice’ is often not useful at all for an organisation. The software, which is increasingly determining the success of organisations, soon no longer fits in well with your own core activities. The organization becomes dependent on the choices made by the producer of a dominant software product.

This is often at the expense of the availability and flexibility of company data. After all, this is trapped in a data structure that is useful for the application. And that is rarely a useful structure for the entire organisation. This leads to fragmentation, lack of clarity and ultimately loss of (insight into) essential company data. In this way, you do not get a software environment that optimally facilitates the organisation and performance of employees.

AVG and privacy by design

In addition to the importance of the software architecture as a foundation for your own business, privacy legislation (AVG/GDPR) is also a reason to think carefully about this. After all, the AVG (General Data Protection Regulation) requires organisations to think carefully about questions such as: Where is our data stored? Who can do this? What is the source of that data?

The interpretation of privacy by design and privacy by default is therefore a topical theme. Implementing it afterwards is much more complicated and expensive than thinking about it carefully beforehand. You can’t just ‘stick it on your software’, you have to design it in the software architecture. In fact, the AVG expects organizations to adopt an integrated approach in software architecture in order to realize a sustainable and secure solution for the privacy principles.

Software architecture for proprietary data source

The crucial step in an architecture first approach is to secure the availability and flexibility of your essential business data and business processes. With a good software architecture you create your own data source for this. You can develop this yourself (or have it developed) separately from external (SaaS) software. You then connect the external software to it for publication and transactions.

This means you remain independent and you can switch SaaS suppliers if an alternative solution is better suited to your organisation and work processes. Such a switch is possible because your core data and core processes are not trapped in a dominant SaaS solution. They are safe and accessible in your own environment. So you remain in charge of crucial business software]yourself [(/blog/2017/03/blijf-zelf-de-baas-over-cruciale-bedrijfssoftware/).

Architecture first also strengthens your business case. It forces you to think about where the core of your business lies. Which parts are essential for your organisation and what are the peripheral issues?

Example with a webshop

Solutions for webshops are often available as SaaS. They are gratefully used by start-up webshop companies. The product database is then often the heart of the software environment. All products, product information and prices are also neatly stored in the database of the SaaS solution.

That’s super handy until you grow and want to keep up with a little more than the SaaS solution offers. For example, that you can buy certain products from multiple suppliers. That can become very important for your business. That needs to be tracked externally, referring to the SaaS database as a source. That is where the loss of control, overview and flexibility of the source data begins. This is the moment to reverse the approach: first your own product database and a copy of it for the SaaS webshop.