Therefore the components of any Service (business service, web service, project management service, aviation service or security service, etc., and etc.) should be identified and modeled. All Services contain the following:
- An Interface which facilitate the inputs and outputs
- Cost associate in conceiving, designing, implementing and maintaining this service.
Here are also some characteristics of any Service?
- How is the Service invoked? – Service Invocation
- How is the Service delivered? – Service Delivery
- How good is the Service? - Quality of Service
- How is the Service supported – Service Support
Even though all Services have the common components and characteristics, it is important to understand that Services are realized within a context and some characteristics or attributes become mandatory. For example within the context of technical solutions architecture, Services can be realized as Web Services, Database Services, or any other Technical Service. Technical Services usually have well defined Inputs, Outputs, Service Interfaces and the Service Cost which is usually associated with the licensing of the technical infrastructure or the cost of building the technical capability. For example, the term “network protocol” is big within this context since it describes the underlying architecture of the Service Delivery mechanism.
If the context is a Business Automation process, then Business Automation Service usually involve the application of Technical Services to address how a certain business process or a sub-process is automated. Since the application of Technical Services and Technical Services may sound similar, they are uniquely different. The lack of clear delineation of what a Business Automation Service is and what a Technical Service is one of the common underlying problems within SOA. There are also Services within the context of a Business. For instance, Oracle Corporation sells Support Services for its products. The Support Services usually include Help Desk personnel who answer and guide Oracle Support Services’ Consumers on how to resolve issues with the Oracle product. Oracle and others have tired to automate this component in the Support Services model however the “human touch” and human interaction is highly desired in the Support Services Consumers’ community. The Support Services Consumer invokes the service when he or she is having issues with the Oracle product, which has Support Services attached to it. The Service Consumer uses the phone or website interaction as his or her interface with the Oracle Support Services. The Service Consumer doesn’t need to know who the other person is, how is he getting paid, what are the Support Services’ processes are, etc., etc. Now the question I often ponder about is:
“Can a business be truly SOA with respect to various contexts and not just IT?”
I believe it can be done however will the Return On Investment worth this change.