Once thing that often confuses Dimensions CM administrators and users is how to set up and use an effective Design Part Structure (DPS). There is no ‘once size fits all’ answer but I hope the following comments will help guide people to a more comfortable structure. The major reason for confusion is probably because users are unable to relate the DPS to anything else they are familiar with – it is purely a logical construction and is purely Dimensions specific.
  1. The DPS is most analogous to a product break down structure from project planning discipline
  2. The first question that is usually asked is ‘should I put everything into a single product, or split it up across multiple products’. The answer is generally to put everything in a single product as this gives the maximum flexibility with organisation and baselines. Exceptions include:
    1. Things really are separate products that will never meet. e.g. an AS/400 order entry system and a C# IT Support Desk application.
    2. You want to limit who can browse the contents of certain items (for real security consider a separate base database)
  3. The DPS will evolve over time as your product and organisation evolve, so be prepared to lavish some care and feeding on it. Activities include:
    1. Creating new design parts (DP)
    2. Suspending defunct DPs (e.g. IBM System 36 development is probably pretty quiet by now)
    3. Moving items between design parts (e.g. refactoring code into common libraries)
    4. Creating usage relationships between DP and between DP and items
    5. Renaming design parts, which should be very rare
    Note that although this is an ongoing process it generally should not be to be done frequently. If you are makeing changes weekly then your environment is probably too unstable and you should go and find out why.
  4. DPs are used for four major things (There are others, but I’m sure most people never use them)
    1. Allocating areas of responsibility to teams – this is the big one
    2. Identifying subsystems and dependent subsystems for baselines
    3. Identifying useful information by
      1. Allocating change documents to affected DPs
      2. Creating reports based around design parts or viewing information using the DPS breakdown
  5. Permission to make changes to items is granted to people who have the correct role on the ‘OWNING’ DP. If an item has a usage relationship this confers no special abilities to users. Dimensions 10 added the concept of granting permissions via groups which is not considered here.
  6. Sometimes it is useful to create one or more CONFIGURATION PARTs (CP). A CP is a design part that
    1. Does not own any items (but may have child DPs that are also CPs)
    2. Does have a USAGE relationship with one or more items (the relationships can be indirect via child DPs)
    3. CP are useful for baselining when the baseline model does not reflect the way the teams are organised. Remember a team's responsibility is reflect by the OWNS relationship between items and DPs.
So from this we can come up with some rules of thumb
  1. The most important structure is how the teams are organised. e.g. Is each team self contained and responsible for one or more subsystems? Are teams function based, i.e. DBAs, Business Programmers, UI developers…. This will be your primary DPS
  2. How are changes managed? Does there need to be a set of business names overlayed on the top? (consider how changes will be raised and managed by the stakeholders)
  3. How is the product released (and baselined). Can we identify a set of cohesive subsystems that can be released independently?
  4. Do we need to create additional substructures to manage third party products? (commercial libraries, open source code etc)
  5. Is the DPS ‘balanced’? Are all the subsystems listed at the same level? Can I place all (or most of) the team leaders at the same level (see below), and so on
  6. Keep it as simple as possible, but no simpler.
Allocating Roles to Design Parts It’s very common to see roles over allocated as people struggle to fix the ‘permission’ issues that come up day to day. The answer is to a have a simple and consistent scheme to make such problems as obvious as possible.
  1. Try and allocate roles at the same level each time. e.g.
    1. Project manager, CCB Chair and Chief architect are allocated once at the product level and are responsible for ALL design parts
    2. Business area owners and stakeholders are allocated at a business level (next level down from product part possibly)
    3. Team leaders, programmers and testers are allocated at next level down , (say)
  2. If you really need to override a role allocation at a lower design part
    1. See if you can use a different role name (usually very difficult)
    2. Do it across all the design parts at that level in the sub tree even if it has no affect – the idea is to be consistent
  3. Avoid using the same role names in the lifecycles for Change documents, items and baselines. For instance, if a item lifecycle has a role of ‘programmer’ then make the corresponding role on the change document ‘implementer’. This has two benefits
    1. It’s less confusing for non programming users (e.g. technical authors) to use the same change document type to manage their changes
    2. It can save a LOT of confusion around role allocation, especially if ‘programmer’ in the above example is allocated the first role on the item lifecycle.