Business-Driven Context

How can a technology architecture be designed to remain in alignment with changing business goals and requirements?

Problem Because it is difficult to support changing business goals and requirements with traditionally tactical and technology-centric architectures, business requirement fulfillment potential is not achieved.
Solution The business goals and requirements form the basis of the technology architectureŐs overarching context.
Application Business goals and models are used to define the on-going scope and state of the architecture.	Impacts Because of the strategic scope applied to the technology architecture and the fact that to be kept in alignment with the business will subject it to regular change over time, it will require a commitment in time and cost to govern.
Principles Service Reusability, Service Composability	Architecture Inventory, Enterprise

Table 5.1 – Profile summary for the Business-Driven Context pattern.

Problem

Technology architectures are commonly designed in support of solutions delivered to fulfill tactical (short-term) business requirements. Because the over-arching, strategic (long-term) business goals of the organization arenŐt taken into consideration when the architecture is defined, this approach can result in a technical environment that, over time, becomes out of alignment with the organizationŐs business direction and requirements.

This gradual separation of business and technology results in a technology architecture with diminishing potential to fulfill business requirements and increasing difficulty to adapt to changing business needs.

Figure 5.3 – A traditional technology architecture (A) is often delivered in alignment with the current state of a business, but can be incapable of changing in alignment with how the business evolves. As business and technology architectures become increasingly out of synch, business requirement fulfillment decreases, often to the point that a whole new technology architecture (B) is needed, which effectively resets this cycle.

Solution

The business vision, goals, and requirements are positioned as the basis for and the primary influence of the service-oriented inventory architecture. This maximizes the potential alignment of technology and business and allows for a technology architecture that can evolve in tandem with the organization as a whole (Figure 5.x). The result of this pattern is an continual increase in the value and lifespan of the inventory architecture.

Figure 5.4 – By defining a strategic, business-centric scope to the technology architecture, it can be kept in constant synch with how the business evolves over time.

Application

What this pattern essentially introduces is a prioritization of influences that determine the scope, complexion, and design of the service-oriented inventory architecture.

The following steps are recommended:

1.     Ensure that the organizationŐs existing business models and processes as well as its goals and directions are clearly defined and documented (Figure 5.x). The former establishes the business environment within which the architecture will need to be implemented, while the latter provides an indication as to how the architecture will need to be extended and evolved in the future.

2.     Ensure that the benefit potential of SOA and service-orientation is clearly defined and determine how and where strategic SOA benefits can aid in the fulfillment of current and upcoming business requirements and goals.

3.     Clearly define the future target state the organization intends to reach. By basing the target environment on business goals, it becomes more evident as to how the underlying technologies and architecture will need to be designed and evolved over a period of time. The result is generally a business-centric roadmap.

4.     Create an SOA transition plan that balances business goals and requirements with available SOA technology and designs and subjects all of this to the organizationŐs resourcing constraints.

5.     Periodically revisit the business goals and requirements and adjust the scope of the technology architecture in accordance with any changes.

6.     Refine and adjust existing service compositions and introduce new compositions as required to stay in alignment with the business as a whole.

There may be additional ways in which the basis of the technology architecture can be positioned in support of the overall business drivers. Organizations often have unique processes and business models in place that can further influence and shape the SOA implementation.

Figure 5.5 – The initial and on-going business context of the an inventory architecture is dictated by the strategic vision, goals, and requirements of the business.

Impacts

Unlike a traditional technology architecture that can remain relatively static for a finite period of time, a Business-Driven Context requires regular governance attention. To remain in alignment with changing business directions, services may need to be reconfigured, refactored, extended, and added, and the underlying inventory architecture needs to continually support and adapt to these demands.

Relationships

The application of the Business-Driven Context pattern is considered fundamental to inventories for which business services will be created. This pattern is therefore supported via the Process Abstraction and Entity Abstraction patterns because their application results in the creation of common types of business services that accurately encapsulate and express business logic.

The Vendor-Agnostic Context pattern fully supports the goals of this pattern by enabling vendor diversity in order to leverage different products and technologies to further maximize business requirements fulfillment (Figure 5.x).

Figure 5.6 – The Business-Driven Context pattern establishes a foundational, business-centric context for inventories but relies on other patterns to fully achieve its goals.

Case Study Example

Case study content is not available on this Web site.