WOA wasn't important to me last week

I spent last week working with a couple of my enterprise customers. The time was focused around the Shared Service Center (formerly known as the SOA Center). Here are the big issues that we worked on:

- Improving the help desk for production implementation problems related to shared services

- Improving the ability to perform root-cause analysis for service exceptions

- Getting funding to pay for a better staging environment

- Changing the way we engage with large I.T. programs so that they don't get bombarded by 5 different CoE's

- Changing our 'service discovery' process to make it easier to project ROI for shared services

- Identifying a new set of processes that support organizations will have to follow if the business application requires high availability: "Gold, Silver, Bronze SLA"

- Modified and communicated changes to our "Service Architecture Document" in order to provide consistency in documentation detail

In my world, SOA refers to the organizational politics necessary for an I.T. group to perform their job efficiently.

SOA has evolved from 'web services' to 'an architectural style' to 'an enterprise architecture framework' to 'a specialized I.T. lifecycle and supporting organizational design' - to 'all of the above'.

If WOA wants to encompass the aforementioned activities - I want in. Until then, WOA is just a cool thing for analysts, press and marketers to talk about. Debating the HTTP verbs might seem like 'real architecture' to some but I am genuinely concerned that a 'shiny object of misdirection' is taking our eye off of the real problems.

WOA wasn't important to me last week and it won't be next week.

Is Your Programming Paradigm HOT or NOT?

Is your programming paradigm Hot or Not????

Well, you might not agree with my observations, but here's what I'm seeing:



Real Time
Let's start at the bottom of the stack: Real Time. Due to an increase in consumer devices, wireless networks, etc. we are seeing additional requirements for new low level programming. I wouldn't call it 'explosive demand', but the area does seem to be growing.

3GL
Surely, I'll get beat up here... but that's life. I am of the opinion that the amount of 'straight 3GL' coding continues to decrease. With the maturity of other paradigms people don't need to do as much old fashion hand coding as they used to. The bulk of this work has moved up a layer in the stack (3.5 GL / App Dev).

