Izabela Szlachta at 18:45, 8 November 2012

2012-11-08T18:45:31Z

New page

{{Cat|SOA|80}}
{{Soa Links}}

==Key Success Factors for SOA==
*Understanding
*Collaboration
*Management support
*Careful introduction
*Homework

==SOA or not to SOA==
*Calculate the potential benefits of SOA versus costs
*Don't replace existing, working solutions with SOA
*Don't try to apply SOA to critical projects unless you are certain you have enough experience
*In case of mass-data processing or real-time systems make sure that the performance will not be the issue

==Introducing SOA==
*SOA IS A STRATEGY
*Gradually introduction
*Impossible to get it right in the first place
*Hence, you can’t make all the decisions up front
*Remember, you cannot buy SOA nor you cannot have a consultant who tell you exactly what to do

==SOA Governance==
*Controlling the development and operation of software
*Making sure that people do what’s “right.”

==Governance Basics==
*'''Policies:''' define what’s right
*'''Processes:''' enforce policies
*'''Metrics:''' provide visibility and verify policy enforcements
*Documentation (for governance)
*Service management (repositories and registers)
*Monitoring
*Change and configuration management

==Governance Template==
*Visions, objectives, business case, and funding model
*Reference architecture
*Roles and responsibilities
*Policies, standards, and formats
*Processes and lifecycles

==Visions, objectives, business case, and funding model==
*Answer the question of why to introduce SOA.
*Funding model determines how the initial overhead of introducing SOA and new services will be paid for
*Explains SOA ROI

==Reference architecture==
*Reference that demonstrates your fundamental architectural decisions
*Preferred technology
*Message exchange patterns
*Meta model
*Primary and canonical types
* Preferred sources of standards (as Web Services has many)

==Roles and responsibilities==
Make it clear who drives and cares about the issues especially
*Architectures
*Technologies
*Process enforcement
*Finance control

==Processes and life-cycles==
*How the services are introduced
*How the services are disposed

==Processes in practise==
*Official process
*Perceived process
*Actual process

==Policies==
A law, examples:
*Every Web Service shall use SOAP protocol
*No enum type is allowed

A Guideline
*WSDL should comply to 1.2 standard

==Policy Template==
*The topic
*Problem the policy addresses
*Whether the policy is mandatory (a law or a guideline)
*The consequences for the infrastructure
*The consequences for service providers
*The consequences for service consumers

==Central SOA Team==
*Coordinates all the steps of implementing SOA
*Establishes and governs SOA
*Consolidates
*Standardizes
*Should not create another Ivory Tower

==The SOA Pilot==
*It is not a prototype (i.e. it must produce something which is supposed to work, not thrown away)
*Project should be non-critical but of palpable business value

==The SOA Pilot==
*Simple MEPs (e.g. synchronous and asynchronous)
*Minimal number of data types
*Lightweight ESB, not necessary used later
*Create only services you need, not you might need them in the future
*Think big, start small (don't fall into analysis paralysis)

==SOA Projects==
*There must be one diagram of the whole system
*Introducing new person should be relativity easy (proper induction documentation)
*Reviews and retrospective
*Movies with explanations
*External reviews and support
*Parallel planning and reviews for critical projects

==Bottom up vs Top down==
*Developer driven
*Business project driven
*IT driven
*Top management driven

==SOA Maturity Models==
*CMMI http://www.sei.cmu.edu/cmmi/index.cfm
*IBM Solutions
*OMG http://soa.omg.org/Uploaded%20Docs/SOA/SOA_Maturity.pdf
*The Open Group (OSIMM)

==CMMI==
#'''Initial:''' services that represent the initial learning and initial project phase of SOA adoption
#'''Managed:''' services using standards that are set as to the technical governance of SOA implementation
#'''Defined:''' services on the partnership between technology and business organizations in order to assure that the use of SOA provides clear business responsiveness
#'''Quantitatively managed:''' when you focus on the implementation of internal and/or external business processes
#'''Optimizing:''' when you have “optimized business processes SOA,” so that “the SOA information systems becomes [sic] the ‘enterprise nervous system.’”

==Service Orientation Red Flags==
*High-performance/real-time systems
*High-throughput systems
*Business-to-business interactions involving intricate transaction semantics
*Batch processes
*Data warehouses
*Any technology system or business unit where tight coupling and/or monolithic integration is desirable

==How can you tell a good consultant?==
*Good consultants do whatever they can to make themselves unnecessary
*You cannot fully rely on external consultant, internal knowledge of at least a couple of people is a must

Implementing SOA - Revision history

Izabela Szlachta at 18:45, 8 November 2012