There are three forces that we can bring to bear to push change to a Service Oriented Architecture.

(1) Architectural Purity

>This is the force of arguing that it is the right thing to do. You can state a lot of reasons why it is the right thing to do like: composite applications, workflow, ROI, integration cost reduction, etc. Basically, you stand on high ground and preach that this is the correct approach. This is a difficult sell to pull off especially in a heterogeneous and feudal enterprise like a higher education institution.

(2) Consumer Request

>This is force of the consumer of the information or service asking for a new way of getting information. The statement goes something like, “I need to know X from your system. I would prefer to get that information in a Web Service rather than a flat file.” The reasons for making this argument may have to do with timeliness of data (it needs to be up-to-date at this moment) or ownership of the business rules (e.g. you have all of the data to determine if X is true so you should just provide the answer instead of sending me the data so I can derive the answer) or possibly wanting to be on the front edge of technology.

(3) Provider Demand

>This is the force of the data provider (or source or system of record) deciding they will no longer support older interface styles (flat file transfers et al) and instead will only support a Web service interface. This argument can bring to bear cost incentives. The provider can state, “if you use the Web service, we will make sure that the Web service is upgrade and updated. If you must have a flat-file, then you must pay for all of the work to develop, maintain and deliver the file”. They can also bring policy enforcement into play. “Any request for a flat-file will be reviewed and you will have to make an argument why you must have the flat file rather than use our Web service”.

The Provider Demand force is the one that has the most weight behind it and is the one that is mostly like to carry day. We can argue about the Architectural Purity of a SOA and we can request Web services but that will fall on deaf ears or at least un-funded ears. When the data providers demand that the data consumers use their Services or pay the bill, then we will see rapid adoption of SOA.