Application Development
These days more and more people write their applications on top of some stack (Java EE, open source frameworks, .Net, etc. Typically, they are using a combination of a 3GL with DSL extensions (JSP, ASP, etc.) In recent years, we saw the big application platforms (ERP, CRM, etc.) get (mostly) migrated to one of the aforementioned stacks.

Package App Customizations
The ERP, CRM and other packaged app vendors have increased their market share (as a percent of the enterprise footprint). This has moved traditional application development to more of a 'customization' model. Power users or application configurators use a workbench to add fields to a screen, modify reports, grant user access and other basic operations. New modules or complex changes are still typically done with more of an Application Development model except that the developer is expected to use the 'business framework' that comes with the system.

Platform as a Service
Although PaaS remains in it's infancy, it is growing at a rapid pace. From a language perspective, we seem to be seeing three options:
- The first option is to create a new language (like Apex) that is PaaS friendly (multi-tenant, sandbox, governed, etc.)
- The second option is to take a current programming language and throw exceptions with people call potentially harmful features (like Google did with their Python impl)
- The third option is to let the developer program in any language they want and let them deploy it on a VM. Here, developers are typically charged for CPU time and the VM is the sandbox, thus they don't really care what you do.


In general, we're seeing more and more development move up the stack. On occasion, we have to rework the stack, so we drop back down into lower layers and then work our way back up. Ultimately, the stacks get figured out and dollars (and work) flow into the layer of the stack that is most productive.

Why Enterprise Architecture is a Joke

Enterprise Architecture is a joke. And I don't say that lightly. My goal isn't to pick fights with enterprise architects - quite the contrary. I've got huge bets on EA - my time - my career - my money. My goal is to improve it.

Anyone who has been in our industry for any period of time has heard the jokes about EA... "EA's are the guys who program in PowerPoint." Despite valiant efforts to mature the discipline by groups like IASA, the OMB, The Open Group, The Zachman Institute as well as individuals like Ambler, the discipline remains fragmented and often unproductive.

In my opinion, there are several reasons why the discipline has not matured more quickly:

1. Zachman pioneered, than stagnated. I believe that the single largest reason that EA is a joke can be linked back to the pioneer. This pains me to say, but many in our industry were patiently waiting for better stuff to come from Zachman and it just didn't happen.

2. Bad Application Architects got promoted to be bad Enterprise Architects. Although this isn't a universal truth, I've witnessed my fair share of it. Those who can't architect do PowerPoint.

3. Silo Organizations promote Silo Funding. Many EA's never had a chance. They live in organizations that fund everything according to business silo's. Then, the EA is expected to bridge the silos with nickle and dime funding. Their inability to perform Herculean change (multi-channel, master data, cross-organizational BPM, master SOA services) has many of them designated as cops with no gun, just a good flashlight.

4. The Tooling Sucks. Modern EA tooling is complete pile of crap. It is designed and written by a generation who is out of touch with the needs of modern I.T. groups.

5. Unconnected Models. Expanding on #4, our models (and tools) do not sufficiently flow from one model to the next. Software development is often explained as a series of model transformations from concept to design to construction, where each stage adds additional fidelity. We currently have a huge hole between EA and the downstream constituents.

Today's enterprise architects have been given the equivalent tooling as programmers in the 1960's. I feel like I'm bashing developers who were handed punch-cards, told to program in assembler and then scolded for their lack of productivity.

The good news is that most EA's are providing significant value despite their handicaps. The great news is that smart people have identified the problem and are actively working on the solution.

Key WOA Concepts

Nick Gall clarifies a few key concepts of web architecture around the URI:

---

On Thu, May 1, 2008 at 9:09 AM, Gregg Wonderly wrote:
> I think that there are two distinct uses of URIs. There are URIs that are never
> intended to be typed by people (or at least don't need to be), and there are
> URIs that only people will type.

I couldn't disagree more strongly. We should be doing everything in our power to eliminate the distinction between human understandable and machine understandable interfaces. Thus suggesting URIs for humans be different from URIs for machines is a step in the wrong direction.

There are three important reasons to make interfaces for humans and machines as similar as possible:

Debugging: you never know when a person needs to look under the covers to see what's going wrong. Why do you think the Internet and Web emphasize ASCII text-based protocols even though they are far less efficient than binary and will rarely be seen by most people

"Show source": human readable interfaces generally and human readable URLs specifically make it easier for developers (and even occasional scripters like me) to learn from one another

Serendipity: TBL and RTF emphasize that the web is designed/engineering for serendipity. Thus you never know (and shouldn't try to guess) which URIs people will or won't want to use directly.

Our goal should be to minimize the distance between UI and API. Assuming that people will see and use all URIs is a big step in that direction.
-- Nick

---

Spot on, Nick! I love the notion of 'minimizing the distance between UI and API'...

See: http://tech.groups.yahoo.com/group/service-orientated-architecture/message/10245

SOA Acquisitions List

I've updated the list of SOA Acquisitions:
http://www.momentumsi.com/SOA_Acquisitions.html


The new transactions were:
- Cape Clear to WorkDay
- LogicLibrary to SOA Software

I also added Sonoa Systems as a new target.

SOA Software Acquires LogicLibrary

Today, SOA Software announced the acquisition of LogicLibrary, a leading provider of software asset & reuse management. The terms of the acquisition were not disclosed.

SOA Software is best know for their integrated SOA Governance platform. The key word here being "integrated". SOA Software has both design time and run time platforms that share policy information seamlessly. For anyone who has felt the pain of integrating stand-alone registries and repositories with policy enforcement points, mediation points and web service management tools, you'll appreciate the beauty of having an integrated solution.

SOA Software is realizing a grand vision: unified governance and management of SOA across the Enterprise Lifecycle. The acquisition of LogicLibrary will give them significant depth in managing design and development assets. LogicLibrary has deep integration in IDE's and SCM's. In addition, it extends their reach into enterprise architecture by capturing reference architectures and development policies.

Through this acquisition, SOA Software is demonstrating the depth and breadth of their vision. At this point, it is unclear if the competition fails to see the vision or merely fails to execute on the vision. Regardless, SOA Software has raised the bar (again) before many of the competitors have caught up with the last bar-raising that they performed.

SOA and WOA Comparison

Several peopled (too many to name) have recently compared SOA and WOA. Unfortunately, virtually all of the comparisons are really more of an analysis of 'Web Services vs. REST/POX/RSS/AJAX'. For those of us who 'do SOA' for a living, this drives us crazy. We fought for years to get people to quit thinking about SOA and Web Services as being the same thing. Now we have both analysts and press undoing the progress that we had made. Ugh.

Ok guys - steal this:



Please consider extending this little framework as a way to do proper comparisons. If you feel the need to add rows, I encourage it. If you don't like the contents of a cell - change it, but for the love of God, please quit comparing Web Services and REST and calling it "SOA versus WOA".


As for the cute one liners: "WOA is the SOA that works"... "SOA is the internal cloud" :-) You guys kill me. This is excellent nonsensical dribble.

However, the idea of 'building your WOA on your SOA' caught my attention. My deciphering of this statement is "use the EA & Governance practices to ensure business alignment, proper sharing and quality while also using lightweight protocols to drive barrier-free consumption and composition." Assuming this is what was meant... I'd agree! Perhaps another post on this subject...

Targeted Markets for PaaS Providers

Yesterday I wrote that the Google PaaS offering was not suited for the Enterprise primarily due to the language of choice (Python). This had me scratching my head. The people at Google aren't stupid - they know where the money is... why would they make this decision. And then it occurred to me.

Google is betting that the Enterprise will spend more money on SaaS than they will on PaaS. As Gartner said,

“Ease of use, rapid deployment, limited upfront investment in capital and staffing, plus a reduction in software management responsibility all make SaaS a desirable alternative to many on-premises solutions, and they will continue to act as drivers of growth.”

Google has made a bet that they can lure start up companies and next generation developers to their platform by choosing a dynamic language that facilitates mash-ups. And by doing this they will be the preferred platform for many next generation SaaS companies. But which ones?

The Google platform doesn't really offer any 'enterprise grade' functions. What it does offer is simple access to the Google world of social networking, ads, etc. In its current form the platform is best suited as a platform to enable SaaS for large audience applications (like social networking).

PaaS providers are still trying to figure out their target markets. Companies like Coghead are chasing the SMB market, hoping to attract customers who want to avoid setting up their own hardware and paying expensive programmers. SalesForce is clearly going after the enterprise ISV's. We're quickly getting to the point where each of these players will have to announce their target market to the world. The 'one size fits all' model won't last.

Enterprise PaaS

The recent PaaS announcements from Google and Amazon have grabbed the attention of the enterprise customer. Utility computing, clouds, pre-integrated platforms and business services are all sexy topics. But these same companies also realize that there are huge hurdles to adopting these concepts. They're big ships - and they don't turn easily.

How do I get PaaS?
Companies will ask how they can take advantage of this incredibly disruptive computing phase. I'm in agreement with Michael Nygard who feels that "everyone will want one". See:
http://www.michaelnygard.com/blog/2008/02/a_cloud_for_everyone_1.html

Michael discusses the typical progression of high tech products:

1. Very expensive. Only a few exist in the world. They are heavily time-shared, and usually oversubscribed.
   
2. Within the reach of institutions and corporations, but not individuals. The organization wants to maximize utilization.
   
3. Corporations own many, as productivity enhancers, some wealthy or forward-looking individuals own one. Families time share theirs.
   
4. Virtually everyone has one. To lack one is to fall behind. No longer a competitive advantage, the lack of the technology puts one at a disadvantage.
   
5. Invisibility. Most people have or use several, but are not aware of it.

Michael goes on to say that he feels that Cloud Computing is currently at Stage 1 but it won't be long before large enterprises want their own. I'd argue that several enterprises already have their own cloud or utility computing environment. However, not many of them have a pre-integrated, platform sitting on the cloud ready for I.T. customers to use. There's a big difference between virtualized hardware and offering a software computing platform.

If you need to store data using the Amazon or Google offering, the options are clear. They have a couple services available - just grab the one you want and use it. To accomplish the same task in your average enterprise I.T. shop, you'd call up your enterprise architect, get a copy of the Technical Reference Model, identify the applicable elements, and then go to an infrastructure group to try and get them loaded so that you can test to see if they will work for their project. Ugh!

It will take a rebellion for enterprise I.T. to change but this act might be sooner than you think. Developers are already using Amazon and will quickly be messing with Google. They'll be telling management that they want to use this stuff because it is quick and easy to get going. (It's the same reason why people wanted off the mainframe and eventually ignited the client/server era).

In my opinion, Enterprise PaaS is inevitable. Organizations will not be able to switch to a purely outsourced model but will look for hybrid solutions, including creating their own PaaS. The PaaS model of the future will have to embrace multiple PaaS vendors (dare I say federated Paas). But, of course, the major infrastructure vendors will offer a PaaS-in-a-Box that mimics their own hosted model (think Oracle/BEA, IBM, SAP, Microsoft).

Who will win?
It's too early to say. Early indications are that it isn't Google. Their decision to go "Python-Only" is an extremely strong statement. Personally, I can't think of a single enterprise that considers Python part of their strategic computing platform (nor do they have armies of trained Python developers). The winner should be IBM, but they tend to think everything is a consulting problem. SAP isn't exactly known for their technology... Amazon has done some pretty cool stuff. Normally I would have discounted them, but who knows? Salesforce has an early lead but they don't have much of a footprint in the enterprise. Oracle/BEA and Microsoft both have interesting prospects in this space. If I were a betting man (which I am), I'd throw my chips on these guys.

Microsoft's 10 Year Old SOA Strategy

If you aren't familiar with Microsoft's SOA Strategy, I'll sum it up for you:

BizTalk + WCF + Vaporware = SOA

Yesterday, I attended a Microsoft SOA event to get briefed on their strategy. To say the least, I found myself disappointed. After 3 hours of showing slides and demo's I finally concluded that Microsoft's SOA efforts to date have been a failure.

At the heart of their strategy is BizTalk. It's the one SKU that they can actually sell that is related to SOA. And if you listen to Microsoft, you'll be told that virtually all SOA paths lead to BizTalk. If memory serves me, BizTalk was released in Beta in 1998 and became generally available in December of 2000. This isn't exactly a new SOA product.

Windows Communication Foundation (WCF) is a fairly new component that was introduced in the last couple years as a pluggable framework to enable the Web service protocols.

The third part of the equation is Oslo. This mythical beast is basically the next version of a bunch of products which will help build on the vision of Software Factories. Oslo will not be 'released' as a unit, but rather each individual product will get released on its own timeline.

Robert Wahbe, the Microsoft executive in charge of the Connected Systems vision, must either be sitting on some elaborate game plan which involves a well-kept secret to acquire some actual SOA products, or he's in serious trouble. It is clear that Microsoft no longer has the killer instinct that it had years ago. But even then, the lack of results in this area must stand out like a sore thumb.

JBoGS and PoPS

I noticed that Nick Malik and others have stepped up the call to stamp out "JBoWS" (Just a Bunch of Web Services). Not me. After some soul searching, I've determined that JBoWs is the natural first step that an organization takes on the path to service orientation. It's not that it's right or wrong, it's just a stepping stone.

Since the industry likes buzzwords and acronyms, I'll add to the mix. It has been my observation that the next step is to take the 'wild' services and govern them. I've been calling this, 'JBoGS' or (Just a Bunch of Governed Services).


JBoGs is the natural extension of JBoWS. Services continue to be funded in a project (and often silo manner) but are designed, built and operated according to modern governance concepts. With JBoGS, a company will most likely have some type of registry / repository solution, lifecycle governance and runtime management infrastructure and practices in place.

This is an excellent step after JBoWS and it isn't too hard. People like to say, "You can't buy SOA". Well, that's true... but for the most part you can buy JBoGS. Moving from JBoWS to JBoGS requires some infrastructure, a SOA lifecycle and governance practices, all of which can be bought from vendors like MomentumSI, IBM, SOA Software and Progress.

JBoGs might sound like a derogatory term, but it isn't. I applaud the companies that are getting experience in building and governing services. But let's get real, that's not "SOA" - it's another stepping stone.

I'm throwing out another term: "Patches of Planned Services" (PoPS). Here, we're aligning the enterprise architecture with the Services. In essence, we're performing urban planning for communities of services. This is the 'planning' view of SOA typically thought of as a top-down approach. Notice that I used the word 'patches'; I didn't use a term like "Enterprise-Wide Planned Services" - the fact is, no one (who keeps their job) will do this across the enterprise. We'll cut up domains (or patches) and plan one area at a time.

The Evolution
We have several customers who are at the JBoGS stage right now. Most companies want to get their 'wild services' governed before they move to more ambitious goals. 2008 appears to be the start of the PoPS era. Companies that have matured their JBoGS are now looking for SOA to support business critical processes like order-to-cash. This means that they now have to roll out multiple services (not 1 or 2, like in JBoGS). This is the driving force for creating planned communities of services which are typically aligned to business processes. Finally, eh?

You'll notice that in the diagram above I imply that there is something after PoPS. There is - I know it, but the future remains cloudy. In the past, I've predicted things like: organizational alignment to SOA, alignment to business strategy, external service networks, and a host of other great ideas. Bottom line is that I don't know, and most likely no one else does either. Don't worry about it. For now, keep working on the other stepping stones!!!

SOA Acquisitions (updated)

I've updated the list...

http://www.momentumsi.com/SOA_Acquisitions.html

I have 16 companies still listed in the "producer" category (target companies). I'm guessing we'll see two more go in 90 days.

Facebook Terms

You probably saw where Scoble was temporarily suspended from Facebook. It made me go back and look at their legal terms. The one that threw me for a loop was:

You can not...
"use automated scripts to collect information from or otherwise interact with the Service or the Site;"

I must be missing something. How can a software platform like Facebook not allow "automated scripts to... interact with the Service or the Site"??

Just like moving from ISV to SaaS requires a change in attitude, so does the move from a 'web application' to a 'platform'.

Enterprise SaaS Must Stay Up

This is the kind of thing that gives me the hebejebees:

---

---

As soon as you start putting "production data" in a system, it must stay up. In this case, Spock clearly identifies that the system isn't 'Production', but is in 'Beta'. The difference between Beta and Production in SaaS is really just one of expectations. If Spock were to drop all of our data we'd be pretty upset; in my book that looks more like production than beta.

I want a SaaS provider to prove to me that they know how to add features without taking the system down. That is, even in beta, I expect the system to stay up. I expect that they'll do a behind the scenes data migration to make things right.

Balanced Views of SOA

I hate adding new terms, but I think we're hurting ourselves by constantly overloading the term SOA. IMHO, we would be better off if we formalized the "The Balanced Views of SOA". By "views" I'm referring to the old "4+1" type concept, see: http://tinyurl.com/2qed42 or http://tinyurl.com/2pmpmt

Premise: SOA is a collection of techniques which can be understood by observing a solution set from several different vantage points, or Views. The views can be divided into three primary categories:
1. Service Portfolio Views
2. Individual Service Views
3. Consumer-Service Views

The Service Portfolio Views focus on treating services as business assets residing in a portfolio. The role that most likely uses this view is the Enterprise Architect. Example views might include:
Business Priority View, Service Pipeline View, Process View, Portfolio Investment View, Consolidation/Rationalization View, Information Model, etc. These views help in the prioritization and planning process and to keep things organized (think Metropolis).

Individual Service Views focus on describing a single service. This view is most likely used by analysts, developers and testers to create a new service. Example views might include: Service Interface View, Service-Component View, Service-Deployment View, etc. Note that these views most closely resemble the traditional 4+1 concepts.

Consumer-Service Views focus on describing the relationship between services and the consumers (at plan-time, design-time, provision-time and run-time). The roles that would leverage these views include SOA administrators, product managers and configuration managers. Example views might include: Consumer/Service Dependency View, Policy Views, SLA Views, etc. These views help people to keep composite solutions from breaking due to incompatible versions, capacity problems, etc.

================

The power of SOA is that it is the first model that crosses these three areas. It has been my observation that the companies that balance these three broad views of SOA are the most successful.

Is SOA "predominantly an enterprise architectural style"? Well, it sure is if you're an enterprise architect! I understand that the evangelists in this group want to push the importance of the Service Portfolio Views. But, I'm going to pull a "Mark Baker" and become religious about the "Balanced Views of SOA" - that's my New Year's Resolution :-)

