--- In [email protected], "Steve Jones" <[EMAIL PROTECTED]> wrote: > > A much bigger reason (IME) is that different parts of the > organisation have different views on things.
Yes. This speaks to the notion I mentioned of breaking down the uber object into smaller units for for specific processes. But this too has challenges. > So what is important in Sales around customer is difference to what > is important in Accounts, having an "uber" Customer record that has > everything in it creates a classic fragile base class problem and is > also very prone to changes being required. Right you are. I'm not a big fan of the uber definition approach. I think an approach of "think strategically, at least just a little bit beyond your project, act tactically" can be effective in many situations. Building flexibility into the definitions so that it can more readily account for changes and differences is also helpful (for example, the notion of "extrinsics" or a "put stuff we didn't anticipate here" capability). > Industry standard definitions work well when doing external > integration around a common area, but imagine an airline adopting the > OTA standards in their accounts department. Indeed. -Rob
