enterprise architecture

Versioned Governance

Versioned Governance

Versioned GovernanceREST resources and components are meant to be used in more than one application. Organizations should plan for the incremental enhancement of resources over a long deployment lifetime. Essentially, organizations planning to build a robust, stable, and extensible REST resource need to treat resources as “products.”

What does treating a resources as a “product” mean to our IT organization?

  1. Each produced resource must have a regular and well-defined release cycle. The release cycle should occur often enough to meet consumer needs on a timely basis. However, not so often as to churn existing consumers. Typically, an appropriate release cycle for most organizations is between three and six months, which allows organizations to meet new resource needs without unduly disrupting existing applications. When multiple versions of a resource are released, consider defining the life-cycle states for your resources:

Under Development: Available for requirements gathering and application development team planning purposes

–  Production: Mainline version for use in new development

–  Retired: Still in use by existing applications but not allowed for use by new apps

–  Obsolete: All applications should be migrated off this version; version metadata is maintained for traceability/audit purposes only

2. Resources must preserve backward compatibility when possible. Deprecation techniques (where obsolete operations are identified, and notice given to consumers operations will be removed from resource interfaces in future releases) gives existing consumers time to migrate to newer resource releases. Additionally, resource providers should offer n-1 version support at a minimum. All resources provided in a prior version (except ones marked as deprecated) should be preserved intact in the current version. Moreover, consider offering a “grace period” for both resource versions during deployment to allow consumers to make necessary changes while integrating to the new resource version. Dynamic run-time binding techniques via Web resources management infrastructure also simplify the migration process from an old-to-new resource version.

3. The enterprise architecture and resource review teams need to establish mechanisms for gathering requirements from current and potential “customers.” Consider establishing a “product manager” role within the organization, one that manages the aggregate set of business requirements for the resource, and works to prioritize requirements with its current, and potential customers.

Again, a well-designed discovery mechanism helps an organization manage the lifetime of resource versions with automated notifications, and embedded discussion forums for requirements gathering. Further, analysis through filter-based search capabilities, which expose resources to potential consumers based on a resources state, also result from a well-designed discovery mechanism.

Corporate Culture

Influencing REST Behavior and Relationships

To determine and shape organizational behavior that sustains REST efforts over time is often the work of change management specialists. However, conceptualizing the role of REST is easier if we examine the intersection of major influences, such as organizational and individual characteristics. Some influences include:

  • Corporate culture
  • Major decision-making processes
  • Budgeting processes
  • Incentives and penalty structures
  • Compensation linkages to corporate goals and mantras
  • Portfolio management processes
  • Architecture process (definition, acquisition, implementation)
  • Architecture practice (solutions development)
  • Corporate performance metrics⎯return on invested capital (ROIC), revenue and market share growth, cost controls
  • Promotion and advancement criteria

Key factors in the context of REST determine how effective process changes are within an organization. Understanding key process relationships helps a governance board design better REST resources.

For example, the relationship of the budgeting office to project execution helps align budget oversight with the project. Without proper budget-to-project alignment, teams might build project-centric resources. Unfortunately, project-centric resources do not fit the broader needs of an organization. Another example, the relationship between the procurement office and enterprise architecture. Does the acquisition process reflect the goals and standards of the Enterprise Architecture (EA) organization? If not, how can the acquisition process change to better reflect goals and standards?

Another critical relationship is between EA and project or solution architecture, which connects architecture through governance to downstream activities. If there is a disconnect between enterprise architecture and architecture designed at the project level, the result may produce disjointed architecture.

The internal relationships reflect how organizational culture and stakeholder influence converge to either facilitate or hinder REST implementations. There are no easy answers. However, the development of complementary and supportive relationships increase the possibility of successful REST initiatives.

REST Governance Separation of Concern

REST initiatives, in conjunction with other architectural approaches, force IT organizations to recognize teams producing resources are not likely to be the consumers of those resources. Unlike traditional application development, REST is built upon the premise that a set of resources can be used within a wide range of applications. REST depends on production and consumption separation.  The distribution vehicle must allow resource producers to communicate with resource consumers. Observing and consulting for many REST implementations, we have defined the production, distribution, and consumption concerns:

Production: Identification of and governance over the development and maintenance of existing and newly defined candidate reusable resources

Distribution: Publication of those resources for widespread dissemination to potential resources consumers

Consumption: Discovery of and governance over the appropriate use of resources within application development projects

Executing responsibilities within governance concerns through manually defined and managed procedures is technically feasible. However, essentials for IT organizations of any size to build a successful REST implementation include solving political and organizational issues. In addition, selecting appropriate tools such as a resource, repository/registry to automate governance and distribution resources also help build successful REST implementation.

Booker Showers