From Business Ambiguity to Technical Precision
In many companies, the bottleneck has shifted from lack of understanding of the business process to the need to bridge the gap between business and technology. Until recently, many companies had not defined their business processes, and there was much to be gained from business process improvement projects. Of course, if you haven't defined your business process, there still is much to be gained.
Nowadays, I see more client companies where the business processes have been defined, and the current issue is how to get from that necessarily ambiguous model to the (also necessarily) unambiguous model required to build technology systems.
The other current issue, perhaps less understood but just as important, is how to continue to incorporate the ambiguity of business while making progress on project goals. That is, how to insert discontinuity into a goal-oriented process.
So how do we get from ambiguity to precision and back again? The following steps provide a guide:
1. | Embrace the ambiguity. You model the business on business terms—high-level, open-ended models that put all the relevant information on one page so it can be taken in at a glance. |
2. | Develop that vision. You take significant chunks of business function (also known as services, as in Web services) or information and you drill down to more detail, beginning to incorporate broad strokes about the technology that is required. |
3. | You'll end up with a high-level model that represents both the business vision and the technology vision. It provides more detail than the business sales pitch that usually defines the business view, and is more comprehensive than the implementation view. |
To move towards precision, you need to start breaking out the kinds of information that system designers will be looking for: data, functionality, events, and so on. You can do this type of analysis with swim lane process models or business process models such as the various flow diagrams that exist.
Depending on whether you're taking an object-oriented approach or not, you'll move into either use-cases, scenarios and object models, or you'll define entity-relationship diagrams, usage models and data flow diagrams. Either way, you begin to focus on the use of the system (the user model), and define components of data and/or functionality.
Going back again (from ambiguity to precision and back again) involves keeping the business (a moving target) in view by shifting back and forth from global thinking to local thinking.
At the global level, you work at clarifying the big picture, keeping it loose and flexible.
At the local level, you execute iteratively, testing out concepts before rolling them out across the board. You carve up projects into small chunks for delivery. The current chunk is inflexible, precise, and fixed. The flexibility comes from having many small chunks, and the ability to adjust each one as you go, keeping it open until delivery time, when it then becomes fixed.
By reintroducing the ability to adjust implementation options at the level of iterations, you reintroduce the ambiguity that was taken out in order to formalize your system design. The result is a development process that starts out fuzzy, gets clarified through analysis and design, and then begins to blur again when it comes to implementation. It's an approach that works by operating in the real world on both ends of the spectrum (business/technology), while thinking clearly when making critical design decisions.