When talking about SOA what we tend to on a technology basis is talk about Web Services.   Services typically encapsulate some unit of business logic, useing a standard method of communication.  Web Services provide a way to develop logic that is originally indicitive of a particular problem, but can be reused by other units within the enterprise.

A real world example of a webservice would be an accounts receivable service.    Calling this webservice with the proper information would cause the accounts receiveable database to be updated with the information that a particular account had been paid.   As a single unit of work this doesn’t sound so terribly exciting.

So let’s use a real world example.   A manufacturing company who manufactures generators has built a new website.   They have streamlined their entire IT infrastructure so that from this single website a client can place an order for a generator and expect turnaround and delivery time within 30 days.

Let’s break down the steps that must occur before the generator is delivered to the client. Assuming the contract was written so that 50% of the money was delivered up front, and 50% after the generated was delivered and installed.

The client would log onto the site, fill out all the specifications that were required, specify delivery location, then add a method of payment.  Easy enough, but how would this web request turn into actual manufactured goods delivered to the site on time

The first step of course is to take receipt the initial payment, and inform accounts receivable that payment has been made.  (Visa.processPayment(cardno) then AccountsReceiveable.makepayment())

The second step is to inform Manufacturing of the desired specifications of the generator and date of expected delivery.(Manufacturing.build(specs,deliveryDate, OrderNo)

Manufacturing would then have to order the parts to build the generator. (DateToBeDelivered = Parts.request(PartsList))

Manufacturing would then inform delivery that the generator is ready to be picked up.  (Delivery.pickitup(ModelNo,CustNo,OrderNo))

Delivery would check the customer database for information on this customer, and this particular order no.  Customer.getInfoOnOrder(OrderNo)

Delivery, once delivered would inform Accounts Receivable that the generator had been delievered, so that the rest of the payment could be collected.  (AccountsReceivable.theyGotIt(ModelNo,CustNo, Date))

Accounts Receivable would then take the last bit of payment.  (Visa.processPayment(cardNo))

While this is simplified in terms of what really goes on when a generater is ordered from a manufacturing company this example illustrates how many different pieces of the enterprise are involved in a given order.  So the obvious question at this point is, why doesn’t the enterprise build one massive system to handle running their entire business.

Because the risk to the enterprise in depending on 1 and only 1 system is to great.   As a nimble flexible and agile enterprise you have to have all of your departments functioning independently of one another.   In our example, you want all departments, Accounts Receivable, Manufacturing,  Delivery, Parts to be working asynchronously of each other, and not dependent.   You also don’t want to have to risk your entire business flow, if you need to do an maintainence release of the software by relying on one system.  So in order to isolate each part of their business company have built silo’s around each individual department so it can operate in a protected mode.

However while protecteing each individual group from a catastrophic failure, companies over time have made it more difficult for these groups to work together.  Each invidual group has it’s own self contained systems to perform it’s given part of the business.   So in our small example, you would have an Accounting system to do Accounts Receivable, you would have Parts System that monitors and keeps track of parts, you would have a system responsible for controlling the manufactureing process.   You would have yet another system responsible for running the delivery process.   Each one of these systems would operate entirely independent of one another.

So how do we join these systems together without making one giant enterprise level application with a single point of failure?   Enter Web Services.  Web Services are the connective tissue of the enterprise.  They open up each part of the business to other parts while maintaining control within each silo.    SOA at the enterprise level is the practice of articulating how the overall enterprise works, in terms of system and dataflow, cataloging the current state, and defining how to solve a global business problem typically using Web Services as the means of communication. A SOA architecture typically tries to align IT with the business in order to fit all the pieces together.  It involves extensive amount of modeling of the current business, so as to articulate the given solution.  This model, then because a basis for communicating how the business is run, from an IT perspective and how each piece fits together.

This is how a SOA enterprise level undertaking become an IT asset.