3-Tier Architecture in .NET Web Applications

The main question to ask yourself is Why Should I (as in what would I gain by) adding WCF to my project. You would gain scalability, but at the cost of increase complexity. Do you need scalability? Flexibility in deployments (different layers can more easily be on different development schedules) is another benefit, but you mentioned that it was a low priority.

I am currently working in an environment with C# WebParts hitting Java WebServices, We have fought back and forth about versioning, tight and loose coupling, APIs, and more, but we always focus on ROI. How much will this architecture change cost over the life cycle of the project, versus how much will we save in maintenance and development cost.

I would say do it. You can add your WCF Service on the same machine that is currently running your web. I believe separation of concerns, flexibility, and scalability would be worth it, as the change should be minimally invasive.

I would agree with your initial assessment. It probably doesn't make much sense to add an additional network hop into the processing of your system. The reason people separate tiers physically is for reuse across applications. That is you have multiple applications calling the same services to perform a part of their work. As you mentioned, there's not a lot of built in logic the business layer provides; and so far there is only one application using it.

It's good that you have separated the tiers logically but a physical separation at this time might be overkill.

Update to address scalability concerns

I would still argue that keeping the BLL on the same physical tier as the presentation layer is the best approach for now. You can scale out by adding more presentation/bll nodes (already addressed if you're using a fat client deployment, simple enough to do with a web application). Also if you find that the database is becoming the bottleneck, most databases support clustering/sharding and other neat tricks to scale out. Only after I've gone down both of these paths (and of course adding in distributed caching), would I look at adding another physical tier.

Before you can go there however, I'd start looking at making a more "hearty" Business Layer than a simple facade to the Data Access Layer. The first step is to consider using a powerful O/RM that does the data mapping for you. Then consider making your business objects more intelligent. There are reams of paper written on Domain Driven Design (the book is a great place to start). Going through the steps of domain modeling, defining bounded contexts, and finding aggregate roots will help you produce an architecture that has natural seams. This will help split your application into self-contained services that can scale independently as needed.