I am part of a small software company that specializes in small to medium-sized business applications and my experience with distributed architectures/SOA is limited. Please let me know if I'm going about this all wrong.
We often start development on small business applications, where a distributed architecture seems like overkill and will not be implemented as such. However, in some cases, the project expands way beyond the original scope, and the preferred solution may later become a distributed one.
How do we ensure from the very beginning that this transition becomes as smooth as possible, with a minimum cost of performance and (primarily) time? Specifically, I'm looking for advice in regard to the architecture of the solution in order to achieve this.
Take this simple example:
- At first a windows application is running on several computers, invoking all business logic locally in an assembly that is distributed along with the application.
- Later, the business logic is moved to a central server, and the windows application must now communicate with the business layer through a WCF service.
The obvious answer here would be to just create the WCF service from the very beginning and have it run locally on each machine, but my initial thought was that this could cause undesirable time consumption on projects with strict deadlines, due to increased overhead in development (having to maintain the intermediate layer(s) etc.).
One of the concrete problems with the initial architecture is that instances of objects are passed from the windows application to the business layer, thereby creating a dependency that could break code when moving to a distributed solution.
By 'simulating' a distributed solution, we could ensure that our developers aren't unintentionally introducing these sorts of issues.
- What is the best way to achieve this scalability?
- Am I wrong in my assumptions regarding time consumption and performance?