Many organizations have achieved a degree of process maturity (reliability, discipline, consistency) only by paying a very heavy price – they have become addicted to documents and document templates.
Unfortunately, it can happen all too easily. Most processes end up being document-centric even though they never set out to be so. They start by offering useful process guidance on how to progress the project in a controlled way, in the form of a set of activities, each of which is defined in terms of the artifacts it produces. Most artifacts are documents of some kind and the process helpfully comes with templates for each document – a template is better than having to start with a blank sheet of paper, after all. The project milestones we need to pass through are evidenced using the documents, and the whole thing hangs together nicely. Read More
Software development processes have long advocated structuring a software solution around a domain model of the problem space being automated. A domain model shows how our business processes add value by progressing the states of our key business entities. These entities and their life histories tend to be much stable over time than the processes that surround them. Modeling the entities and their states enables us to experiment with different ways of achieving the same outcomes (state progressions) as we seek to rationalize and automate these processes.
I first learnt about the power of domain models more than 25 years ago when I first applied the Jackson System Development (JSD) process. This approach involves modeling the key conceptual entities in the problem domain and the business rules that define how value is delivered by advancing the value states of these key entities. Add a few key business attributes and you now have an executable model of your problem domain / business. You can then simulate the execution of your business merely by slapping some rough-and-ready user-interface screens onto these entities.
How many people know that approximately 40% of the cost of a truck are software costs or that it takes millions of lines of code to develop a mobile phone? The answer is unfortunately, very few. People do not view these things as software products! Software exists in so many things that we touch on a daily basis, but it is hidden under the shells of pacemakers, cars, etc., and the amount of software included in a “normal” product, grows every second.
To close the gap between business and IT we need to get them to play on the same team, as said in my two previous blogs. I compared this team with a soccer team in which the participants are not just specialists but also generalists – they can all kick the ball when called upon.
I was celebrating my birthday in Japan with a team I mentored. The manager was present and he asked me politely what my birthday wish was. I said I wanted to slim down without thinking much. It was something I wanted, but had not been succcessful. But through the weeks following that, by being conscious about calorie intake and output, spreading my food intake, reducing portions, adding some exercises, my weight reduced dramatically. I call it "dramatically" because I never lost that much. Within about a month, I lost 8 kilograms, and then another 6 the next month and another 6 on the third. I had to buy a new pair of pants twice. There were no dieting pills, no starving myself, no gym, but just some self-control, having daily stand-up meetings with my weighing scale and food calorie labels and of course some discipline and commitment with encouragement from weight logs. 
We in the software development industry face a seemingly intractable problem. We have learnt the lesson that prescriptive process is a bad thing. Process bureaucrats sitting in ivory method towers, telling highly-skilled professionals how to do their job and setting the process police on them if they don’t follow their instructions to the letter, can (unsurprisingly) be really quite damaging. It disempowers the development team and engrains apathetic attitudes along the lines of “When we inevitably under-deliver, it will not be our fault, but the fault of these ludicrous process hoops that we are forced to jump through, instead of being able to focus on writing great software”. The agile revolution was software engineering’s way of learning this lesson, and the agile manifesto pledge to value “people over process” and “software over documentation” has got to be right. But (… there was always a “but” coming …), we are already finding that the opposite extreme of little or no explicit process isn’t going to cut it either, because it leaves too many problems unsolved, such as: 
In an earlier blog (Nov 2009: Closing the Gap between Business and IT) I described the gap between business and IT and suggested a way forward: we must speak the same language. That language must be more than just a spoken language; some simple drawings or models are often useful. However, beware of business models inspired by software models, which assume an underlying abstract computational machine. We must work together pursuing common goals and results - without resorting to passing documents from one side to the other. And we must deliver high-quality results on regular intervals.