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.

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.

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.

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.

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.

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.

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.

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:

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.

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.

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.

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.

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.

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.

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.