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

Resource Usage and Traceability

Resource Usage and Traceability

Resource Usage and TraceabilityAnother part of REST Governance is consumption. Consumption comes into play when building, deploying, and maintaining resources based on existing REST resources. Consumption resource tracking is essential for multiple reasons:

  • support internally defined and externally imposed business governance mandates
  • simplify the process of ongoing impact analysis and change management as resources mature
  • provide a quantitative ROI based on real usage statistics back to the enterprise

Governance Mandates

Let’s take a quick look at governance mandates. Business level governance affects IT departments. Consequently, governance mandates increase audits and traceability requirements applied to an IT department. However, expanded requirements cannot be met without some form of usage registration.

Remember, resources change over time as new requirements are identified. Development teams need to stay fully abreast about planned and implemented changes to resources they use. Further, teams need to participate in requirements feedback, and prepare for the eventual obsolescence of back-level resources as new versions are deployed.

Ultimately, enterprises are not in business to serve IT. An organization’s management expect a quantifiable ROI from any REST initiative. Without service usage direct traceability a quantifiable ROI based on service use and reuse is almost impossible to produce. Further, if usage registration is built-in resource discovery is quantifiable. Instead of guessing, ROI is as simple as running a periodic report.

Check Point

Recommended Service SDLC Governance Checkpoints

Check PointAfter defining our first set of services we need to build and deliver. Developing services in REST (i.e., for purposes of reuse across multiple applications) usually requires more of the production team than a single-use component, module, or object. For example, a reusable service is maintainable, discoverable, and consumable.

Maintainability introduces such concepts as version control, models, and other design documentation. In addition, maintainability involves requirements traceability (why was the asset implemented in a certain way from a technical and business perspective).

Discoverability forces us to consider how we help potential consumers of the asset find the asset.

Consumability involves looking at the asset from a downstream project planning point of view to determine how to use the asset. For instance, is there a user guide, a well-documented API, sample code, and other artifacts available to help a user rapidly understand how to apply the asset? Further, are dependencies on other assets (and to prior versions of the asset) specified and easily navigated?

We achieve high standards for our services under development by establishing standardized governance/review checkpoints throughout the service SDLC. Taliferro IT Consulting recommends at a minimum, organizations should review services under development upon reaching the following points in the SDLC:

  • Requirements Complete: All business requirements documented and initial service definition specified (ideally as WADL) to allow reviewers to validate the service against its business architectural context
  • Design Complete: Implementation approach defined with sufficient documentation (e.g., design models, relevant legacy APIs identified) to allow reviewers to validate design against technical, application and/or integration architectural contexts
  • Implementation Complete: Service implemented and deployed in a test environment with sufficient supporting documentation (e.g., sample code, test cases and results, usage guide) to enable a potential consumer to understand the service and to trust its quality and stability

Other review points are necessary based on organizational needs and objectives. However, refrain from overwhelming your development teams with process for the sake of process. Otherwise, you will quickly instill a revolt of the masses by forcing seemingly arbitrary hoops for developers to jump through in the process of completing their work.

Management’s objective should be to instill “just enough process” – not an unnecessary workload. Provide enough guidance at key points in the production and consumption life cycles to make sure things stay on track. Using the approach described, you will very likely reach the right level of process for your organization.

Begin with as lightweight a process as you think will work, and then add process steps as needed. Ultimately, a well-designed services registry/repository can assist in automating governance processes. The result is a reduction in “organizational friction” that often hinders all involved from “doing the right thing.”