About

Who is writing this

I am Marko Hartikainen, a systems analyst. Thirteen-plus years sitting between business requirements and engineering, trying to make sure both sides ship the same thing — across banking, telecom, fintech and logistics.

Integration work has been the constant: core banking interfaces, telecom billing, logistics data flows, insurance systems. Enough projects to have watched the same failures repeat, and to recognise that a fair number of them were specified into existence long before anyone wrote code. Including by me, earlier on.

Why this exists

I put this series together for analysts I work with. Most of the API material I could point them at assumed the reader would be implementing the result, which is a different job with different questions.

It worked well enough as a set of internal sessions that publishing it seemed more useful than keeping it. If it saves someone a month six they would rather not have had, that is enough.

What I am not

Worth saying plainly, because it affects how much weight to put on any of this.

I am not a developer as a profession. I can write code and prepare specifications, and I have built the demo API this series runs on, but I do not ship production systems for a living and I would not review your implementation.

I am not a security architect. Part 3 covers security controls at the depth an analyst needs to specify them and know who to call — it is not threat modelling, and it is not a penetration test. For either of those, bring in people who do it full time.

I am not neutral about context. Most of my experience is European financial services and regulated environments. If you work somewhere with different constraints, some of the emphasis here will be wrong for you, and your architects will know better than this material does.

Where a topic runs past what I can usefully teach, the training pages point at the sources I would go to myself rather than pretending otherwise.

About the material

All examples are aimed to be synthetic. The demo API, its insurer, vehicles, policies and people are fictional by construction — there is no real data anywhere in this material, and nothing here is drawn from any organisation’s internal systems or documentation.

Where real systems are named — vehicle registries, insurance bureaus, cross-border data exchange platforms — they are referenced as publicly documented examples of integration patterns. No affiliation or endorsement is implied.

Licence

Everything on this site — the training material, the sample specifications and the code samples — is published under Creative Commons Attribution-ShareAlike 4.0. You may share and adapt it, including commercially, provided you give attribution and license your adaptations under the same terms.

If you use any of this to teach, I would be glad to hear how it went — corrections especially.