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
-
- 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
- Point-to-point integration per se.
- Just web services
- Not simply an ERP (or set of ERPs) that use the term SOA.
- >> Utopia. SOA Cannot be a goal in and of itself.
- A magic bullet. SOA still requires hard work.
- 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,