Techies are hearing about a concept and then running out and attempting to build something that represents that concept.  Seems reasonable, right?  Well, the issue arises when they explain what they have done to someone else and they say, "I've built that concept."  Too abstract....

Try this SOA = Web services (and the set of standards that underpin them: WSDL, UDDI, SOAP, etc.).  Is the picture getting clearer?

Service-oriented architecture is an architectural pattern that cannot be packaged, sold or delivered in a product.  It is as much a philosophy about the way in which next generation business processes will be designed, described, tested, evolved and deployed as it about the underlying technologies that support it.  The adoption of SOA as a means for delivering business processes made up of loosely-coupled integrations which are supposed to be rapid to deploy, more flexible to change, and ultimately delivering more with less from IT has some significant implications both for people delivering software-based solutions as it does the company adopting SOA as an approach.  
 
As the pace of technological complexity grows within IT, there are a number of compounding factors that are weighing heavily upon today's CIOs and with good reason their tenures are getting shorter and shorter:

1. the business is demanding more and giving IT less to work with.
2. the rapid pace of innovation is continuing and there are so many different technologies still in use that just keeping the lights on (KTLO) represents a significant part of the IT budget; IT is not retiring legacy technologies fast enough. 
3. IT must evolve out of this problem by using their limited innovation spend to invest in new, more flexible approaches to deliver what the business wants AND, at the same time, retire (or at least start the retirement of) enough legacy technologies to (at a minimum) not raise the KTLO spend. 

What SOA proposes from a pattern or philosophical approach is the following: IT must transform from a resource-centric function to a service-centric line of business, so that it becomes a service provider (and only a service provider, nothing else).  In so doing, IT can transform itself, its budgets, its way of doing business and better supporting the organizations they work within.  

In terms of organizational impact, there are four things that are critical for companies which adopt SOA to understand in order to optimize their outcomes with SOA.   If they do not understand the following, they are simply not going to realize the benefits of service-orientation (we are starting to hear about some of these companies already and we will hear more in 2009):

1. Organize IT deliverables around the notion of a service as the economic unit of measure for supply, demand, quality and value
2. Fund IT around a structure and operating model that supports the business in the context of their structure and operating models as Service Providers (enterprise architecture for IT)
3. Apply automation to IT in the context of the enterprise architecture for IT, and exploit the resulting information to drive business direction
4. Initiate transformation methodology to institute service-orientation addressing SOA Governance, Quality, and Management

Now, I haven't mentioned web services, CORBA, JMS, DCOM, WCF, HTTP, REST, SOAP, WSDL, UDDI, IIOP or any number of other implementation, middleware, or standards that can be used in some way shape or form to deliver upon all of this.  But, what I have outlined (I hope), says something significant about what our customers are faced with and, subsequently, the solutions that HP Software MUST provide if we are going to continue to be relevant and successful as a software company.
 
In the short run, we delivering solutions focused on SOA Governance, SOA Quality and SOA Management.  That being said, these solutions are pretty flexible and can be used to support a number of SOA-styles that we are seeing customers implement; everything from WS-* to REST, to XML over JMS, and more.  One thing I will share with you is that we see A LOT of customers approaching their existing Application Modernization projects (in an attempt to retire CORBA-based solutions or mainframe deployments, monolithic applications, and even client/server apps) by taking a service-centric approach and looking for ways to catalog existing application artifacts (assets like Copybooks, IDL interfaces, etc.) using our SOA Governance solution.
 
In the longer run, you should see the connection being made to the financial decisions through integration of our existing solutions to the Portfolio and Project Management solutions.  You should see the alignment between Operations personnel and Enterprise Architects at our customer sites when the Ops folks adopt ITIL v3 and Enterprise Architects adopt SOA.  HP can facilitate this via integrations between our SOA-based solutions with our ITSM solutions.  Finally, the more structured information is being captured which describes the applications, processes, and services the more HP Software should be able to do in terms of driving automated deployment of these solutions.  The earlier in the lifecycle that we capture this "model" of what is being created (i.e. through SOA Governance), HP Software should be able to automate the deployment of the appropriate parts in a test lab as well as correctly instantiate a working system in the production environment including automated population of Configuration Management Databases (CMDBs) [btw, this is another example of a concept and implementation issue].  
 
So, in terms of solutions that we may be building for our customers, SOA is a critical trend that essentially is behind the scenes on everything from Cloud computing, to virtualization, Web 2.0 (specifically enterprise mashups), and Software-as-a-Service).  Oracle and SAP have bet their companies on delivering integrated suites of their applications based on this approach.  Yes, there are a lot of technologies out there that are focused on integration (I actually liked CORBA a lot!), but what are we doing to HELP customers understand what I've written above, what our solutions can (and cannot/will not) do, and how we can help them address the problems that we face?
 
This is the collective challenge of our industry.