=== This is a repost from the Yahoo SOA Group

Top 100 SOA Predictions for 2008

Here are my top 100 predictions for the SOA community:
#1 - The incredible value of SaaS is realized and buyers want in
#2 - The buyers realize they need enterprise SOA to effectively pull off SaaS

#3 - #100 are irrelevant.

Updating the SOA Scorecard: SCA Services

For almost 5 years now, we've been advising clients on their SOA scorecard. In the early days of SOA adoption, customers often measure their success by 'releasing services'. This is a great metric for beginners. As the program progresses the shift moves to their utilization. Services are only valuable if they are actually used. From this perspective, we recommend looking at the consumer-to-service ratio as the primary test. The secondary test looks at message counts; that is, are the services actually being called.

Unfortunately, neither of these tests actually look at the value that software brings to the business. We've been encouraging our customers to spend more time looking at the business proposition that the service reflects. Business strategy is based on those activities and assets which are considered 'Sustainable Competitive Advantages' or SCA. These are the things that allows a company to be successful in their business year after year. Strategist have various means of identifying and describing the SCA's. Moore's 'core vs. context', and 'value chains' are often applied to help an organization understand where they need to be competitive.

Many organizations have moved beyond SOA pilots and now have scores of services running in production. However, many of these same organizations do not have the truly important services available. The fixation to increase the number of services often overrides the commonsense notion of providing business-valued services.

