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.

What Happened to Good Ol' Competition - Is Innovation Dead?

What Happened to Good Ol’ Competition – Is Innovation Dead?


Back in the day, not too long ago, there were many companies competing in a specific marketplace for customers, not consumers. The customer was always right. Companies valued customers. Competition made services and products attractive to customers, and they flocked to the companies that not only provided the best products, but also the best customer service.

Today, customer service is a distant memory in many cases. A customer is no longer treated as valuable, but instead has transitioned into a consumer. Consumers have been deemed a company right. In multiple ways, innovation has taken a back seat. There is a pervasive herd mentality. Instead of different thinking and innovation, too many companies follow the crowd and conform. If companies don’t conform for whatever reason, litigation becomes a significant obstacle for nonconformists.

Companies become more powerful through acquisition by creating industry specific oligopolies, or a monopoly as opposed to the good old days of competition (Circa the advent of the Internet). Increasingly, today’s competition is wrapped up in patent trolls, and licensing litigation. Competition seems to exist only in sports and politics (if we believe what we see is true). The business world has seceded from the world of competition.

This article is not intended to point a finger at any one company, but to highlight a development in the business world that crosses industries, and detracts from innovation and unadulterated competition.

We need to consider how best our global future can be served by restricting new ideas and experimentation from those of us who have much to contribute. Should monopolistic behavior and litigation serve as the backbone of the business world in the 21st century, I think not.

Booker Showers

Tune Your Information

Tune Your Information For An Effective Mobile Strategy


An unfortunate fact⎯employees spend large amounts of time re-creating information. Organizations and customers need to make informed decisions. A maze of systems, sources, sites, and repositories where the right information to support decision-making may be stored present unending challenges. Systems either contain incomplete information or too much information users are unable to filter to support informed decisions. Often users do not know the information they are looking for is there…

For instance, most enterprise systems offer an application interface to expose capabilities online. True to the Pareto principle, 80 percent of users typically require only 20 percent of the system’s available capabilities. A mobile strategy must include users’ information needs, their privileges to use enterprise information, and their current objectives. Then, the mobile strategy through data mining dynamically assembles and delivers the right information to support objectives.

Therefore, personalization allows systems and services (adaptive agents) to understand the profile of each user, every electronic asset, and create a match with the right information.

Adaptability on an enterprise scale

Many enterprise software applications offer attractive solutions to discrete business problems but cannot scale to support cross-departmental or global challenges.

Trying to extend solutions in the enterprise often creates a cycle  of hardware upgrades and custom development, which is the IT equivalent of painting yourself into a corner – at a certain point, any way out is going to be messy.

In addition, today’s IT teams struggle with the pace of changing technologies combined with the needs and demands of business.
Every department, every team, and every line of business has a list of priorities for IT support. Every business development, every optimization of a process, and every innovation means one more request for a new application, feature or report.

Moreover, IT teams struggle to make maximum reuse of completed work. To reuse completed work may mean reconfiguring applications for redeployment, or buying off-the-shelf software to meet needs. Further challenges involve  maintaining completed work, which often runs on different platforms in different languages. Information management within a mobile strategy regardless of the volume of transactions, and content, across the breadth of an enterprise should work together.  Architecting to scale, allows the use of services as much as needed.

IT systems are never static and information is constantly in flux. A business can gain competitive advantage as a result of IT innovation. Essentially, an effective mobile strategy connects  information repositories with  users on demand while providing a consistent user experience.

Booker Showers

Production Best Practices

A programmer should not expose resources within a REST initiative in a “bottom-up” ad hoc manner. Bottom-up development is inherently driven by immediate project needs. For example, how you solve a specific problem with a specific implementation (often driven by the influence of existing applications and associated behaviors masquerading as true business requirements).

What happens when an organization defines and implements REST with the mindset described? The REST implementation simply becomes layered with more spaghetti code of a different form that does not improve business process flexibility. Consequently, a monolithic application in a different technology is implemented often with disappointing results.

To achieve success, a programmer should not define REST in a “top-down” manner. Top-down business process analysis can lead to either “analysis paralysis” – continual refinement of a model hoping to reach perfection (which never comes), or “Big-Bang” projects – trying to define and implement everything at once. Either approach usually creates disastrous consequences (a combination of “death march” projects, and cost, and schedule overruns).

