Key Ideas for SOA

Overarching Statement
Lead Ideas
  • Not really a product, but a distinct architectural style to help design services that meet the business needs. An approach for adapting and deploying needed processes and services. (Follow with a description of what it is and what it yields.)
  • An enterprise architectural style.  Encompasses an ecosystem broader than one particular application
  • Clarify with more rigor what a service is.
  • Guiding principles about service design: Key of SOA is to separate service contracts from implementation in order to maximize clarity regarding service contract, so that at a business level there is a clear understanding among providers and consumers about how the interaction should happen.
  • Corollary in software is the separate service contract from implementation.   Service can be fulfilled in a number of different ways
  • That service approach allows the orchestration things in order to accomplish more complex compound processes.
  • Service ownership:  This requires there be one and only one Service of Record . Ultimately it is the business area that owns, defines business process. 
    • There are implications for governance
    • Note: we will want to conceptually relate this to notions of service and ownership as understood in ITIL.  e.g. HR is  a business owner.  Others may have operational ownership
SOA and process clarity: Notes about automated business processes and information.
  •  
  • Does not need to be automated.   E.g., student rep.  A specific set of services (defined in a contract)
  • There is a fundamental problem: lack of clarity in the business process.  Flaw to assume software will mitigate the that problem.
  •  
  • SOA requires clarity and agreement around bus processes and what services are fulfilled at each stage in a business process.
  • SOA requires statelessness: I can poke and get an answer.  I don’t have to send configuration parameters ahead of time in order to get the answer I need.  I don’t need to know anything beyond the published contract.  The contract is the only thing I need to know.
What SOA is not
  1. Point-to-point integration per se.
  2. Just web services
  3. Not simply an ERP (or set of ERPs) that use the term SOA.
  4. >> Utopia.  SOA Cannot be a goal in and of itself.
  5. A magic bullet.  SOA still requires hard work.
  6. Appropriate for teams that work in silos - there is a lot of coordination and communication required.
References

SOA manifesto  http://www.soa-manifesto.org/

Ann Thomas Manes

Ai Scott

Marina, Jonathon Mott,

  • No labels