Process First, then Data
Every once in a while you read something that reveals that someone else in your market space just has a very different view of how it works. I like to keep up with what other BPM software and services vendors publish in their blogs, and the other day ran across this post on Appian’s blog (they’re emphasis, not mine):
Here is a recap of the topics discussed during the final conference discussion, as well as some of the responses from panel members:
Start with data first, then build process models:
“Within short cycles of development you must start with the data,” said Deshpande. “From there, you can build, but you must start with the data.”
“Without the data in place, what are the processes you can put into place? The key is to first start with the data and analyze, then working your way back to what you want to build,” said Richard.
It is rare that I see something published in BPM circles that I am completely in 100% disagreement with. This is one of of those times. This is just wrong, and reflects old-school waterfall thinking. I’ve seen so many BPM projects either fail or get mired down because the BPM practitioners thought they needed to define all the data before they build any processes. So what do you think happens when you start data-first?
- You have, what we call in Lean, overproduction. You definite and establish lots of data that isn’t needed.
- You miss data elements that you do need – because you’re not starting from the requirements of the process… when you start defining the process you’ll find that it requires data that isn’t in your definition.
- Schema is more rigid than process definition. You build schema, and services against that schema, and queries … and pretty soon you can’t change the schema without breaking the things that depend on it. This isn’t about how hard is it to change a database definition, it is about the change to the definition’s downstream effects on everything else build on top.
- A data-first approach completely ignores process and how people interact with it. If you’re building a data maintenance application of course, that’s not a problem. But if you’re building a process, it is. Because the process, and how people interact with it will shape the way you want to interact with and store the data that supports the process.
You don’t start with the data. You start with the people and the process. And you use the business and technical requirements you discover along the way to define your data. If the data isn’t ready at hand, you find out where you can enter it, or from where you can retrieve it, and you tackle it accordingly. But you can’t let data define your limitations and your scope.
Those who’ve worked with Lombardi in the mid-2000’s or BP3 since 2007 will recognize the echos of our approach in this post. There’s a reason our approach is more productive. The bold-face tagline should have read:
Start with business process first, then build data definitions/integrations.
Seems like such a small distinction, but it will make a huge difference in your business process outcomes.