Your app is not alone!
Applications often rely on other applications for data and functionality. For example, an application for managing ticket sales at an airline may reach out to a separate application for scheduling flights to ensure availability of seating and gauge travel times. The first application is thus not an island as it is efferent coupled to the second application. What would happen if the second application were offline or sluggish in response? Would the first application be unable to facilitate ticket sales?
A system is a functional collection of applications, and service-oriented architecture (SOA) is a systems development method for stability, ensuring that if one domino does fall that there is not a cascading effect. With SOA, the stakeholders of any single executable within a system maintain uptime for their piece of the pie without tying the fate of their application to those of others.
It is naive to assume that networks are "reliable" and "secure" or that latency and bandwidth are not concerns. It is wise to realize that a system is not a uniform whole and to want to buttress the bridges between entities.
Enter services. A service is a technical authority for a specific business capability. For example, a shipment sent event would come from your logistics service. Both data and business rules reside within services. Services in SOA act much as do capacitors in electronics in that they take in "juice" at often random, inconsistently rates, store it, and then ration it back out again in a consistent, predictable manner.
State managing facilities safeguard against the introduction of dirty data by long-running processes. In a scenario in which an application has to push updates to the three separate databases of three separate applications, it would be disastrous if two of the three databases were to be updated only to have the process die before completing without a failover mechanism for rolling back the altered data. State managing facilities account for the plan B scenarios. Saga and Acta are examples. The former assumes that every action has a compensating action and the later that zero or more actions have compensating actions. Both have temporally-based business logic for a series of steps (example: if receiving a response before five minutes do X, but otherwise do Y).
Hear no evil. Speak no evil.
If your application needs to communicate with others, there may be pain in breakdowns of giving or receiving. Headspring can consult your division or organization on SOA compliance for how to "play nicely" with others, but, perhaps more importantly, it can spare you the jolt of being cut off from the information you need. A system can be stronger than its weakest link. An application's performance need not be biased by that of its neighbor.
Smooth sailing beckons. Call 1-877-459-2260.