Service-Oriented Architecture

I was thinking about this on my way to work this morning.  In trying to understand SOA in terms of more everyday elements, I considered my truck as a piece of "hardware" in my enterprise and the CD I was listening to as an "information" requirement I have identified for my enterprise.  That information can exist in a "database" (the CD) that is necessarily upon my car's hardware component (the CD player).  If the CD player is not designed to play MP3 file formats, I may not be able to access some "information".  Additionally, the CD player requires some maintenance and I have to expend a certain amount of resources (time, physical energy, money) in acquiring the information (CDs) that will be of greatest worth in my enterprise.  Now, I started thinking about applying this example to SOA.  An enterprise requirement is that I be able to access information and decouple the source of the information from hardware solutions.  Essentially, I want certain information delivered to my truck without another intermediary piece of hardware.  How about having satellite radio to which I could subscribe and through which service I could directly acquire any and all relevant information?  In this scenario I see that I have cut out the intermediary hardware component (CD Player), but I still have an essential couple of components--the satellite radio and antenna.  What has changed is the information delivery interface to the enterprise, the existing enterprise component must be changed out, and a new datalink must be described.  My business process for acquiring information must also necessarily change raising questions about personal information security.  Namely, how will payment for the service be exchanged?  Will it go over the satellite data link or through a strictly ground-based network.  Therefore SOA is not about simply describing Services without regard to Systems.  It is about accurately describing the information delivery interface, required communication links, and business processes.