I've been encouraging customers to look at the three C's of business: Customers, Commerce and Channel. All three of these domains are typically excellent candidate for service enablement with high business value. Obviously, there are other domains that might be more important for your business which should be prioritized higher. The point is that you need to create a priority list of services based on the business that you're in. Service enabling non-valued added aspects of the business might look good on an old fashion SOA scorecard, but it no longer passes the smell test!

Amazon SimpleDB Launches

Amazon Web Services has launched their latest offering, "Amazon SimpleDB":

"Amazon SimpleDB provides a simple web services interface to create and store multiple data sets, query your data easily, and return the results."

SimpleDB sits on top of their hosted computing layer (EC2), proving an integrated cost model for those who are already EC2 customers. From a developer perspective, SimpleDB looks more like a big 'hashtable in the cloud' than a traditional RDBMS. The database is not relational and doesn't support SQL for data definition or data manipulation (DDL/DML). Instead, they have chosen to use a 'schemaless' system for data definition (name/value pairs) and for data manipulation (insert, update, delete) they have chosen to use simple REST style verbs (PUT, GET, DELETE, CREATE, QUERY).

The service is specifically designed for small payloads (not big BLOBS). For larger files, they recommend that you use AWS S3. They also recommend that you only run 'real time queries'. In fact, query execution time is limited to 5 seconds which prevent users from running very large requests. Although some might disagree with this decision, I'm a full supporter of this model. However, organizations will still need to perform two vital operations: 1. Export all data 2. Perform complex BI style queries. It is currently not clear how these items will be supported. The system doesn't seem to support the notion of 'change data capture' which would allow changed records to be sent to a separate analytics engine, nor am I finding a mechanism to easily load or unload a data store which would be a real issue if you time out after 5 seconds...

