Daniel Selman added an interesting post to his blog discussing the “Meet in the middle” approach which is a combination of top-down and bottom up. You can see the original post here.
I commented on the posts on his site, but I will reproduce one of those comments here. Enjoy
Meeting in the middle challenges
The challenges I have seen with this kind of approach is that if you are working on a project that is using the Zachman Framework, chances are the people working on the modeling (conceptual and logical data modeling) are not the same as the people who are working on the rules and who need to help the Subject Matter Experts work with rules. The model that data modelers will propose will most probably be different than what a model created for the business (and business rules) needs to be and therein lies the challenge of trying to steer the modeling in the direction required for the rules.
What I have seen is that the data modelers want to use best practices of their world which is great, but the vocabulary that they will create will be inevitably different than what the SMEs are used to in that business. For example, they will use some data modeling patterns (party-role for example) but these are not terms that the business uses. So what is the relationship between the models? Is there a relationship?
The solution? I’m not sure.
Does a completely separate modeling effort need to take place? And then an effort to try and map one to the other (i.e. map the business object model to the logical data model using view or some other technique)? Both models will end up influencing the other in the end, so changes are inevitable, but is it better to use that approach?
Or should the team try to collaborate on creating a model that will work for both purposes? This requires that both modelers (assuming there is one for the data modeling world and one for the BOM) collaborate and educate each other on reasons why they should go one way or another. Will you end up with 2 separate models anyway in that case?
There may be other solutions to this and hopefully we will see other people’s input to this.
Tags: Best practice, BRMS, Business Rules
Eric:
MDA, MDD, Model Driven Development/Model Driven Architecture is a foundational approach to doing quality work. As a KE (Knowledge Engineer) it is often our primary function to FIRST set up a dictionary of the data, models, attributes, business terms, etc. and then, the hardest step, is to convince all of the participants that this is the corner stone of the rest of the project. If they cannot agree on this then the project is doomed.
And in answer to your question, yes, a separate modeling effort must be done up front. You can always modify it later.
Team collaboration is the cowards way to spread the blame when something goes wrong. Somebody has to be the final decision maker – and I don’t mean Bush nor Obama. Usually that someone will be you, the KE, the know-it-all AI guy who is trying to help them get something done that will reap the company lots of savings in the future.
SDG
jco