Enterprise PLanning Objects Naming Convention.
As I’ve promised, here are naming conventions I tend to follow in EP projects.
Setting up naming rules doesn’t seem so crucial at project start, but generally hits on you on the head on final phase, when development turns to support. And trying to support your colleagues model will leave you thinking about naming objects the same way more than once ;) So naming conventions are one of main project documents for me now.
I really expect and encourage comments on this naming proposal. Maybe together we will create something like Sun Java Code Conventions )
| Object | Naming rule | Example |
|---|---|---|
| Analyst | ||
| Library | Library names are not that important, though if you use Analyst with Contributor, consider creating stub libraries for importing data to\from Contributor, as I’ve described here. No data in skeleton library is a motto that will help you more than once, I assure you. Library codes are important if you want to keep a single store of projects (in consulting company, or competency center) and you’d better create some seeding rules for creating unique 9 numbers for projects. A simple scheme of xxxxyylll, where xs are project code, ys – library type and ls – library order number will be sufficient in most of cases. | Sales_Planning_skl with code 777701001 |
| Dlist | The main difference with Cognos initial coding standard. Dlists are numbered not up by their functions, but by type calculations happening in this dlist. I’ve got initial table from Erik Thomsen’s OLAP book and modified it to suit EP better. So it goes like this: 1 - IF-ELSE formulas 2 - *,^, / * 3 - Common Sums * 4 - Timescale Sums * 5 - No calculations. Second difference: these numbers are used as suffixes of dlists names, not as prefixes. This allows quick search by first letter of dlist name when you’re browsing the library and all product dlists will be kept together, regardless of type. Third rule: only latin names with spaces substituted by _ (underscore). This guarantees that published tables will be named meaningfully and their names won’t mutate after time (a real problem with cyrillic dlist\dcube names). |
Balance_Sheet_1 Products_3 Months_4 |
| Dlist item names | One really useful hint: mark all calculation temporary elements (not to be seen user) with leading # symbol. This allows creating simple saved selection with filter that will easily hide all unnecessary elements from users in Contributor | #temporary_allocation_element |
| DCubes | Once again, only latin names with underscores to keep publish tables names sane. Contributor translations allow you to rename these cubes for end users with whatever names they’d like. No i\o\c, we’re out of kindergarten | Product_Sales_Global |
| Dlinks | “<” instead of “:” in separating source from target. And some hints like + when you’ve got an add link, - for subtract, to allow better understanding of link logic while viewing it in update list table. | BalanceSheet<Cashflow(+) |
| Macros | ||
| Allocation Tables | Similar to links, just the allocated dimensions with some commentary | ProductGroups<Products |
| File Maps | Whatever you like, I prefer filename | pl_export.csv |
| Contributor | Latin verbs or sentences describing what you’re doing with macro. Latin for running from command line. | Update_Products_Export_Elists |
| Applications | Rather strict rules are implied by Contributor itself, so i’d just advise to name aplications meaningfully, given that these names will always appear in browser connection string. No doubt that seeing “sales_plan_v8_will_it_ever_work” will inspire confidence. | sales_plan_by_brands |
| Access Tables | Access Tables should always be named. It’s best to write a short sentence, describing access table meaning | Closing product list based on managers responsibility |
| Saved selections | Plain common sense: explain what this selection selects ) | Accounts_special_calc_items |
| Administration links | Need suggestions here. Since Administration link is a pack of links, I use macro notation — verbs describing the process, but I put target application first | sales_plan_by_brands update from regions |
| Macros | Need suggestions here too. Again some action descriptions, but I don’t have a common approach of separating macros by applications they’re working with or smth like that. Moreover macros aren’t grouped anyhow, so I sometimes tend to prefix macros with some block group with following description | Sales_submission sales by brands to sales by regions |
| System Links | These are for users, so names should be descriptive actions | Load new currency rates |
Whoa, it’s a really huge document, maybe I’ll it finish someday…