One oversimplification in my writeup was that by saying "process first", the implication is that data can't be considered until the process is finished, which isn't the case.? Process and requisite data definition is incremental and, in our method, iterative - but data definitions stay flexible throughout process definition and development.? However, "process first" was being stated in the context of opposition to the idea that you sort out all your data first, and then figure out what processes you can support.
Another consequence of my oversimplification was that respondents pointed out that some other things come first:
What comes first is not the process nor the data but goals and outcomes. They decide what content is needed. The content drives the data and the process is what happened until you reached your goal.
First, the business strategy to set goals.
Second, processes, or sequences of activities aimed at achieving the objectives.
Third, identify the inputs and outputs of activities over the E2E processes as macro entities (e.g., supplier data, client data, order data, delivery data, etc.).
Fourth, compile the macro entities and define data models required by processes to run at the most elementary level.
Fifth, choose the best technologies that can process data across processes, always on the basis of a cost/benefit analysis.
Both Max Pucher and Jose Camacho make good points - however, for me, seeing the world through my BPM lens, defining strategy, goals and outcomes is part of defining process.
Bogdan Nafornita captured the spirit well:
Well, I also agree that the business goals come first, but responding like this is actually cheating :-) This is reframing the question asked in order to outsmart other responses.
If the question is "chicken or egg", if you want to outsmart the two possible answers, you just answer something like "macromolecules" or "metabolism" as prerequisites to either the chicken or the egg.
I asked a few rhetorical questions:
Chicken and Egg question: If data comes first, how did it get there?
The question isn't "whether" to have good data models or not... the question is "when". Before you know the story / narrative or after?
Process is the story or narrative.? Surely you want to understand that before you lock in your data definitions?? Or the story might cause you to change and add or subtract from your data models?
If data are inputs, outputs, and side-effects of the process, then your process definition and context will drive your data requirements for the process. Try driving it the other way around - You end up with a data maintenance app - which might have been what you really wanted, rather than a process.
So perhaps it would have been more artful for me to say Process and Data, but Process in the driver's seat.? Either way, I came away with some great additional perspectives from contributors to the BPM.com forums.