SimpleDB is in beta which implies that features have been frozen while bugs are ironed out. My primary concern is that they may have accidentally designed "TooSimpleDB". I love the idea of keeping it simple, but they may have overdone it.

Replace SOA Governance with Expertise?

Owen Pettiford takes a swipe at SOA Governance:

The reasons for this conclusion stems from the drug induced high I was on just after the operation when it occurred to me that I had not just survived the biggest operation of my life because someone "governed" it well (sure it was important that the right people were there and that they had the right tools) – I survived because I had EXPERTS working on me who had TRAINED for YEARS.

Well, I partially agree with Owen. Let's not forget that much of the doctors training was on the best practices (sanitary environment, cross-checks, standard procedures, etc.)

SOA Governance isn't a magic bullet. But if it is implemented correctly it will prevent (some) people from doing (some) stupid stuff (some) of the time. And I'm ok with that.

He goes on to say:

Enterprise SOA will be achieved through expertise, passion and shared vision.

You could replace "Enterprise SOA" with just about anything and you'd be correct. The problem is that large organizations are filled with people who are non-experts who don't have passion and lack shared vision. It's that simple. Good SOA Governance makes the assumption that statistically, the average person in your organization is, well, average!

See:
http://pettiford.blogspot.com/2007/04/governance-is-not-answer.html

SDLC and Work Patterns

Nick Malick stumbled upon a real common misconception. In a recent blog post he mentioned that a SOA SDLC must be more iterative:

First, a comparison: Waterfall looks like this:
Waterfall: Plan --> Envision --> Design --> Develop & Test --> Deploy
Agile: Plan --> Sprint --> Sprint --> (occasionally) Deploy --> Sprint --> Deploy

A SOA SDLC looks more like this:

Plan --> Sprint (Process and User Experience) --> Sprint (Process & Services) --> Deploy --> Sprint (P&UX) --> Sprint (P&S) --> Deploy

What Nick is describing is the use of Work Patterns within an SDLC. It is common for people to accidentally combine these two distinct concepts.

Here's the difference...
- SDLC focuses on the phases, activities and artifacts
- Work Patterns focus on the selection of phases, iterations and workflows

It's hard to describe but take a look at this and I think you'll see what I mean:
http://www.usdoj.gov/jmd/irm/lifecycle/table.htm

See section 13.2 for an example. I do agree that running a serial SOA SDLC is not a good thing. I was glad to see Nick mention User Experience. Usually, we'll talk about the Consumer SDLC and aligning it with the Service SDLC.

Good Stuff!