Why most of what I read about service-oriented architecture annoys me - Part 8
The conclusion to draw from these considerations is that in a service-oriented system we are focused first-and-foremost on the boundaries of trust between stores of data and on implementing the agreements among the owners of the data. The details of those agreements will vary from case to case and, consequently, so will the services we implement in accordance with them. Yet, the approach of identifying the trust boundaries between data stores, determining the contracts between the owners, and building services in accordance with those contracts remains consistent.
Of course this approach to the architecture of applications is applicable within large enterprises where there typically are legacy stores of data that clearly belong to particular departments. Within that context, our method of architecture will lead us to avoid the duplication of data across the enterprise. We will see, in the case of our example, that our application will refer to salespeople, and that instead of copying a list of sales staff into our application’s own database, we will promote the notion of establishing agreements and building services by which our application can leverage the authoritative list of employees in the human resource management system, or wherever that authoritative list may be. So it is that a service-oriented architecture systematically breaks down the barriers between silos of data.
Yet, I wish to emphasize that a service-oriented approach to architecture is not only applicable within large enterprises where legacy stores of data already exist. Let us imagine that the document management application that we have been discussing is the first one to be implemented within a small organization. Even in that scenario, our approach, by which we rigorously decouple data along departmental boundaries, and establish explicit agreements about how data items divided by those boundaries relate to one another, will yield important dividends. As the organization expands, as departments—that were once perhaps merely different roles performed by the same individual in the course of a day—grow in size and responsibility, the information system that we will have built for them at the outset will not hinder their progress. Always-already decoupled from the rest of the system, the human resource data could easily be moved onto a different storage system, say within a gleaming new PeopleSoft implementation, and our existing systems will keep ticking along provided we forged sound agreements about how the human resource system would behave in relation to other systems. And we will certainly have forged sound agreements, because that is what our method had us focus our attention on doing.
By contrast, using an object-oriented or component-oriented approach, we would have identified the entities our application was to deal with, and designed a single integrated relational schema for the data store in which instances of those entities were to be stored. Neither of those approaches would have enjoined us to ask to whom the entities belonged or might one day belong within the organization, and what agreements, beyond the explicit requirements of our own application, should be reached concerning the use of the data by groups to whom it does not belong.
It is our service-oriented approach to architecture that always demands that we put our immediate work within the context of the structure of our client’s organizations, as well as that of the past and future history of their enterprise. Such an approach is certainly appropriate now, when the excesses of the Internet technology bubble at the turn of the century have given way to a period of corporate suspicion of the sense of responsibility of software developers.