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 whole section of this blog 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.
Integration used to be simpler, so it was considered kind of like an afterthought. Point-to-point communication (system A sends a message to system B) was the norm. Things are more complicated 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 integration. This means that a big part of business logic now relies on properly understanding non-technical processes and deciding when and how to call relevant systems.
Integration can be done in a completely custom way (e.g. by putting a bunch of scripts together) or using 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, etc.
Notice how all these bullet points sound very generic? That’s a 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 arise in a real-world scenario. 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, cost optimisation…
Many vendors have their own integration platform. While the concepts are the same (authentication, the protocols involved, logging, etc.), each platform has its own way of doing things. My day-to-day work (and therefore my muscle memory) centres on the SAP ecosystem. SAP’s modern middleware has been repackaged a few times over the last decade: it was initially called HCI, then CPI, and it is now called Integration Suite.
SAP has adopted a philosophy called clean core. Instead of messing directly with the ERP’s native capabilities, you are encouraged to move extensions out of the core. One way to do this is to move things onto a platform called BTP (Business Technology Platform). It is essentially a platform where you can run software, both SAP’s own and made to order.
How does this relate to the previous context? Both integrations and a myriad of other SAP and custom applications can live on BTP. For this reason, I am also spending more and more time doing stuff on BTP: user and role management, authentication, setting up new services and a lot of housekeeping.
Although integration platforms tend to be marketed as no-code or low-code tools, there is a fair amount of programming involved as soon as the logic gets a bit complicated. Most of my code lives on private platforms and is written in Groovy, a Java-based language.

What is it that I actually do?

I am currently a consultant, so my services are hired through my employer by different companies. A typical project might look like this, which I am aware is fairly standard:

Stakeholders usually have something they want to achieve. They talk to technical & fuctional experts along with sales representatives to come up with the details of a project: scope, a calendar, people involved, costs, and so on. Having a good project manager involved completely changes the experience for those of us executing the project.
The project is born along with a requirements sheet, which can be incredibly detailed or a bare-bones description of a desired solution. Usually depends on how tech-savvy the stakeholders are and the resources spent in the discovery phase.
We do the actual job of designing, building, testing and documenting the solution. The involvement of the stakeholders can vary, but I find having them around giving feedback the most direct predictor of how the project is going to do. An absent client usually means bad news later on.
The solution is deployed to production and typically there is a period of hypercare during which we can be on call in case anything unexpected happens.

The word typical is doing a lot of heavy lifting, as there are many variations of this. Sometimes requirements change mid-project. Or you go into a half-finished project because someone went on medical leave. Or the project is not building, but teaching something that you know to an internal team of some other company. Or there is no project at all, and instead what happens is that some API exploded and a client has not been able to ship deliveries for three days and they desperately need someone that might know how to fix it.

Anyone who has spent any amount of time in SAP consultancy knows that things can (and often go) different than expected, but generally most projects are doable and get done without major headaches.

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.
I am also finding event-based architectures very interesting because they solve a lot of the problems that older architectures frequently face (see an example). This is something I’d like to keep exploring.
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.

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!