Service Oriented Architecture : Service Oriented Architecture Strategy, Architecture and Infrastructure
Slide 2 : Service Oriented Architecture (SOA)
Slide 3 : Service Oriented Architecture (SOA)
Slide 4 : Clarity of business goal (mission statement)
Business Agility
consolidation
Qualitative consistency
Reduced cost through reusability
Strategy of development and implementation should focus on business areas of:
High volatility
Common function
Cost benefit
Clearly defined phases / levels of maturity
Wrap existing (legacy) services
Migration to a federated identity model (pass-though vs. managed security model)
Third-party product integration
Identification of enterprise-worthy services and deprecation model
Changes in business and IT model and culture (funding model, service ownership across LOB’s, roles and responsibilities, … ) Define a clear SOA mission statement and strategy
Slide 5 : Clearly defined and validated cost benefit assumptions ROI both short-term and long-term
Simplicity (major consideration – contrary to most vendor solutions)
Maturity The business services and corresponding infrastructure are mission critical and should be built upon mature and robust architectural components
Performance and extensibility The model and components will reused as the needs of the enterprise grow in terms of function and overall volume
Non-disruptiveness during periods of development and implementation
Consistency with unique business characteristics An SOA implementation should be tailored to the characteristics of the specific business
(Geography, volume, business priorities, service levels agreements, user knowledge and experience, etc.) Enumerate strategic considerations
Slide 6 : Not allow SOA to be defined by the software vendors through their software products ; rather, based on a business perspective that assures that business objectives are supported with the SOA and Web services strategy.
Not considering SOA as a business model architecture
Eliminate a proliferation of Web services running without any IT oversight or management, which can lead to an ad hoc SOA with poor interoperability and low services reuse potential.
Industry best practices (lessons learned) Other considerations “Detailed advanced planning is nice, but your best bet is to just get out there and start doing it. And keep it simple — very simple.”
(Amazon CTO)
Slide 7 : SOA Reference Model
Slide 8 : Service Component Architecture (SCA) Stack SOA Reference Model Stack
Slide 9 : SOA is, by definition, distributed.
The purpose of a service is to communicate remotely with another service, typically to share data.
The purpose of an SOA is to change the approach of IT from building custom, monolithic applications to building applications that are developed and integrated more and more using assets from a collection of shared, reusable functionality, i.e. services.
Centralized approaches to SOA infrastructure continue to be developed and proposed. Vendors will go to great lengths to convince the technology buying public that what they're offering is already SOA compliant, always was, always will be and was truly designed from the beginning to facilitate their customers' move to SOA, no matter whether it was originally designed to be a JEE application server or EAI system.
Vendors taking an opposing view to distributed SOA infrastructure often do so because that's the nature of the software infrastructure they already have.
This centralized approach to SOA adds cost, limits reuse, reduces flexibility and introduces a potentially expensive bottleneck. In the worst case it could even negate the reasons for moving to SOA in the first place.
A good SOA infrastructure shouldn't constrain your design options to J2EE, Web Services, hub-and-spoke, or any other implementation. A good SOA infrastructure embraces and includes them among the collection of reusable service assets. SOA Infrastructure