Curriculum vitae · Manuel Almagro

You can download my CV as a PDF here.

This page used to contain a plain-text version of my CV. No one read it, so I have decided to use this space to do something a bit different.

Consultancy sounds like a buzzword sometimes, and SAP looks like a great, blue, German monolith from the outside. So instead of throwing ATS-optimised keywords around, I will try to explain clearly what my professional life looks like.

Here you can learn a bit about me, explore my area of expertise, see what I do in practice, and find out what I want to do next.

Who am I?

My name is Manuel. I studied physics, but I no longer think about wavefunctions. There is a section where you can get to know me a bit better.
I work in integration.

What is integration?

Integration is about making different systems work together. As organisations grow, they tend to adopt systems that were not designed to communicate with one another. Integration bridges those gaps, allowing systems to exchange information and coordinate their work. I know it might sound boring, but there are many truly interesting problems to solve in this area.
Things used to be simpler. Point-to-point communication (system A sends a message to system B) was the norm. It’s more complex now: the number of systems, the complexity of the logic and the mix of on-premise and cloud technologies have made orchestration a bigger part of the discipline.
Although most middleware used to be hand-rolled (e.g. putting a bunch of scripts together), it has become standard practice now to use an integration platform.
Integration platforms are tremendously useful because they abstract away a lot of the problems that frequently come up in distributed systems: throttling, idempotency, persistence, retries and backoff, correlation, ordering, queuing, logging, etcetera. My activity (and therefore my muscle memory) is based around SAP’s own integration paradigm, which comprises a bunch of tools. You can read about them on my actual CV.
All of these bullet points sound generic by necessity. Integration can take any number of forms. There are many protocols, message formats, authentication methods and communication styles to deal with, along with security problems that may (and do) arise. There are as many potential failure modes as there are possible combinations. A good integration specialist should be familiar with technology at different levels: infrastructure, cybersecurity, architecture, development, cost optimisation…

What is it that I actually do?

My working life has much the same structure as any technology consultant’s: I work on projects for other companies, sometimes providing advice, but more often making architectural decisions, developing integrations and/or improving existing ones.

The balance varies from day to day, but a rough breakdown looks like this:

10–20% helping colleagues with problems they have run into.
10–20% reading documentation, keeping up with new developments or learning a tool/framework I might need.
20–30% talking to colleagues and clients to understand what needs doing and what some process actually looks like.
30–40% developing, testing and documenting integrations.

SAP consultancy has a way of rearranging your day. Things often go differently than expected, but most projects are manageable and get done without (major) headaches.

The amount of time spent talking is deliverate. Once you have reached a certain level of competence, you find that most integration problems are functional or human in nature rather than technical: what the process is actually like, who owns what, what happens when things go wrong, and so on. The technical part is, to be honest, the most fun and the easiest to handle. A former boss of mine said that we are not building rockets, just sending messages around. While that may be an oversimplification for the sake of sanity, it is essentially true.

What do I want to do?

I have seen many failure modes. I have had to live with the consequences of my choices (which, admitedly, seem to have been rather adequate). I have also had some excellent mentors. As a result I can design integrations that work reliably, and I have made architectural decissions that hold up in prod. My goal is to become an integration architect without losing sight of the fun part (building). I dread the incresing importance of PowerPoint, though, as I have seen what it can do to those in the higher architectural spheres.
Sometimes I miss programming. Or, in some sense, I would like to have an experience closer to typical software development. I would like to eventually take up CAP (the SAP framework that allows for code in non-ABAP languages to become part of existing enterprise processes). This means I could learn Node.js, Go, or clean up my rusty Java (since Groovy has spoiled me with all that flexibility) and still gravitate around the same type of problems I solve now.
Some time ago I read SQL Antipatterns: Avoiding the Pitfalls of Database Programming, by Bill Karwin. It is an absolutely excellent book, even if databases are not your focus. I thought it would be very exciting to write something similar for integration. A documented list of integration anti-recipes, and how to fix them. I still don’t know whether a book or something more modest and updateable. I am in the very early stages of planning the contents of whatever this thing might turn into, and I am pretty sure it will take years for it to grow into something more solid.

You can find the specific technologies and procedures I know in my CV. Do not hesitate to send me an email or give me a quick call if any of this sounds interesting to you!