2004.07.01

Harry posts about the new SOA Section at the Architecture Center. They have posted a position paper on SOA that is well worth the read. I read over it late last night/early this morning, and it is very interesting. It covers several interesting topics, including service-oriented analysis, coarsed grained entities, intermediaries and pipelines for cross-cutting architectural concerns and functional services for endpoints, etc. I will try to post some comments later.

2004.06.06

I was recently chatting with my good friend and sometimes business partner, Rhett. He and I went to college together. He studied math, I studied physics. Both of us ended up in computers, thanks in large part to our personal desire, another good friend, Russ McClelland, and his introduction to Luke Hohmann, who was working at the time at ObjectSpace in Dallas. We both started on the same day at ObjectSpace. Good times. Good times.

Now.

The other day, he was searching for the name of a mathematical concept. He thought it was a complete covering. I thought MathWorld would be the obvious place to look, but my math chops are far, far too rusty to interpret the closest match they came up.

I did a little digging this morning, and I struck gold with "Set Partition." In math, a set is a collection of things. A set partition is a set of subsets such that none of the subsets overlaps and the union of which is the original set.

I was very glad that Rhett brought the idea to mind, because it does provide an analogy for the ideal of service decomposition and rationalization in the enterprise. I believe that service-oriented architecture for the enterprise is a platform for the enterprise's future business process management platform. The business process is comprised of activities that are necessary to acheive the goal of the business process. These activities are a good first pass at scoping a service. The service defines the set of interactions necessary for the singular role involved in the activity to acheive it's subgoal. If two different activities require the same service, then you have an overlapping set, and the service should be partitioned to remove this overlap.
So the principle is:

The collection of services that span the enterprise should be a partitioning set with no overlapping operations.

I liken this principle to the concept of normalization in relational databases. Just as any database design should start off with a well-normalized data design and back down from that to address performance and complexity, enterprises should start with the partitioning set of services as the ideal SOA, and back down from there to address performance, scalability, availability, and so on.

Now.

That being said, reality is going to creep into this idealized world. For one, the data necessary to fullfill a service contract may span multiple applications and data stores, and in fact, may be geographically or temporally separated. You may need this bit of data from that application over there, and the work necessary to rationalize the architecture outweighs the benefit of having such a rationalization [in the near term]. Second, performance and scalability are going to require architectural techniques such as caching, federation, compression, clustering, load-balancing, load-sharing, and so on. These performance optimizations corrupt the ideal, but the evils are necessary. Be pragmatic, and be continuously improving the architecture by working toward the ideal.

As Dave Thomas would probably say, and Thom [or his computer] once said, "Pragmatism, not idealism."

2004.05.30

It has been a while since I ran across this one. SearchWebServices has a BPEL Learning Guide that pulls together relevant products, samples, presentations, blogs, and so on for BPEL. It is almost a year old, so I hope they do an update sometime soon. If you are interested in BPEL, this is a good place to start.

One memorable excerpt from the text that serves as a cautionary tales for those automating business processes.

Another key characteristic of a modern Business Process Definition language should be its
inability--yes, inability-- to describe a business process from A to Z with all explicit exception
paths: I was talking to a large company’s chief architect at a conference last November. His
conclusions were stunning: his company had just gone through a complete mapping of all their
processes. I said, ”That must be a great asset. You are ready for BPM.” “Actually, no,” he
answered. They had come to the conclusion that because of the way they had modeled the
processes, the resulting definitions were far too complex and, consequently, brittle. Nobody
could comprehend the impact of any changes, let alone move the enterprise architecture to a
BPMS.