Mindmap: API Manager

9 items to consider when selecting an API Manager

One of my hobbies is photography and when I bought my first camera it was a compact camera. I soon realized and experienced that I needed a reflex camera (SLR), because the resolution, speed and quality was far more better. I did not realize it until I really used the product. Again after a few years I noticed that I did not use my camera a lot. Why was that? Because the camera was pretty big and unpractical to take with me all the time. Then I read about a system camera, which has the advantage of being small, but you still have the possibility to switch lenses. I never regretted my choices, because at the time it seemed to be the best choice. Today there are a lot of camera’s with a lot of possibilities and specifications. Which one to pick? It depends on a lot of factors and what you want todo with the camera, like portret-, landscape-, sport- and street photography.

The same holds when selecting a software application, in this case an API manager. In my opinion there are 3 options to select a product:

1.    Just go with your gut and select one
You think you know that you decide for yourself but your subconsciousness has already decided for you. Go with your feelings.

2.    Try-out period
In this case you try-out a product for a couple of months. Using it the way you think and start experience the capabilities you really need.

3.    Thorough investigation of capabilities
Start a trajectory with collecting requirements, make a long-list, make a short-list, arrange demo’s, rating the products, selecting the most suitable, install- and configure the product, defining the governance around it and start using it.

The difference with a camera is that you are the only one to decide (most of the time). In case of a software selection, you can be tided by regulations and a lot of other persons have different feelings and meanings. In case you need to go for option 3 this blog will give you 10 categories of requirements to think about.

A camera has several important components, like the body itself, the light sensor and the lens. An API manager also has different logical components which are:

·         API Publisher
A component where APIs are described, policies are defined and APIs are published to the gateway(s)

·         API Gateway
The API gateway is the runtime component that will process the API calls. It will validate the policies that are defined for the API and it is the most important component to secure your gateway to the backend systems.

·         API Portal
The component where consumers can search for-, test-, read documentation about- and subscribe to APIs.

·         API Analytics
A component to store data about the API usage, metering and monetizing capabilities.

So what are the 10 categories of requirements you need to think about when selecting an API manager? Here we go

1 - API definition

Most of the API Managers will support the contract first paradigm.

·         Do you need the capability to define your API using an editor (for example Swagger(OpenAPI), RAML or a proprietary format)?

·         Do you need to import existing API files? Import WSDL?

·         Add documentation? Which formats do you want to support for adding documentation?

·         Do you want connections to other content management systems?

2 -  API Gateway

·         Do you need a separate gateway for internal- and external usage? This can be interested for example in case the security policies are more strict for external use or the performance for internal traffic must be different.

·         Do you want to have horizontal scalable- and central managed gateways?

·         Do you need micro-gateways that are even more distributed than the full blown brother gateways? Microgateways can be interested for Microservices architecture.

·         Do you want mediation capabilities or do you use other products to do the mediation and is the gateway purely used to pass on the messages and only checking the policies?

·         Which protocols do you want to support? HTTP or also JMS, MQTT, Websockets or AMQP?

3 – Deployment

The deployment possibilities are important capabilities of the product. There are several possibilities: Cloud (SaaS and/or own DC), on-premise, hybrid.

·         Do you want to have the flexibility to be cloud agnostic? So deploy possibility on Google Cloud, but be able to migrate to AWS or Azure?

·         Deploy possibilities on OpenStack, Apache Stratos or docker containers?

·         Another important aspect is if the components are separately deployable and scalable. A gateway may have other scalable requirements than an API portal and also have other availability and security requirements. It is a pre that the API manager product can support this kind of deployment options.

·         How is the product handling patches and upgrades? Does it require to shutdown the components or are rolling upgrades possible with zero downtime? Note that this is more important for the gateway component than for the portal and publisher components.

·         What kind of authentication/authorization do you need?

·         Do you need connection to your internal IAM, or maybe even to an external IAM?

·         Do you want social authentication possibilities like OpenID and Facebook.

·         Do you need multi-tenant support, so that you have clear separate isolated environments with your own users and access rights.

·         In case external database storage is used, which database(s) do you want to be supported.

4 - Policies

There are several categories of policies:

·         Traffic/routing policies (i.e. caching and rates/quotas)

·         Mediation policies (data mapping)

·         Security policies (note: these are described in the security section)

·         Extension/custom policies

Next some capabilities to consider:

·         How are the policies managed? Are they centrally managed within the API publisher and can they be dynamically updated?

