After selecting your deployment strategy, you must define the organizational structure of your registry. The structure you choose determines how the assets in your registry are organized. It also plays a key role in controlling who can access various portions of the registry.
In CentraSite, an organization is a high-level container for the assets and other objects that make up a CentraSite registry. Any object that is not an organization must belong to an organization. You use organizations to partition your registry into autonomous collections of assets that you can administer independently. Typically, you use organizations to arrange your registry around functional lines of business, regional subsidiaries, branches, legal entities, departments, B2B partners (e.g., suppliers and customers) or similar criteria.
By default, only users within an organization have permission to view the organization's assets. If other users require access to the organization's assets, they must obtain explicit permissions to do so. Thus, on a broad level, organizations enable you to restrict the visibility of a collection of assets to a specified group of users.
Organizations also act as a scoping mechanism for the following registry functions:
Role-based permissions
Lifecycle models
Design/change-time policies
Run-time policies
Supporting documents
For example, organization administrators can create lifecycle models and design/change-time policies that apply only to the assets that belong to their organization.
An organization also represents a specific group of users within the registry. This quality allows you to apply many permissions and capabilities collectively to all users in an organization.
CentraSite is installed with one predefined organization called Default Organization. The default organization owns the system-defined registry objects that CentraSite uses. You cannot delete the default organization nor can you rename it.
As a best practice, you should avoid using the default organization as an ordinary organization. Instead, treat it as the "home" for system-wide objects such as asset types, taxonomies, targets and system-wide policies, and restrict membership in this organization to a small number of administrative users.
You can use parent-child associations to represent hierarchical relationships among organizations. Parent-child relationships enable you to collectively administer certain aspects of the associated organizations. For example, after you establish a parent-child relationship between organizations, administrators can collectively grant roles and permission to users that belong to a parent organization or any of its children. Moreover, the administrator of a parent organization also has administrative control over the organization's descendants (meaning he or she can manage users, assets, policies, lifecycles and so forth within the parent organization and all of its descendants).
To create a parent-child relationship, you must create the child organization from within the parent organization. A child organization functions just like an ordinary organization. It does not inherit any characteristics from its parent. It has its own administrator (although the administrator of the parent organization also has administrative privileges in the child organization) and it has its own set of users, policies, lifecycle models and assets. A child organization can have additional child organizations of its own.
As you define the organizational structure for your registry, identify organizations that you want to relate in a hierarchical form and use parent-child relationships to reflect the hierarchy.
When defining your organizational structure, keep the following points in mind with respect to parent-child relationships:
A child organization can belong to only one parent.
You must create the parent organization first and then create the child from the parent. In other words, you cannot create two unrelated organizations and then, at a later time, establish a parent-child relationship between them.
Once you associate organizations in a parent-child relationship, you cannot disassociate the organizations.
You cannot move a child organization to a different parent.
You cannot promote a child organization to become top-level parent organization.
A child does not inherit properties or objects from its parent (other than the fact that organization administrators in the parent organization are automatically allowed to administer the child organization). Nor do the parent's organization-specific policies and lifecycles apply to its children. A child organization creates and maintains its own policies and lifecycles independent of its parent. In this respect, it is like any other organization. (To impose policies and lifecycles on all organizations in the registry, you can create system-wide policies and lifecycles as described later in this guide.)
By default, CentraSite gives every user in an organization the ability to act both as an asset consumer (meaning the user can view assets in the registry) and an asset provider (meaning the user can publish assets into the registry). CentraSite does this by assigning both the Asset Provider role and the Asset Consumer role to the organization's Users group (the group comprising all users in the organization).
If you have groups of users that will only consume assets (a group of external partners, perhaps), consider creating a separate organization for just those users. Remove the Asset Provider role from the organization's Users group so that the users in the organization have just the Asset Consumer role. Any organization that wants to extend assets to these consumers can do so by giving the consumer organization's Users group permission to view the assets.
Although you might be tempted to create an organizational structure that precisely mimics the organization chart within your enterprise, this is not usually a practical strategy. Many low-level organizational units within your enterprise have no relationship to your SOA environment and, therefore, do not need to be represented in the registry. Furthermore, the low-level work groups within an enterprise tend to be very dynamic, which makes them unsuitable entities on which to base your registry's organizational structure.
Instead of organizing the contents of your registry around the low-level departments on an organization chart, group it by higher-level concepts such as functional units, lines of business, process owners, legal entities (e.g., subsidiaries and affiliates) or regional divisions. Think in terms of who owns the assets that will reside in the registry or has primary responsibility for developing and maintaining them. Create organizations to represent those areas.
If you intend to give external partners access to CentraSite, create separate organizations for each partner. (By partners we mean any external entities with which your enterprise interacts, such as suppliers and other vendors, dealers and distributors, customers, government agencies, trade organizations and so forth.)
The following shows the organizational structure that is defined in the starter kit example. This example has a level of granularity that is appropriate for defining organizations.
Example Organization Structure
| Organization | Description |
|---|---|
| Default Organization | This organization serves as the home for administrative and system-wide artifacts. |
| Shared IT Services | This organization represents Information Technology (IT) departments that operate across (i.e., are shared by) other lines of business. This organization would include the Quality Assurance (QA) department, the SOA Competency Center and individuals who serve as enterprise-wide IT architects. |
| Customer Care | This organization is responsible for systems and services related to customer management (from CRM to claims processing). |
| E-Commerce | This organization represents the department responsible for providing external-facing services including customer-facing portal sites and business-to-business services. |
| Trading Partners | This organization is the parent organization for all external partner organizations. It is a "pseudo" organization that is used to hold organizations that represent external parties. |
| Acme Inc. | This organization represents an external partner that provides or consumes assets. This organization is a child of the Trading Partners organization. |
| Flowers.com | This organization represents an external partner that provides or consumes assets. This organization is a child of the Trading Partners organization |
If you are using a multi-stage deployment, you might replicate the same organizational structure across all registries. Or you might adopt a different structure in each registry. For example, on the creation CentraSite you might use the organizational structure like the one described above. However, on the consumption CentraSite, you might define just two organizations: an “operations organization”, which owns and manages all of the assets in the registry, and a “consumer organization”, which contains users who can browse the consumption registry. The organizational structure that you adopt for other stages will depend on your particular requirements.
Aside from choosing a deployment strategy, defining your organizational structure is one of the most critical deployment decisions you will make. It is important to choose a structure that is stable and will endure over time. After you establish your registry's structure and put your governance processes in place, it is difficult to make fundamental changes to the way in which the registry is organized. Such a change would not only require you to transfer assets to different organizations, but might also require you to redefine the lifecycle models, policies and permissions that support your governance environment.
When planning your organizational strategy, take the following points into consideration:
In general, create organizations around the concept of asset visibility, ownership or responsibility. In the pre-production stages, use organizations to represent the major stakeholders involved in the pre-production aspects of the asset's development lifecycle (e.g., service owners, developers and the SOA Competency Center). In the production stage, use organizations to represent the groups of users who represent assets owners, consumers of assets and the operators of the production services.
If a particular group of users requires the use of custom lifecycle models or design-time policies, create a separate organization for those users.
If you have groups of users whose needs are "consumer only", create separate consumer organizations for those users.
Keep in mind that a user can belong to only one organization within a CentraSite registry. If you have a user who will create assets for multiple organizations, add the user to the organization in which he or she will work primarily. Then use roles to give the user the ability to create assets in other organizations.
Keep in mind that an asset also belongs to only one organization. To make an asset accessible to multiple organizations, you must give the users in those organizations permission to access the asset.
Avoid creating an organizational structure that is too fine-grained. Keeping the structure of the registry synchronized with your low-level development teams and work-units will require a significant amount of work. Moreover, a fine-grained structure is generally not needed in order to govern your assets effectively.
