The Domain Model isn’t significantly different than several other types of box-and-line diagrams; You may already be familiar with Conceptual Data Models from the ER world, Concept Maps from systems thinking or the Fact Model from business rules approach. The subtle difference is that you identify, and define the concepts (nouns) important to the business and the relationships (verbs) between them. This forces a common understanding among the participants, and flushes out undeclared / implicit assumptions.

It is equally important that the domain model be independent of implementation…a good domain model captures the essence of the business, and therefore is equally applicable to the AS-IS and TO-BE perspectives.

Failure to have a common understanding of the concepts of the business, and declaring assumptions, is at the very heart of bad process design and application systems requirements.

In my experience, you can only get a rich understanding of how best to innovate effectively from AS-IS analysis that comprises of customer-perspective performance data as well as activity steps.

TO-BE analysis leaves a lot of room for conjecture and inaccurate assumptions to throw the process off track.

Are you able to provide an example of the Business Domain model? How does it compare to a standard strategic analysis?

Thanks
Craig

When I initially read your comment I thought you were referring to using the organisations systems as a basis for the initial analysis, and therefore I reflected on when I have seen high-level systems diagram used as a starting point. In these cases I would feel confident to say that 100% of the time it has led to the wrong analysis being done – because as the systems were built, process compromises were made and compounded so that the systems no longer represented the processes that the organisation needed to support.

Have you had these experiences?

I would think that a “thorough understanding of the as-is … (including) time in motion” is a high-level of detail for as-is analysis, where would you draw the line to simplify what is being done on the as-is?

Cheers
Craig

After all, in general, the as-is is the problem, so why spend too much time documenting it, when the chances are that you are going to change it!

I agree with you that focusing on the as-is process can ground participants in the current state, making innovation difficult. And I have also experienced the challenge of getting people to accept a future state that diverges to far from their current state / comfort zone.

When the future state is likely to be significantly different than the current state (i.e. not just an incremental adjustment) I prefer to start with establishing an explicit understanding of what the business is, using a business domain model that identifies and defines the business concepts and the relationships between them. This can be developed ‘offline’ if there is consensus on the concepts, but often discussion among a broad group identifies divergent perspectives and understanding and allows the differences to be resolved before they become critical issues later in the project.

Once this context is established, and with an understanding of the organization’s overall goals, establishing agreement on what the process goals / objectives are is much easier. And the domain model provides the terms that can be used to describe the future state process.