Enterprise Business Modeling
Recent history is littered with failed enterprise business modeling projects, whether they be data-modeling, process-modeling, or both. A common factor in these failures was the big-bang attempt to model the whole enterprise in one project. The just-in-time philosophy embodied in iterative development and agile approaches, including RUP, encourages us to only model what we need to when we need to. This philosophy works well for individual, isolated projects and software systems. What is not obvious, nor well explored in RUP or other Business Modeling references is how to model small portions of the business as required, but over time build up one enterprise model.
Our Business Requirements Modeling page discusses the use-case model for the entire business (which shows the interation between the business and it's external stakeholders), and individual use-case models for individual business functions. In order to build a consistent enterprise business model over time, the identification of business functions requires a systematic approach. For an enterprise model to remain valid over time, it is essential that the functions are not based on organisational structure. So how do we determine them? I use simple means-end analysis to derive a functional decomposition of the organisation. This does not take long, and provides a framework to guide the scope of the business use case models developed on subsequent projects. People find some problems with this type of functional decomposition. They may find many different business processes in different parts of the organisation end up in the one function in the decomposition. This could identify opportunities for consolidation, or there could be legitimate differing ways of performing the function for different stakeholders with differing objectives. More interesting are those business processes that don't turn up in the means-end analysis at all <raised eyebrows>. In enterprises that comprise highly independent business units, you may chose to treat a single business unit as the enterprise.
Having your business requirements (use case) models under control, we can move on to the business process models. These contain realisations of the use cases from the business requirements models as discussed in our Business Process Modeling page. IDEF0 and UML Activity digrams are of little long-term value in an enterprise model. We suggest that they be used to foster stakeholder understanding and buy-in, and be preserved in process descriptions and work instructions intended for the business stakeholder audience. They need not be preserved in the enterprise model. Collaborations are the key here. They show how the actors, business workers, and business entities collaborate to realise the business use cases and other business processes. The aggregate collection of the business workers and business entities from all the use case realisations forms the enterprise business object model. You need to ensure that every real-world business worker or entity appears only once in the business object model, and that all collaborations reference that one copy. This approach is quite nice in that the a complete set of responsibilities and attributes for each worker and entity is built up from the contributions of each collaboration. This can then drive the requirements for automated workers (software and other systems), and the position descriptions for human workers. Actors in collaborations are treated differently. A worker or entity in one collaboration may appear as an actor in a second collaboration. The second collaboration should reference the actor from the use case model where it originates. There is no real need to maintain any relationship between actors and the worker or entity that they represent, as the actor is only valid in the context of the individual use case model.
