SOA: Making the Paradigm Shift Part 1 of N

Introduction and Context

I have been giving an SOA talk, in various forms for several years, where I concentrate on various themes. For the benefit of many who have not gone to such talks, as well as for others, I always wanted to start a written series based on these talks. Since, I can't sleep tonight, this is Part 1.

In this series, I would like to discuss a lot of concepts that are not tied to any particular technology stack whatsoever. SOA requires a Paradigm Shift in thinking and I am very interested in getting people there. Chief, among these ideas is that People Drive Business Outcomes, not technology. Thus, there are people and business drivers for SOA. Doing SOA for the sake of doing SOA or for some technology exercise is very likely to fail. We will use Microsoft Infrastructure Optimization (IO) to measure, yes measure the value of the business enablers in the context of a maturity model. Rather than being vague guidelines, we will instead have ways to measure business drivers and then the services that meet them into the context of creating a more dynamic IT.

However, as we delve into implementation, I will need to use a stack, and I will use Indigo. Yes, say it with me. The W-C-F is silent. It's pronounced "Indigo." Examples will be all with .NET Framework 3.5 SP1 Beta 1 and Visual Studio 2008 SP1 Beta 1. At that point, I envision the series moving more into how Indigo is a framework or platform for creating SOA. As WCF is THE one Microsoft distributed stack to rule them all (among the Microsoft stacks), I also have selfish reasons to stop the use, and promotion of non-SOA stacks like ASMX in a lot of the ASP.NET books and blogs I see and the non-SOA RPC-centric systems it creates.

We will talk about Microsoft Real World SOA and Expose-Compose-Consume. In that area, I would like to especially talk about Workflow and Workflow/Durable Services in 3.5.

We will spent a lot of time talking about Service Patterns and Message Exchange Patterns.

So, here is a tentative Outline. Tell me what you think, would like to see, etc.

Tentative Outline

1. Symptoms of a Problem, Diagnosis and Why SOA?
2. Dynamic IT to Support the Agile Business and Business Benefits of SOA
3. What is SOA? The Many Definitions, a Working Definition, the Four Tenants
4. What is a Service?
5. Service Architectural Patterns
6. The Current State of SOA and How to Make the Paradigm Shift
7. Microsoft Approach to SOA
8. Microsoft IO, App Plat IO, ESOMM Maturity Model and how Service Enablement Fits In
9. Real World SOA and the "Middle-Out" Approach
10. Short Term vs. Long-Term
11. Introduction of the ESB as Long-Term A in SOA
12. Introduction to WCF: Architecture and the "ABCs" of Indigo
13. WCF: Bindings, Endpoints, and Hosting
14. WCF: Contracts
15. WCF: Behaviors and the Channel Stack
16. Message Exchange Patterns and Greghor Hohpe EAI Patterns
17. Introduction to BizTalk in context of Patterns
18. BizTalk and It's Role in an SOA
19. Asynchronous Messaging and Event-Driven Architectures
20. Publish-Subscribe and Router Design Patterns
21. Introduction to Neuron as WCF/SOA Enabler and "BizTalk and Neuron: Better Together"
22. Neuron ESB and Publish-Subscribe, Mediation, Routing, etc.
23. REST in Indigo 3.5
24. Windows Workflow Introduction
25. Workflow Services, Durable Services in 3.5

Symptoms of a Problem

So, what are some of the symptoms in the industry driving SOA? Well, there are a bunch of them, but they fundamentally stem from a mismatch between organizational needs and technical infrastructure. IT has become a conversation of "why we can't." What once was an Enabler has become a Barrier. So many companies have treated IT as a cost center and simply outsourced it. We see technology at home way before IT at work. It begins to feel like Paleontology.

What has happened? Simply, with 80% or more of the average IT budget spent on maintenance, the CIO can’t redeploy budget and resources to shift IT to strategic business asset. Less than 20% is spent on Business Results and New Value. Meanwhile, the poor CIO is getting hammered with SOX/Regulatory Compliance, Cost Reduction efforts, technology changes, security, keeping the islands and masses of legacy systems running.

Diagnosis

The diagnosis is that there is a misalignment. Us Geeks think in the world of the abstract (think OO) and business people are thinking in Capabilities. People focus on process. hide behind requirements and become fearful of change. We have spent billions creating Silos and Monoliths, and billions more with EAI systems with misguided investments of point-to-point silo stitching. We then end up with two systems tightly integrated. Big step forward. Not. 

The bottom line is that IT must become more dynamic to support the business in an agile fashion.

That is the subject of Part 2.