In his recent post JP Morgenthal explains that in a nutshell an SOA implementation is:
Identify, consolidate, orchestrate and govern a set of business functions or capabilities.
Morgenthal starts with explaining of what exactly a service is in SOA terms means:
There are lots of things that you can call services, which is where many of the problems arise for SOA. I believe that the use of the word service in context of "Service Oriented Architecture" connotes a particular meaning that filters out most of non-applicable definitions of services... SOA is an architectural approach designed to identify and delineate business functional boundaries within a particular domain. A domain can be a single organizational unit or an entire industry. Regardless of the domain, if there are interactions within the domain, then there is most likely more than one unique business functions used to complete those interactions... Very simply, SOA is the initiative designed around identifying the domain goal, marking the necessary business functions boundaries required to reach that goal, consolidating these business functions so that there is no redundancy and then orchestrating the process to reach the goal against the resulting set of business functions.
He continues by explaining that despite all the hype in the media that makes many to believe that SOA is very complex and requires expensive software and resources, in reality it is just about business-aligned functional decomposition:
... looking at a particular domain and figuring out how we can chop it up into a group of services that work together. For example, a landscape service and a mulching service have particularly good synergy, would you agree? These are two distinct services, but they have what we call a loosely-coupled relationship. That is, they work together for the duration of a task and then go their separate ways. Granted, the task of looking at a domain and breaking it down into a set of services is a strategic skill that requires an experienced practitioner, but formulating the boundaries and putting the governance around those boundaries in place can be done by current management.
In SOA all services are implemented as software, but what is important in this case is that each one of them represents a real business function. The software implementation is just a way to automate the function execution:
... because it was implemented in software, does not, in and of itself, make these services. It's the role they represent. These services allowed the business to reduce complexity, consolidate around one way of achieving a goal and do so in a way that was agile and flexible. Moreover, while they are not dependent upon one another to provide value to the business, one could easily see how they could work together synergistically...
Morgenthal continues his SOA explanation by examining how two topics typically linked to SOA - Software-as-a-Service (SaaS) and component-based software development really relate to SOA. In his opinion SaaS is not really an SOA service because:
SaaS meets one criteria we defined for a service - we want to pay a fair price to use them and we don't want to own them. However, most SaaS is just rented software. You're still responsible for integrating your data with the SaaS application after you rent it. You're still responsible for configuration of the forms and workflows after you rent it. For me, SaaS fails to meet the other key attributes of a service.
Many practitioners, according to Morgenthal, while discussing SOA, really talk about component-based development. In his opinion, this is happening when people are using the term SOA to describe a way to build a software system. When someone starts to talk about platforms or utility services:
... these are sure-fire indicators that the discussion has degraded into software design methodology and has left the realm of SOA... there's no such thing as a "utility" service and it's just a software component... The software providing the business service could exist without the existence of the utility service. The resulting solution may not be as modular of a design and, perhaps, not offer the service provider, the preferred level of agility and flexibility, but the service consumer would be no worse off than if you decided not to build a utility service, but instead, developed that business logic directly in to the software itself.
Morgenthal post does a great job of defining the SOA fundamentals, and keeps reminding us that it is about architecture and business IT alignment, not about software design methodology or vendor tools.