Train-Wreck Management

Wow, this is a well organized essay by Mary Poppendieck.

Train-Wreck Management

The essay explains a bit about how a train accident in 1841 leads to the Prussian army becoming a model for today's organization chart!

Here's a quote that might make you look around your environment and feel an eary sense of historical dread...

Problems are caused by people who don't do their job well, so finding someone to blame is the first step to correcting problems.

I recommend anything on the website, and the books they've authored as well.

What I'm Reading

I try not to post my own blog entries that just point to other blog entries - unless I have something to say that adds to the original.

On my blog page I have a readling list widget, but here is a link in case anyone is interested and hadn't noticed it before:

What I'm Reading

SOA Integration: RPC and Constraints

DevHawk responded to my hard work post. Most important responses first.

Beer.

Let's have a beer together someday and you can make up your own mind! I try to have formed my own opinion on some topic, but don't take my view so imortantly that other people are wrong. The back-and-forth of ideas during a technical discussion is a fun way to spend a few hours.

DevHawk said:

I might be going out on a limb here, I'll bet the core of John's problem with SOA is how toolkits like WCF all but force you to build RPC style services that can easily be modeled as method calls. That's certainly one of my problems with SOA.

You're right, that is something that causes me grief. When I see a WSDL with endless request/response operations I first think:

1. That's going to cause some scalability/extensibility/versioning problems.
2. It would be easier to build this design in CORBA[1]
   

Also, your quoting from Tim Ewald was spot on. 10 years of SOAP and most systems just are just strongly coupled RPC.

Also, I agree that all the tools (and examples and sample code and ...) nearly universally pushes a view of Web Services that is really just RPC.

[Note: I just switched from SOA to SOAP to WS. I'm trying to formulate another post that will articulate what I think distinguishes those from each other. Right now I'm just rambling...]

There is one other thing about SOA that drives me bonkers. I'm hooked on architecture by constraint - limit the system in certain key areas to promote certain use and benefits. The four tenets of SOA don't do it to me at all.

Tenet 1: Boundaries are Explicit
(Sure, but isn't everything? Ok, so SQL based integration strategies don't fall into this category. How do I build a good boundary? What will version better? What has a lower barrier to mashup/integration?)

Tenet 2: Services are Autonomous
(Right. This is a great goal, but provides no guidance or boundaries to achieve it.)

Tenet 3: Services share schema and contract, not class
(So do all of my OO programs with interface and classes. What is different from OO design that makes SOA something else?)

Tenet 4: Service compatibility is based upon policy
(This is a good start: the types and scope of policy can shape an architecture. The policies are the constraints in a system. There not really defined though, just a statement that they should be there.)

Ah, I feel better getting that out.

I asked "Where are the SOA Mashups?" and DevHawk responded:

That's easy! They're inside the firewall where you can't see them! ;)

I'm so glad I procrastinated writing this because now I can just refer to this InfoQ article. Gregor Hohpe's comment is pretty much my definition of mashup.
The project you describe is an integration, but multi-schema, star-integration with a huge effort doesn't fit my definition of mashup.

[1] Yes, I'm serious! I used OmniORB with Python to build systems for about 2 years. I think CORBA with C++ might be more work than most WSDL based systems, but this was a very efficient development environment for strongly typed interfaces.

REST, Serendipity, and Hard Work

DevHawk found my comment on the "SOA in the Real World" book. DevHawk writes:

Yeah, I'd rather not have to think about integration before hand either. On the other hand, I want integration that actually works. It sounds like John H. is suggesting here that REST somehow eliminates the need to consider integration up front. It doesn't.

I didn't mean to imply that building RESTful system would lead to magical integration without any hard work. I can see how that came across in my post, and I guess I got the reaction I asked for ;)

Let me try again...

I want to build systems using tools, techniques, designs, and architectures that maximize my investment in effort and work to produce value. If I put one unit of effort into building something, and I get more (or many more) than one unit of value for my effort, then I'm working in a high-leverage environment.

REST uses constraints to encourage integration. If I pay the cost of building a RESTful system (uniform interface, single naming system, resource-based design, representation transfer, ...) then any other system can leverage my system - for at least some minimum degree of use. That is serendipity. This is the fundamental reason that mashups on the web can exist.

Where are the SOA mashups?

I think related to that question, DevHawk further says:

...enterprises aren't interested in unexpected or serendipitous reuse. They want their reuse to be systematic and predictable.

I think we disagree here. Enterprises think they want systematic and predictable systems, but I suspect this is the equivalent of developers wishing distributed object systems worked despite latency and partial failures. I'm not suggesting enterprise systems should set "not predictable" as a goal, but I do think that trying to make things too predictable often leads to fragile systems.

Disclaimer: I've only read the first chapter of the book.

Here are some more quotes.

This one leads into the first chapter:

“SOAs are like snowflakes – no two are alike.”
- David Linthicum
Consultant

I'm assuming it's included not as a supporting opinion, but the first chapter doesn't do much to disprove it! Obviously if this is true then every bit of integration will have to be fought for, bit by little tiny bit. When everything is different there are no high-leverage environments for integration.

This next quote is why I don't feel (at least the first chapter) does much to discount the previous quote:

For the purposes of this book, we will define SOA as:
A loosely-coupled architecture designed to meet the business needs of the organization.

That loosely-coupled looks good. Loosely-coupled systems should be easier to integrate (as opposed to highly-coupled systems anyway).

How does an SOA become loosely-coupled? The four tenets of services or the summarized SOA process (expose, compose, consume) listed in the first chapter don't tell me anything yet.

Building systems is hard, building RESTful systems is also hard. The question of serendipity is this:

If I build an application with constraint A instead of constrain B, will I get more integration and value elsewhere the total system?

The constraints that define REST, and inspire the Web, have a significant track record for enabling integration. Are they the only constraints that can lead to value? No, absolutely not.

Can some of the constraints of REST be applied to SOA? Absolutely. I think an asynchronous, message-passing architecture with a uniform interface would be astoundingly interesting! I'm not the only one: see MEST, AMPQ, and Erlang.