Thanks Tony I hear you. Below is some of my motivating factors based on function and process. I would appreciate more input from your side if you don't mind. - Modeling existing data structures (as-is) as we have no existing data models, and we have to rely on our dev teams to consult and advise. Not much new data modeling. The aim here is to empower the BA team to understand the data structure while our data architecture team will take ownership. - Currently our processes are all over the place, scattered visio diagrams, lucky to find one, nevermind if it's the right version or not. So the aim is to map all existing processes as a start, then we can optimise. To me, detailed processes are the blueprint of a business, and again the aim is to empower the BA team to take ownership of the business unit that they service. - A central repository for all modeling, structured, with version control, and access controlled. (No more attempts to hunt down a visio diagram stored on one of the 1000s of network folders) - Template-based document generation from detailed models, i.e. a Functional Spec, Test Cases. (latest model ensures that the generated spec will have the latest FR & BR). Based on past experience, this reduces time spent on documenting. - The tracking of Functional Requirements & Business Rules is also a major factor. Funtional Requirements for System, and Business Rules for Product. Again empowering the BA to understand Product, and the mechanism that services that Product. Justin
Justin:
* For enterprise-wide data modeling, be as business centric as you can. ERD's are very business centric - plus they focus on interrelationships. A big problem with the UML is that all the models - data, fucntion, state - try to slant things towards implementation considerations. They are meant for BA's who are programmer wanta be's. If you try to, at the same time, think implementation AND design on an enterprise wide effort, you will fall into a confusing mess.
* Sounds like you have the very common situation of a bunch of lower level flow charts that do not tie together - and you can bet you bottom dollar are very disjointed. You need to take an integration approach, and to do this you need approach analysis from a higher level of abstraction (i.e., take a bigger picture approach). You can not approach larger scale process/fuinction analysis from the bottom up; you will drown in an ocean of detail if you try.
One of the toughest things about working at a higher level of abstraction, is that you have deal with the fact that at this level, systems are non-sequenctial. Therefore, you can not use a sequence based modeling techinque to model process/fucntion. (All the process/function UML techniques, except Use Cases, rely upon sequence - and Use Cases are useless as they do not model the essential interrelationships.) Only data flow diagrams will do.
* Requirements tracability is an exercise in proper system decomposition: To trace requirements from the higher level of abstraction to the detail level. Only data flow diagrams lead to a logical decomposition.
Tony
brought to you by enabling practitioners & organizations to achieve their goals using: