One area that I've seen consistently as a problem over the years though is down to how the package vendors have thought about physical and electronic addresses. When the packages were created there were really only one set of important addresses, physical addresses. Phone numbers were pretty much fixed to those premises and email was a million miles away from the mind. This means that the data models tend to look at electronic addresses as very much second class citizens, normally as some form of child table rather than as a core entity.
The trouble is that as packages are being updated I'm seeing this same mistake being made again with some of the new technology models being used by vendors (AIA from Oracle appears to make the mistake). The reality is that the model is pretty simple
That really is it. There are two key points here
- Treat all actors as a single root type (Party) then hang other types off that one
- Do the same for Locations
The reason for doing this is pretty obvious. These days mobile phone numbers and email addresses are much better communication tools than physical addresses. As you want to send e-statements, e-invoices, and other elements to customers like SMS delivery notices, then you want to be able to channel shift customers much more simply. If a customer switches their delivery address for a book to an email then that is fine as long as you can ship them an e-book.
Now I know that anyone from an OO background is going to go "well duh!" but it does amaze me how in package land the database centric mindset still dominates and people just don't seem to want to revisit the assumptions they made in the 1990s when their hacks to put in electronic addresses seemed like a safe bet, after all email and the internet weren't considered as future strategies.
Its now well into the 21st century and I'd really advise people buying packages to look long and hard at the data model and ask yourself "is this a 1990s view of business or a 21st Century view" if its the former then be aware that you will have pain.
Technorati Tags: SOA, Service Architecture
No comments:
Post a Comment