Final session of today is about identifying and avoiding common anti-patterns in your service oriented architecture solution. It is presented by John Callaway (Quicklearn).
Agenda
Anti-patterns defined
Common anti-patterns and solutions
Patterns
A pattern is something which is documented to a common problem that produces beneficial results, there everywhere and SO ones adhere to tenets of Service Orientation. The tenets are all to known by now everybody in world who knows Service Orientation (explicit, autonomous, policy, share schema and contract).
Core SO Patterns
Share reuse assets
Share representations of core entities and types
Consolidate function and data
Conform to standards
Separation of concerns between system aspects
Anti-Pattern
A pattern design that may appear to be beneficial, but ultimately is detrimental
Identify SO can be best de done by defining what are not best practices..and avoid them
Quote Michelangelo : When I look at a slab of marble I see the statue that was trapped inside.
Scenarios
A) Someone goes to conference and hears about SOA and tells his company. We already do SOA (anti-pattern defensive SOA), adopt to buzz word yadiyadayada…
Cause: miscommunication of what SOA means or governance is missing.
Solution: education, clear definition of what SOA is and mean for company, adapt to SOA governance to enforce definition.
B) Learn all about ESB, leads team to develop an ESB, layers of technology with little or reuse, proud of build ESB (Nice Shiny Nickel Anti-pattern)
Cause: implementing the latest technology,
Solution: Begin with the end in mind, identify goals in organization related to agility and implement the technologies
C) Next scenario like B but then SOA (Read Gartner, conference attendance) (Technology Alter Anti Pattern)
Cause: investment into technology to the exclusion of what matters most, since IT controls budget investment in technology du jour
Solution: split IT budget between operation and development, focus on IT support
D) IT department decide to implement IT without the business involved (People’s Republic of IT or Golf Course SOA)
Cause: best guess practices from previous projects…
Solution: Align business with IT
E) Peter thinks he builds the best software, everybody is doing his own thing and not communicate with others (Too Many Cooks in The SOA)
Cause functionally identical services are developed
Solution: implements and enforce service governance, refractor reuse stop using bottom-up approach
F) Company is doing defining a process map and then create SOA, no reuse or process are working and then finally finished it is not solve anything (Top-down SOA anti-pattern)
Cause: attempt to make existing service oriented process
Solution: create service architecture separately
G) Jack builds service nobody is using (Nobody home anti-pattern)
Cause: building services no one or almost no one needs
Solution: Align IT and business, create registry of services, monitor services being use, implement policy that remove service that are not being used
H) Do it yourself kinda thing not use standards, create your own, not using WCF ect… (DIY Transport anti-pattern)
And so the scenarios go on and on (Splitting Hair Anti-Pattern, A Million Service All In a Row Anti-Pattern, Point-to-Point SOA Anti-Pattern, Uber Service Anti-Pattern, Loosey Goosey Anti-Pattern) about how SOA’s should not be started or set up. Basically this session comes down to do not start with building a SOA just for the sake of it or go on your own or as a unit without the business involved (ALIGN BUSINESS WITH IT!!!!). Use common sense and think before acting. There are a lot of articles, books and blogs out in there that will tell you this also. Some background about SOA Anti-patterns can be found in an article by Steve Jones.
Technorati: 
Microsoft SOA and BPM Conference 2007 
SOA 
SOA Anti-Patterns
