Introduction to Organizations
An organization represents an entity that owns a collection of assets. Organizations enable you to partition a registry into autonomous collections of objects that can be administered independently. You define organizations that represent actual entities within your enterprise, such as functional lines of business, regional subsidiaries or branches, legal entities, B2B partners (for example, suppliers and customers), projects, or departments. You can define parent-child associations between organizations to model the hierarchical structure of entities in your enterprise.
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 permission. Organizations enable you to restrict the visibility of a collection of assets to a specified group of users.
Organizations also function as a scoping mechanism for the following registry functions:
Role-based permissions
Lifecycle models
Design and change-time policies
Run-time policies
Supporting documents
For example, organizations enable administrators to create lifecycle models, and design and change-time policies that apply only to the assets that belong to their organization.
Each organization that you add is stored in the CentraSite registry as an object of the type Organization.
The information that you store for an organization includes:
General information about the organization, such as the organization's name, the description of the organization, the contact person for the organization, and the address of the organization's web site.
The
CentraSite users who belong to the organization, as well as any group or role assignments.
Details of any child organizations of the organization.
Basic Organization Structure
An organization is composed of users, groups, roles, and permissions. The structure you select determines how the assets in your registry are organized. It also plays a key role in controlling who can access various assets of the registry. The users that belong to an organization are permitted to access all assets of the organization. If other users require access to the organization's assets, they must obtain explicit permissions to do so.
An organization can have zero or more child organizations. Each child organization is a separate organization in its own right and has its own set of users, groups, roles, and permissions.
An organization can have one or more users. A user can belong to only one organization.
An organization has one or more groups. A group represents a set of users. Groups enable you to collectively apply permissions and other capabilities to a set of users. All organizations include the following predefined groups:
Group | Description |
Users | All users belonging to the organization. The API requires all organizations to have this group. |
Members | All users belonging to the organization or any of its descendants (that is, children, children's children, and so forth). |
An organization has one or more roles that can be assigned to users or groups. By default, each organization includes the following set of roles: Organization Administrator, Policy Administrator, Asset Administrator, Asset Provider, and Asset Consumer. A role is a collection of system-level permissions and organization-level permissions. These permissions enable users to work with specific types of objects or perform certain tasks.
Instance-level permissions are used to give specific users or groups access to individual assets or registry objects. They enable you to apply fine-grain access controls to the assets in your organization.
Default Organization
CentraSite is installed with one pre-defined organization called Default Organization. The Default Organization owns the system-defined registry objects that CentraSite uses. You cannot delete the Default Organization or rename it.
As a best practice, avoid using the Default Organization as an ordinary organization. Instead, treat it as the home for system-wide objects such as asset types, taxonomies, gateways and system-wide policies, and restrict membership in this organization to a small number of administrative users.
To create and manage a top-level organization (that is, an organization that is a sibling of the Default Organization), you must belong to a role that has the Manage Organizations system-level permission. By default, users with the CentraSite Administrator role have this permission, and can assign this permission to other roles. The Manage Organizations permission enables you to manage all organizations (including the Default Organization). This permission allows you to create, view, edit, and delete any object within any organization.
Child Organization
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. The administrator of a parent organization also has administrative control over the organization's descendants, and can manage users, assets, policies, and lifecycles 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 does not inherit any characteristics from its parent. It has its own administrator, set of users, policies, lifecycle models, and assets. The administrator of the parent organization also has administrative privileges in the child organization. A child organization can have additional child organizations of its own.
To create child organizations from an organization, you must belong to a role that has either the Manage Organizations permission for the organization in which you want to create the child organization or that permission for one of that organization's antecedents.
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 and organization administrators in the parent organization are automatically allowed to administer the child organization. The parent's organization specific policies and lifecycles do not 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.
Consumer Organization
CentraSite gives every user in an organization the ability to act both as an Asset Consumer, where the user can view assets in the registry and an Asset Provider, where 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, which is the group comprising all users in the organization.
If you have groups of users who consume only assets, consider creating a separate organization for 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 give the consumer organization's Users group, permission to view the assets.
Organization Administrators and Primary Contacts
When you create an organization, you must specify a user to serve as the Organization Administrator and a user to serve as the Primary Contact.
The
Organization Administrator is a user that has the Organization Administrator role for the organization. An organization must have at least one user in this role. A user in one organization can serve as an Organization Administrator for another organization; however, this role is generally given to someone within the organization. An organization administrator performs administrative tasks for the organization, such as:
Adding users to the organization
Defining groups and roles
Defining custom lifecycle models for the organization
Creating child organizations
An organization administrator can also view, edit, and delete any asset, policy or lifecycle model that belongs to the organization or any of its descendants.
The
Primary Contact is a user who acts as the point-of-contact for an organization. An organization has just one primary contact. The user who is designated as the primary contact does not receive any additional roles or permissions. The same user can serve as the organization's administrator and its primary contact. You can assign a different user to each position. The primary contact is not required to be a user within the organization, but usually is in most of the cases.
Modeling your Organizations
Instead of organizing the content 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 (for example, subsidiaries and affiliates) or regional divisions. Think in terms of who owns the assets that resides 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 on.
The figure 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 (that is, 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 serves as the home for administrative and system-wide artifacts. |
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 can 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 depends on your requirements.
Selecting an Organizational Strategy
Apart from selecting a deployment strategy, defining your organizational structure is one of the most critical deployment decisions. It is important to select a structure that is stable and endures over time. After establishing your registry's structure and 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 may 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. For example, 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 creates assets for multiple organizations, add the user to the organization in which he or she works primarily. Then assign roles to the user that enable the user 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 requires a significant amount of work. Moreover, a fine-grained structure is generally not needed in order to govern your assets effectively.