·         Can the policies be externally stored in a configuration management tool and integrated within CI/CD street?

·         What is the granularity of the policies? For example: on key, subscriber, application, product, api, api method.

·         Is it possible and easy to add custom policies.

·         Do you need mediation policies like data- and protocol transformation or is this done by another functional component within your architecture.

5 – Analytics
One of the capabilities of an API manager is the metrics about the APIs. You can think about:

·         API usage per subscription, application or API

·         API latencies

·         API response times

·         API errors

·         SLA

·         Security

The following is a list of capabilities you can think of when analyzing the analytics requirements:

·         Some products will have dashboards out-of-the-box which are dynamically updated. Some only have logs on which you can implement your own reports.

·         Do you need monetization capabilities or use your own mechanism to implement this.

·         Is it possible to define your own custom dashboards and is this easy task.

·         Is it possible to export your analytics data and in which formats (for example CSV, XML, PDF, Word).

·         Is it possible to automatically export the data to a datalake or 3^rd party analytics (like Splunk or Google analytics). 

6 – API Portal
The API portal is the frontend for developers and consumers of your API. APIs can be found, tested and subscribed on. In fact it is your shop that is the entry into your API world.

·         Should the portal be customizable to your own brand theme.

·         What should the access control and visibility of the partner-, public- and internal APIs be.

·         Should it be possible to add your own custom flows or hooks when some important events occur, like a subscription must be approved before it can be used, or some special actions must be taken in case a new application or product is created.

·         Do you want community support, like discussion forms and FAQs, where consumers can help each other and ask questions. Or maybe to enter problem reports in case there are troubles with using the API.

·         How fancy do you want to have your sandbox to test APIs.

·         Generation of client code for all kind of languages like python, nodejs, .net or java.

·         Do you need connection with your own content management system, for example office 365.

·         Internationalization can also be an important aspect to consider in case you need Multilanguage support.

·         What should be the search capabilities, will it only be based on tags or text content, or do you need more fancier capabilities like proposals based on earlier subscriptions.

7 - Product

The price of the product is also important of course, but there are also very important other items to think of (I think even more important):

·         How is the support? Is there support within your country and do they speak your language.

·         How is the customer base within your country so that you can learn and ask help from those customers as well. They have already practical experience with the product so that they can indicate where the pitfalls are.

·         Do they have a good and clear vision with the product or is it almost end of game.

·         You can also look at the Gartner and Forrester reports of course but local support can be very vital for your company.

8 - Security

One of the key aspects to buy an API manager is the security of the data and services of your organization. There is a lot to read about this so I only mention a few of them.

·         Which kind of token support do you want, for example OAuth 2.0, OpenID, normal keys.

·         How do you want to protect your backend, e.g. two-way-ssl, basic authentication, payload encryption to have end-to-end data security.

·         Integration with your internal IAM and/or external IAM system.

·         Single-sign-on in the form of SAML tokens.

·         Role based access for example XACML or OAuth 2.0 scopes.

·         Black and white listing of IPs so that only explicit set of IPs and domains are able to access the APIs.

·         The security keys and identities need to be protected too.

·         Support of federated identity in the form of JWT.

·         VPN connection to your IT servers in case the solution is public Cloud based.

·         The product is secured and protected for large payloads, DDOS attacks and SQL injection.

·         Is it needed that the product is certified and compliant with a security standard, like PCI DDS, HIPAA, SOC1 and SOC2.

9 – Operations

The last item on the list is how the product is operated. Do you need real-time monitoring of your APIs and be proactively alerted in case something happens. Examples are out of resources, APIs are not reachable anymore, the latency becomes too high, SLAs are not met. Do you need the possibility to inform users in case the state of an API changes, e.g. the API will be deprecated or becomes obsolete. What are the disaster recovery capabilities and corresponding RTO.

Conclusion

There are a lot of items you have to think about when selecting an API manager and you can make it as complex as you want. From following your feeling to a broad investigation and analysis trajectory. Take your pick and do what is necessary within your organization.

Be aware that the API manager journey does not end here. Just when you selected your camera you have to use it, start to experience how you use its functionality in different situations. How the photos are governed and how you setup a whole photo project.

You need to define the governance processes around the APIs as well, but that is a whole different story.

Feel free to give feedback on this blog, or contact me when you have questions and remarks, or if I can help you with the process!

(Dutch) Integreer ERP en productie zonder hoofdpijn met ISA95

1.1      Introductie