What do organizations need to make progress? A coarse-grained business model driven by key business processes. Not all key business processes may apply but definitely a representative set of high-priority processes to start. Architects and business analysts should collaborate to build an applicable model by extracting key business processes to define a normalized set of functions. Next, group functions together based on behavioral affinity as a straw-man set of initial, target resource definitions.

Resultantly, we have a useful framework for the “real work” – detailed analysis, design, and REST implementation needed for our current set of prioritized projects. Based on business process (and project) prioritization, we identify the needed resources from our business reference model and formalize the definition for the prioritized resources. Ideally, each resource should be driven by requirements extracted from at least two separate processes. Designing a REST resource based on a single use case may result in a fragile, and narrowly defined implementation lacking the flexibility necessary to meet the next set of prioritized projects. Formalization efforts are likely to result in modifications to business architecture – which is fine! We can iteratively enhance the architecture as progress is made towards a successful REST implementation.

Booker Showers

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



Giving application developers access to the set of broadly reusable REST controllers and resources produced through our aforementioned best practices, requires revisiting aspects of discoverability and consumable production. Simply, unless your services are uncomplicated like the ubiquitous weather example, a WADL is not enough. Moreover, syntactic definition does not equate to semantic understanding. Potential consumers need ready access to supporting artifacts (e.g., usage guide, sample client code) to make resources consumable.

A resource should be discoverable. Wrapping a resource with metadata allows the user to search for other practical resources using varying techniques, and user interfaces. Additionally, IT organizations efficiently deliver resources to potential consumers when well-designed. Minimally, support for mobile, browsers, and deep IDE integration enable users with varying roles to discover the right resources. For example, a business architect may comfortably use domain terminology searches within a browser. However, a designer or developer may prefer a visual search mechanism within a preferred IDE.

Booker Showers


IT Organization Should Get Back to Basics

I met a guy who became a good friend two Octobers ago. Our exchanges were funny, fresh, and all about the ideas. Ideas about music, ideas about technology, and ideas about relationships. In addition, we discussed lots of ideas about how to make the IT program we were on better. We acted on some of the ideas, mostly the ones about music.

One of the ideas centered around organizations and the power of organizing. The organization at the time excelled at spending a lot of money building the wrong thing, building it the wrong way, making a lot of noise while building it, issuing regular and spectacular corporate headlines, and the most important ⎯confusing and disenfranchising 80% of the org.  How such an organization survives as long as it has, baffles me.  Recently, there was another major program re-org….yeah, that’s going to do the trick, another case of managed chaos.

I have worked over 25 years in small, medium, and large technology organizations. I can honestly say, I have experienced managed chaos  in every organization. So, why does this managed chaos effect occur so frequently?  Maybe it’s because of me….nah, my friend says that he has experienced managed chaos many times as well, and my friend is one of the mellowest dudes I know.  Most of my peer group will also confirm similar experiences to be the normal state for IT programs….maybe not as severe but certainly consisting of similar characteristics.

IT OrganizationFueled by dramatically different motives, the organization we so thoroughly enjoyed was a pretty diverse group and included cowboys, indians, martians, criminals, addicts and a disproportionate level of skilled politicians.  I left the program in July, so one less indian.  The sentient leaders spoke constantly about “altruistic collaboration” but acted in ways that yielded no productivity multiplier, which I would argue is the principal aim of an organization.  Confusing goals, scheming leaders, a lot of money, arbitrary measures, plans within plans…..I’m telling you man, this was made for TV.

Wikipedia defines organization as a “social entity that has a collective goal and is linked to an external environment.” I define an organization as “a necessary set of rules, which compel a group of individuals towards a common goal.”  The larger the group, the bigger and more complex the org, the more leaders must maintain control and produce results.  I contend that leaders should be measured by the rules and goals they promote, and the quality and consistency of communicating the rules and goals.  Moreover, leaders should be measured by how the rules and goals they set produce desired outcomes.

Great organizations are grown, not assembled. Further, successful organizations rely on great leaders to exemplify their values and intent clearly through goals, rules, and actions, not rhetoric. Great organizations are quiet, productive, and consistently stay within operating margins. Successful organizations have laser sharp focus on their key performance indicators (KPIs), simple and effective work systems, and clear incentives that promote the right behaviors. Equally important, great organizations smartly leverage information and relationships without getting bogged down in process dogma. Ultimately, great organizations are naturally creative and collaborative because team members trust, respect, and enjoy producing excellence with one another.

So, IT leaders, professionals, tool makers, educators, and anyone else interested in advancing the IT work experience can we all get back to basics please!  There are too many cool things that we still need to build.