CBDI Forum was one of the organizations back in those early days that Richard refers to that promoted the concept of service boundaries, but unfortunately not much of our work on that principle is freely available. So, I thought I would rectify that.
Services as Points of Flexibility
The first principle described in our CBDI-SAE SOA elearning material that promotes the concept of boundaries is that services are "Points of Flexibility". That is, services should be designed to provide points of flexibility (which we also call Articulation Points - a term coined by Richard) across functional, organizational or technology boundaries.
The objective is to allow flexibility/choice for the participant on either side of the Service.
So services form an important flexibility point – a place where change can occur on one side of the boundary, with minimum impact to the other.
As the figure above illustrated, services can be placed at the boundaries between:
- Organizations – allowing the participants in the service ecosystem to change
- This could also be boundaries within an organization, such as business domains or organizational units. Where certain services are placed on the boundaries between them.
- Technologies – allowing the implementation technology used by provider or consumer to change
- Resources (such as existing applications and other software artifacts) – that allow the implementation of the provider’s or consumer’s application to change.
Another concept in CBDI-SAE that promotes the concept of placing services at boundaries is the Automation Unit (AU). An AU is the collection of software artifacts that provide a service (i.e. its implementation). We use the AU rather than component to avoid the suggestion that an AU must also conform to component-based development (CBD) principles, which it may not do.
The AU concept is a logical grouping of software artifacts. Hence the figure below shows an external view of an AU on the left - that can be derived from looking at its public specification - and an internal view on the right, that is privvy only to the implementor/provider of the AU.
Consequently it can be seen that Orders Service and Customers Service in that example are effectively placed at the boundary of that logical grouping of software artefacts (the AU). Whilst the Sales DataService is not, and is only used inside the boundaries of the AU. The Orders and Customers Services are therefore the "points of flexibility" for the provider and consumer of those services. The provider of the Orders and Customers services would publish those in the Service Catalog for other service consumers to discover and use, whereas the Sales DataService would not be in the catalog (or at least not "public") as this is private to the publisher's implementation.
Whereas the Sales DataService is a point of flexibility for the AU implementor, who could for example migrate the Sales Database to a new database platform without impacting the Orders and Customers Service components, as long as the same Sales DataService is provided.
Other Logical Boundaries
This concept, that there are services placed on the boundary of the AU, as well as services that exist within the AU - could equally apply to logical boundary groupings such as organizational units, business domains, etc, where the service architecture differentiates between the services provisioned for intra-unit consumption and those for inter-unit consumption and hence placed on the boundary.
Over time, services could potentially be re-classified as the boundary lines change.
Further Reading
More on the concept of Automation Units and other key SOA deliverables can be found in
- The Architecture Component of the CBDI-SAE Reference Framework for SOA
- Service Contracts in the Service Oriented Process
- Service Portfolio Planning and Architecture for Cloud Services
No comments:
Post a Comment