RE: [xml-dev] Don't Let Architecture Astronauts Scare You

["Paul Brown" <prb@fivesight.com>]

> From: Alaric Snell
> http://www.joelonsoftware.com/articles/fog0000000018.html
> "Remember that the architecture people are solving problems 
> that they think they can solve, not problems which are useful
> to solve."

There are five parts to solving a problem: (1) having a problem, (2) identifying a solvable subset with respect to time/complexity and total value, (3) inspiration, (4) creating a solution, (5) using it.  I don't see any research/academic experience on the Joel's resume, so I'm not surprised that he's ignorant of the process of doing new work.  We are at the tail end of 3 with respect to web services in that we have a good idea of the lemmas that will be necessary to prove the desired result: the packaging and (re)use of well-defined hunks of functionality in a distributed, heterogeneous environment (hardware/software/connectivity).

The inspiration is two-fold.  First, most of the integration problems left to solve are in the middle-tier businesses or on the departmental level within large businesses where the primary integration challenge is with external as opposed to internal entities and with custom as opposed to packaged applications and processes.  (Compare/contrast with EAI.)  Second, there is real value in forcing people to think *either* outside or inside of the box, where "the box" is a software service.  It is simply enforcement of the best-practice of interface-driven software development on a grand scale.

The business value of integration is exactly the same the high-level business value of any piece of software ever: machines are better (more effective, faster, etc.) at repetitive, specific work than people.

As for the business value of service-oriented systems from a software development/mainentnance perspective, I credit Ron Schmeltzer of ZapThink for a succinct graphical summation of the development/TCO picture for custom ground-up, packaged EAI/BPM, and service-oriented systems.  The non-graphical summary is that service-oriented systems win on TCO in the long-run because incremental environmental change can be satisfied by incremental change in the supporting systems.

Some parts of the web services stack fly in the face of reasonability because they ignore the fundamental requirements of doing business.  I'll throw out some flamebait: <bait>Automated service discovery and trust are an example of technical dreams and business realities at odds.</bait>  <bait>Distributed two-phase commit will not work.</bait>

> "Soap + WSDL may be the Hot New Thing, but it doesn't really
> let you do anything you couldn't do before using other
> technologies -- if you had a reason to."

And I could build a computer from vaccum tubes and program it by flipping switches with my nose.  Progress comes from layering and composition of ideas and techniques over time.

SOAP/WSDL is not the incremental advance that could represent a discontinous change in software development.  Service-oriented architecture and service-oriented thinking is.

SOAP/WSDL is not nearly enough -- those two specifications are merely the hypothesis on which a promising implementation of service-oriented concepts is predicated.  We could predicate it on something else, but XML/SOAP/WSDL is O(n) as good as anything else and already has a good level of support.  (In fact, I claim that the real problems are *independent of the protocol* up to sufficiency of representation, so there is zero value to bickering about it.)

We're at the point in the problem-solving lifecycle where we sit in a cafe with our collaborators to discuss ideas and counterexamples (REST, BPEL, BTP, WSCI, BPML, WS-S, WS-T, WS-C...) and hit the library to make sure that we're doing new work (CORBA, DCOM, EDI, mainframe-era TP, non-ACID transaction management ideas from the 1990's...).

So, feel free to point out that simplifying assumptions are vacuous but realize (1) that is the nature of an assumption and (2) the people with their eye on the big picture are well aware that there is a lot of work to do.

	-- Paul