The application design/code should not be a constraint to support scalability.
I'll take a best practices example here - The app should not have hardcoded absolute paths that would cease to work on another server. Similar approach goes for environment variables, shared content storage, session based use cases etc.
When you say SW, do you mean AEM (as software) or your custom application code (as software)?
What if you add a new node for horizontal scaling but your custom application code can't even support it because of various reasons? Would that still count as a scalable system? Hope you can connect the dots and see the big picture.
These are general concepts/guiding principles to achieve what you want to do. The implementation of these principles might have a range with specifics tasks based on a lot of factors e.g. if you are on Cloud vs on-premise etc.
If you've any specific questions, please share your requirements and details about your existing setup. Alternatively, you could open a ticket with DayCare and ask for specific recommendations regarding your use case.
What is your use case/context here? You may need to understand the concept before concluding how scaling works. E.g. TarMK Farm is also an example of scaling (read-only since its not clustered). Whatever setup you currently have, if you are able to more nodes without breaking your app etc., that would be termed as a scalable system.
Below are the definitions that might help for the concept:
scale horizontally (or scale out/in) means to add more nodes to (or remove nodes from) a system, such as adding a new computer to a distributed software application.
scale vertically (or scale up/down) means to add resources to (or remove resources from) a single node in a system, typically involving the addition of CPUs or memory to a single computer