Interesting question that I've heard asked on several occasions.

Before we consider an answer, we need to understand why the question "Why use WF?" is being asked. My assertion on the answer to that lies in the organic growth of web applications since they became 'the way to do things' inside an organisation.

My assertion is this: there a many instances of mid-sized applications (which are now possibly business critical, although not necessarily envisaged as being such at the point of design) that have grown-up over the past 5-6 years out of the ‘web app boom’ constructed in ASP and more recently ASP.NET that have some kind of lightweight ‘business logic’ requirement. This logic layer has probably been constructed in some procedural or data-driven (maybe declarative?) way for the application at the time of construction to best satisfy business requirements. These typical apps will also have policies and rules and flow and external communication and so on. Although these abstract concepts are common to each system, it's likely that a custom point solution is present in each.

Maybe many of these could be defined in WF and thus this consolidation of the business tier implementation strategies using WF could provide powerful gains for development teams and analyst teams.

Consider some specific points:

• Smaller development footprint: removing a custom developed layer reduces chance of development errors. (How much developed code represents the current custom solution? What expertise is required to maintain? How many custom solutions are there?)
• Change efficacy: creating a series of ‘building block’ activities and then using WF constructs to join them up means that a the blocks conform to a well-known process so that when change is required, this change can be completed efficiently and effectively. Analysts, architects and developers understand the same process of logic and policy construction across all systems. (How hard is this to effect currently? How often does testing fail? Where is the mismatch between analysts, actual process, and the developed system?)
• Hosting options: WF can run inside a variety of hosts meaning the same processes can be accessed from a variety of systems. (How do the current systems work? Targeted at web when maybe a richer client would be preferable?)
• Services: Tracking services mean that a clear audit trail can be defined for the behaviour of the computation. Persistence services mean that resilience and scaling can be introduced (and the ability to test prior computations, reconstruct behaviour). Services could be extended to (for example) measure cost of computation. (Again, how much code represents efforts to provide these services via custom development? How repeatable and understandable is the current implementation?)
• Policy and rules: WF has a declarative rules engine that could define policies for execution, or decision-making rules in the computation. Because rules can be declarative, you can push rules definition upstream to business analysts or power-users providing business agility and low-cost, high-speed change without endangering a core process. (Actually the same goes for workflows too). (How are rules defined in custom systems? How hard is this to change? Does it require development effort?)
• Skills: As WF is a core part of .NET then skills are standard and transferable (and therefore marketable: incoming or outgoing). (How much time does it take to skill a developer on custom systems? Are there any ‘key-man’ dependencies?
• Performance: Does it work? Well, take a look at this whitepaper. http://blogs.msdn.com/pandrew/archive/2006/11/10/wf-performance-peaks-at-10308-wf-instances-per-second-on-lab-environment.aspx

So, I think that if you're looking at these points, and the questions raised, then consider whether WF is a suitable strategy to form the heart of application logic layers. I'll draw a diagram on this next!