Why most of what I read about service-oriented architecture annoys me - Part 4

Now let us subject these requirements to a service-oriented analysis. You will recall that when we used to do functional analyses of requirements, we would draw flowcharts to help us identify the processes that would need to be implemented. Then, when we progressed to object-oriented analyses, we would “highlight the nouns” in the statements of the requirements, each noun being a candidate class (See David A. Taylor. 1992. Object-oriented Information Systems: Planning and Implementation. Page 101.)

Well, in undertaking a service-oriented analysis, we begin as would in an object-oriented analysis, identifying all of the nouns, but then, as a subsequent step, we identify who in the enterprise own or would own the objects referred to by the nouns.

Looking at the requirements for our example, we can highlight these nouns: branch administrator, sales contract document, salesperson, and branch. We’ll omit the printer, the supplier, for the sake of simplicity.

In a second pass, we try to substitute more generic nouns for some of those we identified at first, where appropriate. We reason that branch administrators are just one species of user, and that salespeople are a type of employee.

Now we move on to the step of asking who owns the data concerning the objects identified by the nouns. We reason that data concerning users belongs to the information technology department, the system administrators, who will ultimately be responsible for maintaining the list of authorized users, updating their profiles, and so forth. The authoritative list of branches would likely be in the corporate accounting system. Employee data is no doubt in the human resource management system, while data about the sales contract documents, well, that belongs to the branch administrators, and it is their system that we are in the process of building.

Now, what if the enterprise in question does not have, say, a human resource management system? Well, you proceed in your analysis as if it does, or, more precisely, as if it someday will have one, treating the employee data as if it resides behind a boundary of trust beyond our own.