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

Having undertaken this analysis at least one cogent insight jumps right out. It is that user data does not belong to the group for whom our application is being built. Indeed, in reality, it almost never does. So, it would probably not be a good idea to do what most application architects typically do, which is store the data of their application’s users within their application’s own database. By doing so, they are behaving as though the users of their application do not use any other applications throughout the enterprise, and never will. And they force the enterprise’s system administrators to have to run from one application to another deleting user data whenever someone quits, and adding user data whenever someone leaves. Usually, an enterprise’s system administrators own all of the data for all of the users of all of the applications within the enterprise, and, consequently, that data should be stored in one place where those administrators can access it easily and authorize and prohibit people from using all of the enterprise’s applications from that single store.

Let us go further. We now know that we have four separate data stores within our application. Does that mean that there has to be four separate SQL Server databases? No: the actual storage facility is not important to the analysis, and should be chosen for expediency. How we arrange the content within the stores will be important though.

Let us deal with the expediency issue first. For our scenario, we will assume that the organization does not have an existing core accounting system or human resource management system, so we will include the data for those stores along with the contract document data within a single SQL Server database. To store the user data, we choose Active Directory/Application Mode, which is called ADAM for short. For those of you that are not familiar with ADAM, I have extolled its virtues at length, in this series of posts.