I'm starting a project I call "Things of the Enterprise" (TOTE) or just Enterprise, that is intended to develop a reference set of common items and relationships. A good example of a common item is a "Person". For the most part the Person Entity contains the same fields in every application within an enterprise. This can be extended to say that for the most part the Person Entity is much the same across applications worldwide. Even though a Person entity structure is fairly constant in most cases, all to often every project designs the person from scratch. This eats up much time unnecessarily.
The Enterprise project is intended to create a standard set of commonly used items like, person and organization, and share them with anyone that can use them through public methods (like GitHub).
A project like Enterprise requires tools, not text, to be successful. PowerDesigner is the perfect tool for this project. With the ability to work across technology domains, like Object<->Data, and multiple targets (Oracle, SQL Server, Java, C#...) PowerDesigner makes it fairly easy to develop entities not only conceptually, but also as concrete items. It also gives us implicit OR mapping. If we generate a PDM from an OOM by default all of our strings become varchar(254). If we use domains and have the same domain in both our PDM and OOM environments our generation is much better controlled and more consistent.
A core requirement for this type of effort is standards that are flexible enough to be both conceptual and abstract, cross technology domain, and internationalized. PowerDesigner gives us the construct we need - the Domain. The Domain is generic enough on the surface to fit almost anywhere, but flexible to contain detailed implementation details. There is a base set of Domains that are used in almost all business applications. Things like phone numbers, mail locations, and people are examples. If we define a domain called Phone or sub classed domains like Phone.US, Phone.International, we can then use that title in many way. We can use it as an abstraction - just the idea of a Telephony Location. Or make it very concrete for different locations across the world, different technology domains (Object, Data), or different target platforms (Oracle, SQL Server). The great thing is that we only need to say "Phone" in our PowerDesigner typing, with the domain implementation taking care of the rest for us.
PowerDesigner give us great flexibility in making these abstracts concrete. And "protect" us from over or unnecessary analysis. Have you ever seen long discussion about whether a field for a simple list should be 12 or 14 chars long? It rarely matters from a technology perspective or business perspective. Storage allocations in databases generally fall on byte/word boundary lengths - 12 and 14 use the same space. And from a business perspective the sizes don't often matter either. How often have you seem a true business rule that says list items can't be more than 12 char long? We can create a generic domain for this "Type Of" idea. I use "Pick" for this, and a length of varchar(20). (I picked this because on a web form that fits about right in a dropdown). When I see an element in the "Pick" domain I know that I am describing a small string that (most likely) represents a list of values, and possibly an enumeration. Much richer and more clear then just seeing varchar(14).
With these basic Domain constructs we can then build more complex objects. Things like Person, Organization, and Location. But things don't stop there. Not only do we have standard fields (backed by domains), and standard entities (composed of standard fields/domains), but we can also define standard relationships. In most cases our Person has some type of relationship with at least one Location. We can establish that relationship in our models. Eventually we can build a comprehensive model of the universe. OK, just a small piece of the universe, but you get the picture. The standard model is a base that can be extended with business specific entities or tailored down. In my case I deal with Providers. I have extended my Organization entity to include the specifics of a Provider with little effort. Now our systems development teams can just pull from common entities and relationships when designing systems, saving significant amounts of time, providing consistency, and even assisting with systems interoperability. Have you ever seen Zip implemented as chars in one system, varchars in another, and as int (hey, it looks like a number doesn't it?) in another with the same organization. Have you every tried to get the systems to talk? Conversion = time + complexity + point-of-failure. With a standard model the Zip issue doesn't (shouldn't) occur. Our designer would normally just grab the Location entity and use that, tailoring as appropriate. If Zip was needed by itself, no problem, Zip is a domain that can be used as-is.
I think you can see the advantages of a standard model. As PowerDesigner users we know that PowerDesigner makes doing something like this possible. If you would like to join in this project please let me know. Even if you would just like to use the model let me know and I'll let you know as things get published. The GitHub site is https://github.com/Tessalator/Enterprise. There is nothing there yet and I hope to have the first pieces out there soon. In the meantime, I've attached a sample of some of my base domains, spec'ed for SQL Server.
BTW - I hope this is readable. I'm not much of a writer (or proof reader, or speller, and you should see my hand writing...), but I a pretty good modeler. I just whipped this out at lunch while I was motivated.
