Chapter 1: An Introduction to Workflow and Windows Workflow Foundation

This chapter gives you an overview of how business applications were and are traditionally developed, as well as an introduction to workflow and the Windows Workflow Foundation platform.

A Little Background

Initially, computers were used at universities to solve mathematically complex problems. The use of computing power was limited to the world of academia for a period of time before the world realized computers could be applied to solve business problems. Thus began the era of business applications.

If you are reading this book, you likely have some involvement in the world of business applications. Maybe you write .NET code, C++, Java, SQL, or other language to help businesses achieve strategic or cost savings goals. If so, you play an important role in the success of modern business.

Traditionally, a business decides that a given project involving information technology is worth doing because it will give the organization a competitive advantage, trim operating costs, or automate a complex manual process. Generally, the project’s software developers gather requirements from the business, perform system and software design, and create the source code. Of course, any software development process worth its salt is much more complicated than that, but you get the idea.

The software development process has evolved greatly in the 50-plus years that businesses have been using computers to help solve business processes. In the not-too-distant past, procedural code was the de facto method for implementing software solutions. Over the past 10–15 years, object-oriented code has given developers a great way to build reusable blocks of code that can be mapped to real-world objects. This building-block approach, when used correctly, can lend itself to helping developers build software solutions more efficiently and quickly.

Order processing, new employee processing, and insurance claim processing are just a few examples of the types of business processes that can be automated. These processes are modeled and documented, at which point a software developer creates his or her interpretation of the process with source code. It is very common in the stages before the actual coding begins for a business analyst to capture the steps in a process and represent the process graphically or with a list of tasks that must be completed and in what order. At this point, the perfectly nice list or visual representation is reduced to source code so that a machine is able to perform the process.

This approach might work in many instances, and in reality, it has been working for many years now. That doesn’t mean there isn’t a better way. Although this book is dedicated to conveying the technical aspects of Windows Workflow Foundation, understanding the problem domain of workflow and business processes can help you, as a developer, relate the technology to its business drivers.