Microsoft .NET 3.0 should have been called .NET 37 to do justice to the magnitude of the changes in Windows Communication Foundation (WCF), Windows Presentation Foundation (WCF), and Windows Workflow Foundation (WF) from .NET 2.0 to .NET 3.0.
WCF lets you build world-class systems with an amazing productivity boost, allowing you to focus on the business logic rather than the plumbing, yielding an unprecedented reduction in application complexity. No more dealing with security, threads, transactions, hosting, remote calls, reliability, queuing, instance management, and so on. And to top it all off, WCF is also extensible and interoperable.
WPF allows you to build a modern UI, with visual effects that would require blood-letting in Windows Forms. WPF allows for combining text and tables or even images with ease; it even allows the UI to be composed dynamically.
WF (redone in .NET 4.0) allows you to separate the execution sequence of your business logic from the individual activities in the sequence, which enables you to encapsulate the most volatile portion of many applications, capturing the workflow visually, and containing the changes. You can host the WF engine in your application, thus enabling the end user to modify the system post-deployment.
Given this power, adoption of WCF, WPF, and WF is nowhere near where one would expect. Aside from a few early adopters, developers have ignored these technologies. This is not on par with how the industry has embraced .NET. I believe the cause for the lukewarm adoption of the foundation technologies lies in what they imply and require.
As powerful as WCF is, it’s of no use without an architect (or system designer) to decompose the application into a set of core services that can satisfy any present or future requirements. The wrong decomposition is literally the kiss of death for most systems, creating unmaintainable internally coupled applications. WCF shifts the center of gravity; the bulk of the effort is spent designing what you want to do, and the act of doing can be reduced to a single line of code or an attribute. Yes, you save development time, but more importantly, you gain the ability to tackle degrees of complexity and connectivity that are simply prohibitive with regular .NET. But most teams don’t have a dedicated architect; without the up-front investment in design, teams try to program their way out of the complexity, and they don’t benefit from the power of WCF.
WPF is an amazing tool for creating UIs, but most developers simply don’t know how to design good a UI. Developers lack the artistic flair, the understanding of UI flow, the knowledge about what to highlight for usability and ergonomics, and the awareness of how to maximize use of screen real-estate. For that you need UI designers—experts in both usability and graphic design—who can use WPF (or Silverlight) design tools, generate the XAML, and pass it to developers. However, most teams simply don’t have graphic designers; without them, WPF can impose a disproportionate penalty in complexity and learning curve and become more painful than it’s worth.
WF has the potential of transcending programming languages as a way of stitching applications, but its use is predicated on having a technical business analyst who knows the key workflows the application needs to support, and who can break workflows down into constituent activities for developers to implement. But people who straddle the worlds of technology and business are rare, and most teams don’t have them. Without dedicated technical analysts to design the workflows, WF merely adds complexity to a project, and developers feel they are better off coding the execution sequence rather than modeling it.
I’m sure you noticed a pattern here: All three technologies require a new design role, which is very difficult to staff, and within a team’s current organization and management structure may not be recognized as a need. My opinion is that until industry adopts the design role (architect for WCF, UI designer for WPF, and analyst/designer for WF) for every team, the technologies introduced with .NET 3.0 won’t deliver on their potential. I think the adoption of the design role is inevitable because teams who embrace that missing piece will have such an advantage that everyone else will have to catch up.
I don’t know how long it will take. Look at the evolution of QA resources: In the 70s and 80s, developers did the testing. By the 90s it was clear that every decent project should have dedicated QA resources. I suspect we’ll see a similar evolutionary course with the design role, and I can only hope it will take less than a decade or two.
