Blogs

RedMonk

Skip to content

Guestpost: On Hardware As A Service, engines as services, and Real SOA

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.

Categories: Uncategorized.

Comment Feed

4 Responses

  1. Well, you COULD tell us, but then you’d have to kill us ..

  2. I’ve been banging on about this to anyone who’d listen for the last 5-years and I thought we’d covered this before. Much of the effort behind our contributions to Grid, Web Services and more recently CIM, SMASH et al. have been driven by the need to be able to design secure, industry standard service based into faces into every facet of IT operations.

    Making out and out promises on direction and implementation is just too hard to do prior to product announcements, even in these blogging days(and I promise to get a business blog up and running soon), but I tried to couch this concept of a services driven infrstructure in which there would be no more private, proprietary communications between hardware components in various redbooks where you can squeek out some ideas and concepts.

    Check out Chapter-3 in http://www.redbooks.ibm.com/redpapers/pdfs/redp9115.pdf

    I wrote the first three chapters, they contain they typical background and saber rattling stuff, but as much as I could in chapter-3 I tried to outline where we are headed on this. CIM/Web Services etc. in the hardware? Publish and subscribe to events, managed through a message bus using autonimic managers… Plug any piece of hardware in somewhere, it does something, or has something done to it.

    I hear you won’t be at the July 5th Analysts event, shame there might be some decent wine this time, not like last time we met in Bedfont…

  3. The OASIS Reference Model for SOA defines a service as means for which needs and capabilites can be brought together. The model is actually not only applicable to software and hardware, but also real world “things” such as a coffee shop. If you create a model where you offer coffee’s to customers, you are providing a service for which needs (thirsty, sleepy customers) and capabilites (a large multinational *$ type coffee shop) can interact. The pattern you describe here is when you need to mod the service invocation request by sending a customer to the next counter, you can do it.

    This is why the SOA RM TC decided to make it into an abstract model – we realized that the range of applicability is far greater than software alone.

  4. I think the time for HaaS is now. The value that you can provide clients a value by branding your own services by using the product specs of a product. It allows you to control the process and provide a service for your clients that you can support more efficiently because you choose the product mix based on your core competencies.

    I would challenge you to look at the cell phone industry, where originally you spent dollars on equipment and paid every time the product was used. Now you sign a contract and they give a phone to use and now instead of having to support an enormous amount of products they choose the products they can support efficiently. They stream the process with a defined product, control the environment and effectively provide a monthly fee based service that includes hardware.

    This model is prime time for Technology providers looking to provide a managed service based business. The profits are much greater in this space but only for a short time until the model becomes more excepted.

    Sorry it’s my soap box. I have been providing this model since 2000 in the technology reseller community. I now help resellers experience this model real time.

    Ramsey Dellinger



Some HTML is OK

or, reply to this post via trackback.