Last week, I attended a workshop of a new initiative in software engineering (SEMAT see www.semat.org). This was the first real f2f meeting we've had. 28 people attended the workshop and one session with around 12 people were working on developing more detailed objectives of the entire initiative.
To develop the objectives we appointed a facilitator. He suggested that we make a usage model for the Semat initiative. But for this blog, what we modeled is not so important. It is the principles that are important. We built up the model on a large bulletin board using yellow, rectangular post-it stickers. A usage was like a use case or a user story. Long side up for usages. Short side up for users outside the system. These were in essence all the instructions we got.
In my last three blogs, I discussed how we can close the gap between the business and IT. I summed up the way forward with the advice to stop thinking about the business as the customer and IT as the provider. Instead, let them work together in teams (similar to members of a soccer team), responsible directly to management.
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.
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.