Vendor-Agnostic Context

How can a technology architecture be designed to avoid inhibiting dependencies on proprietary vendor platforms?

Problem An architectural model based on a single vendor platform can constrain an enterprise to the confines of that platform, resulting in constant limitations that may inhibit business requirements fulfillment.
Solution The model behind the technology architecture is designed independently from but still in alignment with primary vendor platforms.
Application Vendor-agnostic patterns and principles are applied to the design of the services, the service inventory, and its surrounding architecture.	Impacts Establishing a vendor-agnostic model increases design and governance effort while reducing the availability of proprietary features.
Principles Service Abstraction, Service Reusability, Service Composability, Service Loose Coupling	Architecture Inventory, Enterprise

Table 5.2 – Profile summary for the Vendor-Agnostic Context pattern.

Problem

Designing a service-oriented technology architecture around one particular vendor platform can lead to an implementation that inadvertently inherits proprietary characteristics. This can end up inhibiting the future evolution of an inventory architecture in response to technology innovations that become available from other vendors.

An inhibitive technology architecture is unable to evolve and expand in response to changing automation requirements. This can result in the architecture having a limited lifespan after which it needs to be replaced to remain effective (Figure 5.x).

Figure 5.7 – Vendor-centric technology architectures are often bound to corresponding vendor platform roadmaps. This can reduce opportunities to leverage technology innovations provided by other vendor platforms and can result in the need to eventually replace the architecture entirely with a new vendor implementation (which starts the cycle over again).

Solution

It is in the best interest of an organization to base the design of a service-oriented inventory architecture on a model that is in alignment with the primary SOA vendor platforms, yet agnostic to all of them.

A vendor-agnostic architectural model can be derived from a vendor-agnostic design paradigm used to build the solution logic the architecture will be responsible for supporting. The service-orientation paradigm provides such an approach, in that it is derived from and applicable to real world technology platforms while remaining neutral to all of them.

Figure 5.8 – If the architectural model is designed to be and remain agnostic to vendor platforms, it maintains the freedom to diversify its implementation by leveraging multiple vendor technology innovations. This increases the longevity of the architecture as it is allowed to augment and evolve in response to changing requirements.

Application

It is ideal to set a fundamental vendor-agnostic context for the overall architecture as early in the delivery lifecycle as possible, prior even to initial planning efforts (Figure 5.x). However, even for projects that are already underway, this pattern can be carried out in an effort to validate the strategic direction of the project and perhaps to form the basis for a realignment.

The key step to applying this pattern is the adoption of a design paradigm that is consistently used to shape predictable design characteristics across all solution logic deemed Òservice-oriented.Ó This ultimately dictates the requirements of the supporting technology architecture.

It is furthermore beneficial to avoid the use of proprietary vendor technologies that require services to form negative dependencies. Instead, vendor-agnostic service technologies are ideally utilized wherever feasible. For example, this can be achieved by combining this pattern with the Canonical Protocol pattern, as explained in the Web Services Architecture compound pattern in Chapter 9.

Figure 5.9 – The design of the service-oriented architecture is constantly kept agnostic to but still in alignment with vendor platforms.

Impacts

To establish and keep an architectural model constantly positioned as agnostic yet also in synch with vendor platforms requires that it initially be custom designed for an organization, and then periodically reviewed and revised to stay current with the direction of the overall industry. This translates into increased up-front analysis and design effort as well as additional, long-term governance responsibilities.

Furthermore, to actually leverage and incorporate multiple vendor technologies into a single architecture introduces increased maintenance cost and effort as it can result in the need for new skill-sets and a less consistent infrastructure.

Also, even though multiple vendor technologies may be available, maintaining a truly Vendor-Agnostic Context may limit the use of several products or technology features that are proprietary to the vendor. As a result, it may not be possible to apply this pattern to its full extent in all cases.

Relationships

The Vendor-Agnostic Context pattern is another fundamental element required to position a service-oriented architecture as a truly agile model, capable of evolving with the business in support of the Business-Driven Context pattern. It accomplishes this by establishing a non-proprietary context for service inventories, which must often be realized through the use of internal design standards. The one design pattern that can undermine the goals of this pattern is Service Agent, which advocates using event-driven programs that can be proprietary in nature.

It also relies on the application of the Decoupled Contract and Contract Centralization patterns that are key to ensuring that no implementation-specific characteristics make their way into the design of service consumers. By avoiding negative implementation coupling, the underlying service implementations can be evolved over time (as per the Service Refactoring pattern) without compromising the consumer programs that have formed dependencies on them (Figure 5.x).

Figure 5.10 – The Vendor-Agnostic Context pattern establishes an overarching, non-proprietary context that affects the entire service inventory.

Case Study Example

Case study content is not available on this Web site.