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,