Service Oriented Architecture (SOA)

Service Oriented Architecture (SOA) is a business-centric IT architectural approach that supports integrating your business as linked, repeatable business tasks, or services.  SOA leverages open standards to represent software assets as services.  Align business design and IT solution design to enable an agile enterprise that is responsive to new opportunities.  An approach for building business systems that deliver application functionality as services to end-user applications or other services.

  • Provides a standard way of representing and interacting with software assets
  • Individual software assets become building blocks that can be reused in developing applications
  • Shifts focus to application assembly rather than implementation details
  • Used internally to create new applications out of existing components
  • Used externally to integrate with applications outside of the enterprise
A service-oriented architecture can be defined as a way of designing and implementing enterprise applications that deals with the intercommunication of loosely coupled, coarse grained (business level), reusable artifacts (services). Determining how to invoke these services should be through a platform independent service interface.  An SOA is composed of multiple layers.  At the heart of the SOA are services, components that realize services, and service flows.
While Web services and SOA are not synonymous.  Although Web services are an important tool and one implementation method for SOA, but there are other patterns that may be more appropriate for any given use-case.   In general, SOA can be thought to consist of service providers and service consumers.  The providers define what the service looks like and how to invoke it through an implementation independent service interface. The consumers use this interface to construct the necessary data and invoke the service.An optional construct is the introduction of a discovery mechanism that acts as an intermediary to which providers publish the service interface and from which consumers discover it. This is useful for enterprises with many services, but is not covered in this specification.
One of the keys to SOA is defining the correct level of granularity. This is a fairly subjective thing, but generally speaking services exposed to other systems should provide operations that correspond to business functions. This does not mean that all services are coarse grained. Finely grained component services may be used by business services, but would not be exposed to other systems.
A key aspect of successful SOA implementations is having business involved in the effort from the beginning. One of the values from SOA you can gain from SOA is improved Business / IT alignment.  SOA Governance provides this insight into your SOA, enabling stakeholders to furthermore identify the return on investment (ROI) gained from the SOA implementation.  SOA governance effectively manages the service lifecycle by governing key processes across the entire lifecycle.  Effective SOA governance must:

  • Help define guiding decisions around these processes
  • Properly enforce these guiding decisions
  • Communicate these guiding decisions effectively
  • Evolve these guiding decisions with changing needs
  • Ensure that the perspective of both service providers and consumers are properly met

There are two aspects of SOA Roadmap:
•The business Architecture – it caters to the business plan and describes the “What” from a business perspective
•The IT Architecture – it talks to the IT specialists and describes the “how”