Some great unconventional thinking here folks, from someone I met a while back and admire. And no I can’t tell you his real name or who he works for.
Unconventional Service Providers
by the SOA Wizard
Many companies are trying to discover how Service-Oriented Architectures will benefit and bring new value to their business and customers. The most obvious industries are those that by their very nature are service oriented (i.e. financial, insurance, package delivery).
However, there have been documented cases where even governments around the world have begun to explore SOA in order to improve their services. Probably the most widely documented case comes from Queensland Transport. Queensland Transport is a regional government agency in Australia who began exploring SOA in 1997. In 2000, an SOA-based vehicle registration system was deployed. Since they have followed-on with other government transformations such as outsourcing vehicle inspections, created a new revenue stream from distributing their data, and have shared their services with other agencies.
These are typical examples of where and how SOA can be applied. But, in most cases the notion of a service in an SOA is that of a software component. I have often wondered who dictated that to be the rule and the norm. Take the case of the package delivery industry. I will give you that a majority of the services offered by companies that find themselves in that industry are software oriented as well, but their most important and basic service is not one implemented in software. Their most basic service is performed by a human when they deliver the actual package.
To further this notion of unconventional service providers, let’s examine another governmental situation, but this time one from a more tactical perspective. Let’s say that the United Kingdom Ministry of Defense has deployed a Pheonix over a certain area. Now let’s say that there exist software components that can be utilized to communicate with the Pheonix, and that can be orchestrated as part of a much large business process. What if a user could request usage of the Pheonix as part of that business process in which the Pheonix is tasked to perform its mission in some other location? The user could initiate the request through a software component, once approved the Pheonix would relocate to the new location perform its task, and upon completion of the task relocate back to its original area.
In the situation above, there are two service providers 1) the software component, and 2) the Pheonix itself. The concept of a software component in this situation is no different than that in any other industry. The software component could be implemented as a Web Service in this situation just as it is in many others. However, I would like to focus on the unconventional service provider, the Pheonix. People use hardware devices to perform services each and everyday. People use a microwave oven to prepare popcorn and reheat meals, they use electric openers to open can food, and they use automobiles to move them from location to location. The notion of an aircraft, a piece of hardware, should not be to far from common thought. As governmental departments, such as the MOD, explore utilizing SOAs in the future one can not rule out unconventional service providers.
After thinking about this notion a little further and in more detail I’m not convinced that HAAS, Hardware As A Service, is all that unconventional of an idea. I have stated common everyday examples that support this as well. So in my opinion HAAS is really not an unconventional service provider.
Note: The above situation involving the MOD Pheonix is a hypothetical situation. The ideas and examples outlined here are the ideas of the SOA Wizard and should not be considered to reflect the ideas or plans of the MOD.