I have during a long time build some kind of “static” applications; I have used Domain Driven Design for most of my solutions during the last three years. Most of those apps became static. During the last year now I have spend some time on Process-Orientation (PO). As you may know a company has several of process. To simplify the process they sometime want to replace some processes or part of a process with a software of some kind. Most of those apps became static. They need to go in and change the app if the process needs to be changed. This could even result that the old app is not good enough and a whole new one need to be build. The whole process will cost company money. Sometimes I don’t even think they get the money back by simplifying the process, especially not if the use a static application. So I (not only I) have notice that more and more company want to minimize the cost of building or changing an app based on changes in the business (for example when a process is changing). So what I think we need is to be more process-oriented. Look at the process, build activities for the process. The activities is something developer can help companies with, the process-schema itself can often be created by the company, for example using BPML. So the new focus for developers will be to create “activities”. Those activities are often small, but can be complex. But if an activity will became complex to build, we should see if we can solve it by creating an inner process instead that can be used. If not, we can apply for example DDD when we create the activity, either as a service or a static component. I think the important thing is to make new applications dynamic, at least as much as possible. If they need new activities (which I think should be created as re-useable units if possible) they get some help of creating them. Here is the developers’ role. I saw a large process-schema written after the BPML, and the activities were really small. The process that was created should replace an “errand managing system”. Instead of using a static application as an “errand managing system”, they draw processes.  It was really cool. If a process changed, the company simply changed the schema and hit save and run button, and the process-engine run the process after the new schema. If they need a new process in the company to solve some problems, they simply draw the process. There was no need to go in and change a static app, and deploy it. Can it be more dynamic!? Together with PO, I can see a great use of SOA, where the activity in a process is a “call” to a service. Today we have a relative great process-engine, and that is the Microsoft Workflow Foundation, what we don’t have is a great designer for companies that follow a standard like BPML to create the process yet (But support for BPEL exists). But we can create one and use the WF compiler with the XML file that defines the process; we can also help the company as long as they provide us with some kind of schema and then use the WF designer integrated into Visual Studio.