Veel bedrijven hebben moeite om de business systemen aan te sluiten op de productie vloer systemen. Dit zijn bedrijven die producten maken en waarbij productie locaties de daadwerkelijke producten maken. Bij de kantoren worden sales orders ontvangen die worden doorgestuurd naar de planningsafdeling en waarbij er uiteindelijk productie orders worden verstuurd naar de productievloer. Deze supply chain bestaat dan uit plan-source-make-deliver.

Figuur 1 ISA95 context

Veel bedrijven hebben vaak te maken met de volgende uitdagingen:

•         De business (sales, managers, planners) praten vaak een andere vaktaal dan de medewerkers op de productievloer
•          Bedrijven groeien gestaag door en er worden vaak nieuwe productielocaties bijgebouwd en/of overgenomen. Dit leidt dan weer tot integratie uitdagingen.
•          Nieuwe producten die worden geïntroduceerd moeten nog volledig worden opgenomen in het productieproces. Het kost veel tijd om dit goed te integreren met de processen op de productievloer

·         IT systemen die gebruikt worden in de verschillende lagen hebben vaak andere eisen (denk aan beschikbaarheid en performance)

Klinkt dit herkenbaar en ervaar je dit ook als frustrerend? Wellicht is de ISA95 standaard een oplossing voor je!

Dit artikel gaat in op de mogelijkheden van ISA95 en hoe deze standaard kan helpen bij bovengenoemde uitdagingen. Laten we beginnen om kort uit te leggen wat ISA95 is.

1.2      Wat is ISA95?

ISA95 is een internationale standaard en bestaat uit modellen en terminologie die nauwkeurig in kaart brengen welke informatie moet worden uitgewisseld tussen systemen gericht op verkoop, financiën en logistieke systemen gericht op productie, onderhoud en kwaliteit. Het geeft handvaten voor applicatie rationalisatie en het scheppen van overzicht welke informatie moet worden uitgewisseld tussen de kantoorsystemen en de productieautomatiseringssystemen.

Figuur 2  ISA95 scope

De standaard richt zich niet op de productievloer zelf. Hier kunnen ISA88 en ISA106 helpen, maar dat is niet de scope van dit artikel.

Welke modellen heb je dan allemaal tot je beschikking?

1.3      De modellen van ISA95

ISA95 kent verschillende modellen voor de rationalisatie van het integratie landschap in beeld te brengen.

Figuur 3  ISA95 modellen

· Domain Definities
Het begint met het aanbrengen van de scheiding tussen het zogenoemde Enterprise Domain en Control Domain. Dit is de scheiding tussen respectievelijk de business en de productie functies.

· Functies
Daarna worden de functies verdeeld over deze domeinen. ISA95 heeft een overzicht van generieke functies die in elk bedrijf een rol spelen.

· Relevante functies
Relevante functies worden in de “functions of interest” benoemd. In dit model wordt ook aangegeven welke systeem applicaties verantwoordelijk zijn voor welke functies.

· Informatieflow
Met de “information flows of interest” wordt aangegeven welke informatie er tussen de systemen wordt uitgewisseld tussen de verschillende lagen.

· Categorieën
De informatie wordt verder opgedeeld in categorieën en hier verder uitgewerkt. Het gaat hierbij om productie-, kwaliteit-, performance- en/of inventory informatie.

· Informatie definities

Alle data definities van de benodigde data entiteiten worden vastgelegd in detail.

Figuur 4  Informatie definities

ISA95 gaat niet verder dan de logische data definities en de implementatie wordt overgelaten aan de bedrijven. Hiervoor kan het interessant zijn om ook naar B2MML te kijken.

1.4      B2MML

B2MML is een verzameling van XML schema’s voor de representatie van de ISA95 data entiteiten. Deze kunnen gebruikt worden in het berichtenverkeer tussen de verschillende systemen.

1.5      Conclusie

ISA95 heeft een standaard begrippenmodel dat de verschillen in vaktaal tussen de business en productievloer kan weghalen.

ISA95 standaardisatie van interfaces maakt integratie eenvoudiger en kan de migratie met nieuwe locaties versnellen.

Aangezien ISA95 een scheiding maakt tussen de business- en de productie processen worden de processen flexibeler en kunnen de systemen in de verschillende lagen afgestemd worden op de behoeftes in die specifieke laag (zoals bijvoorbeeld beschikbaarheid en performance).

