Technology and software consultancy

Advice pays off at moments when a wrong choice has long-lasting effects. There are usually four of them.

• Before a tender or request for quotation. You want to write requirements that are technically correct, verifiable and do not restrict the market unnecessarily.
• At a contract renewal. The existing system works, but you want to know what a switch would take before you sign for years again.
• In a stalled project. The schedule slips, costs rise and nobody can explain why. A fresh look at code and architecture often makes the cause visible.
• When choosing between build and buy. There is a package that almost fits, and a proposal for custom work. Which route is cheaper and less risky in the long run?

Advice is less useful when the decision has already been made and only looks for justification. A review then mainly delivers confirmation, and you should not pay for that. We would rather say so in advance.

The advice covers software, data and geo-information, with a focus on government bodies and organisations that work with open standards. For the building itself we refer to custom software development or GIS and digital map solutions.

An architecture review looks at how a system is put together and whether that fits what the organisation wants from it. It is not a code audit of every line, but an assessment of the choices that are hardest to reverse.

The review ends with a report in plain language and a priority list. Each point refers to the place in code, configuration or documentation on which it is based, so that your own people or another supplier can check it.

Forum Standaardisatie, the Dutch standardisation forum, maintains a list of open standards that Dutch governments (national government, provinces, municipalities and water boards) and organisations in the (semi-)public sector must request or are advised to use. With the status "Verplicht (Pas toe of leg uit)", meaning mandatory comply or explain, the standard must be requested and applied unless you explain with reasons why not.

That list changes. An example from the geo field: WMS and WFS are on the list as "Aanbevolen" (recommended), while the Geo-standaarden package, with the status comply or explain, includes OGC API Features and OGC API Tiles, among others. On its WMS page the Forum writes (in Dutch):

WMS is onderdeel van de eerste generatie OGC API standaarden, toen nog 'services' genaamd, en is gebaseerd op XML en SOAP. Deze standaarden zijn nog steeds geldig en in gebruik, maar worden gaandeweg vervangen door een nieuwe generatie op REST gebaseerde OGC API standaarden.

Source: Forum Standaardisatie, WMS. In English: WMS belongs to the first generation of OGC standards, then called services, and is based on XML and SOAP; these remain valid and in use but are gradually being replaced by a new generation of REST-based OGC API standards. A tender that asks only for WMS is therefore behind the times.

For APIs that you have built, the NL API Design Rules from Logius are the usual frame of reference. They contain agreements on versioning, error handling and transport security, among other things.

In the check we set side by side, per standard, what the list asks, what the system does and what the difference means. Where you deliberately deviate, that overview helps with the "explain" justification.

Almost every contract mentions an exit arrangement. In practice many of them cannot be carried out because they stay vague: "the supplier will cooperate in a handover". A good exit requirement is concrete enough to test in advance.

An advisory report therefore answers the following questions.

• In which format does the data come back, and is it an open format another system can read? Ask for a trial export during the term, not only at the end.
• Does the configuration come too, such as map layers, styles, user roles and search settings? Without it the successor starts from scratch anyway.
• Is the source code available and, if so, under which licence? With software as a service that is often not the case; the data export then becomes more important.
• How many hours of handover support are included, and at what rate afterwards?
• What happens to copies and backups at the old supplier afterwards?

Compare the answers to these questions between bidders. An honest limitation in the exit is better than a promise nobody can keep. The infrastructure side of an exit is covered on the page about cloud and data infrastructure.

For municipalities, Common Ground is the vision for information provision with which, according to the VNG (the Association of Dutch Municipalities), they will collectively organise their information provision in a simpler, more flexible and smarter way. GEMMA, the Dutch municipal reference architecture, describes the aim as more control over their own information provision and less dependence on software suppliers. Data is recorded once and used in different processes, and functionally delimited components work together in a standardised way. The five-layer model shows how those layers relate to each other.

In an advisory report we translate that into questions about the specific system. Does the application fetch data from the source, or does it make its own copy that can drift out of step? Are interaction, logic and storage separated, so that you can replace one layer without the rest? And are the links documented APIs, or custom work that only the current supplier understands?

Not every system has to be built entirely according to Common Ground. A map viewer that shows open data from PDOK has different requirements from a case-management system. The advice makes visible where deviating is sensible and where it will cost money later. More about the municipal context is on the page about municipalities (in Dutch), and the open data side on the open data platform page.

TechinFlow also builds software itself. We therefore make clear in advance how advice and a possible later assignment relate to each other.

Is a tender likely later? Then what you receive from us is drafted so that you can share it with all bidders. A scan or proof of concept gives no preferred position and may affect our participation in a later tender.

In practice that means the advice contains no requirements that point to one product or supplier, that the report contains no confidential knowledge that others lack, and that you decide whether and how it ends up in a tender document.

The advice is prepared by Tekin Uslu, founder of TechinFlow. By his own account, Tekin has worked on geo-information, data engineering and IT architecture since 2006. Earlier work by the founder is not a reference of TechinFlow B.V. Who Tekin is and which code he has published you can read on his profile page.

If you first want to know which questions to ask in a tender for a map viewer, read the guide on requirements for a GIS viewer tender (in Dutch).

1. Sharpening the question. In a first conversation we determine which decision the advice must support and what falls outside the question.
2. Documents and access. You supply documentation, contracts where relevant, and read access to code or configuration. Where those are missing, we interview administrators and users.
3. Analysis. We work through the parts in the table above and, where possible, test supplier claims ourselves, for example by performing an export or an API call.
4. Draft report. You receive the findings first as a draft, so that factual errors can be removed before the report is shared.
5. Final report and explanation. A report with priorities and an oral explanation to the people who have to decide.

The scope depends on the question. A check of exit requirements in a draft tender is smaller than a review of a complete application landscape. That is why we agree the scope only after the first conversation. The report remains yours; you may use it internally and externally, also if you continue with another party afterwards.