So far we’ve established that we need:
- cooperative teams that have…
- a common understanding and education pertaining to industry and enterprise-specific knowledge areas and that…
- we need to consistently cooperate as a team, apply our understanding, and follow a common methodology and standards in a disciplined manner.
In some IT enterprises, especially those with a long history of building silo-based applications, achieving these qualities can be challenging. Cultural, political, and various other forms of organizational issues can arise to make it difficult to attain the necessary organizational changes required by these three pillars. How then can they be realistically achieved? It all comes down to defining a balanced scope of adoption.
The scope of adoption needs to be meaningfully cross-silo, while also realistically manageable. This requires the definition of a balanced scope of adoption of service-orientation.
“The scope of SOA adoption can vary. Keep efforts manageable and within meaningful boundaries.”
– SOA Manifesto
Once a balanced scope of adoption has been defined, this scope determines the extent to which the other three pillars need to be established. Conversely, the extent to which you can realize the other three pillars will influence how you determine the scope (Figure 1).
Figure 1 – The Balanced Scope pillar encompasses and sets the scope at which the other three pillars are applied for a given adoption effort.
Common factors involved in determining a balanced scope include:
- cultural obstacles
- authority structures
- business domain alignment
- available stakeholder support and funding
- available IT resources
A single organization can choose one or more balanced adoption scopes (Figure 2). Having multiple scopes results in a domain-based approach to adoption. Each domain establishes a boundary for an inventory of services. Among domains, adoption of service-orientation and the delivery of services can occur independently. This does not result in application silos; it establishes meaningful service domains (also known as “continents of services”) within the IT enterprise.
Figure 2 – Multiple balanced scopes can exist within the same IT enterprise. Each represents a separate service inventory that is independently standardized, owned, and governed.
The domain-based approach to the adoption of SOA and service-orientation originated with the Domain Inventory pattern. However, it is also important to acknowledge that logical domains within a domain service inventory can also be established by classifying services based on the nature of their respecitive functionality. This form of separation is relevant to service governance and is the basis of the Service Layers pattern, as well as the related Utility Abstraction , Entity Abstraction , and Process Abstraction patterns.