ISA95 en B2MML standaarden helpen om de integratie tussen business- en productievloer systemen te definiëren en te implementeren. Het helpt om de bedrijfsprocessen te scheiden van de productie processen en hiermee flexibiliteit te creëren.

Wil je meer weten dan neem contact met me op, want ik heb een implementatie gedaan bij een klant en kan je wellicht helpen.

Architecture is sexy or a paradox?

Op 15 november 2018 hebben we met SynTouch het Landelijk Architectuur Congres bezocht in
de Brabanthallen in Den Bosch. Dit jaar was het thema “Paradoxen in Architectuur”.
En dit jaar konden we een feestje vieren, want het LAC bestaat 20 jaar !

Normaal gesproken is het beeld van een architect saai, oubollig en werken vanuit een ivoren toren.
Kijken of hier langzaam verandering in gaat komen en zelfs sexy gaat worden.
Of blijkt dit toch nog steeds een paradox?

Een kijkje in de wereld van architectuur

De dag begon met twee keynotes. De eerste keynote ging over het feit dat we aan de vooravond
staan van een nieuwe digitale revolutie. Een betoog over het feit dat steeds meer wordt
geautomatiseerd en dat we als mens worden ingehaald door de techniek. Het zal spannend worden.

De tweede keynote ging over de reisorganisatie Tui, die bezig zijn met een nieuw business model
te implementeren om met de concurrenten de strijd aan te kunnen gaan.
Denk hierbij bijvoorbeeld aan de Uber, Airbnb en Bookings van deze wereld. Deze bedrijven zijn
exponentieel gegroeid, waarbij ze zelf niets in bezit hebben. Ze bieden een platform aan waarin
ze partijen bij elkaar brengen. Tui wil het voorportaal zijn waar klanten hun reisbeleving beginnen en
waarbij de beste opties worden voorgesteld. Hierbij speelt data, artificial intelligence, analytics en
integratie een belangrijke rol.

Twee enerverende keynotes, die tot inspiratie leidde.

Toen was het de beurt aan de trackleaders om hun jaarlijkse elevator pitch te houden.
Dit is een traditie waarbij een track “verkocht” wordt aan het publiek. Dit jaar waren er 7 verschillende
tracks:

• Renaissance van Architectuur
• Viable System Model
• Ethiek en Architectuur
• Join forces of researchers and practioners
• Blockchain
• Solution Architecture
• The 4th industrial revolution

• 
• 
  
• Solution Architectuur

Dit was de track die ik persoonlijk heb gevolgd (met een laatste uitstap naar het VSM model).
De onderwerpen van deze track gingen over distributed systemen, event driven architecture in een
Microservices- en analytics omgeving, cloud agnostisch bouwen op PaaS diensten en business
agility met architectuur.

Helaas geen nieuwe inzichten verkregen tijdens deze sessies. Wel een goed verhaal over business
agility en architectuur met een meer uitvoerende rol van de architect in de teams.

Viable System Model

Dit was de track waarbij de energie er vanaf droop. Een heerlijke ADHDer voor de groep en een
inspirerend verhaal over deze (voor mij nieuwe) methode.

Mocht je meer willen weten over deze (wetenschappelijk bewezen) methode dan werd er aangeraden
de volgende boeken eens te lezen: “Brain of the firm” van Stafford Beer en “Waarom gaan dingen nou
nooit eens een beetje vanzelf ?“ van Ed van der Winden. Het laatste boek geschreven door de
entertainer himself en een stuk leesbaarder dan het eerste.

In feite is alles een systeem dat beïnvloed wordt door zijn omgeving en waarbij er een balans wordt
gezocht tussen het heden en de toekomst. Een beetje een vaag verhaal maar het heeft mij getriggerd
om eens wat meer te gaan lezen hierover.

Conclusie

Het congres was weer een leuke dag om wat contacten op te doen en ervaringen uit te wisselen.
Verder weinig verrassende nieuwe inzichten verworven.

Ik moet helaas concluderen dat het stoffige imago nog steeds wel een beetje hangt aan de architect
en weinig seksie. Maar goed het is ook een ambacht waarbij je toch wel wat meters gemaakt moet
hebben om dit goed uit te kunnen voeren. Ervaring, veel je neus stoten, proberen, opstaan en weer
mee met de volgende hype. Het blijft in ieder geval een mooie gelegenheid om ervaringen uit te
wisselen en elkaar te inspireren. Laten we vooral doorgaan met dit mooie beroep.

Fijne avond LAC en tot de volgende keer !