Hi Michał,
thank you for you reply. I’d like to clarify a bit and hopefully come to a clearer ground for an answer I am seeking.
I agree completely with all the thing you’ve pointed out. There is not a magic formula to give us number of services or to draw us service boundaries. However, there is a practical side of things. I really like the DevOps principle, where devs are responsible for the code itself, the building, deployment and running the software in production. If you take this into account, then you have to think hard about the mapping that would be appropriate between the logical grouping of the ACs and the runtimes, because the runtimes should be owned by one single team - right? At least, that’s my premise.
Regarding this, I could have any number of services - say 3 which can have any number of ACs that are deployed into 3 runtimes, that are owned by 3 teams. So far, so good.
If my company is growing and I want to introduce another team, how should I reorganize then? Should I keep those three services regardless of the organizational change? Should I introduce at least another runtime? Should I even care about those things?
This is where it breaks down for me. The growth of the organization should also be supported by the architecture in such a way that every team has their own mission and responsibility. With services and ACs vaguely defined I don’t see the clear picture.
I mixed two different questions (this one and SOA Organizational aspects - who is responsible for the runtimes?) into one, because I think it is relevant. And under growth of the organization I mean rather rampant growth 
Say 10 or 20 Teams for the same company that used to develop the software from one team upwards.