Blog Posts from January 2004 (page 1 of 7)

SOA vs. OO in Business Process

Ram blogs on abstraction and Simon blogs on intimacy of SOA vs. OO. Here are my two cents on control and process of SOA vs. OO.

I came across this blog entry by Michael Santos who wants to stop the hype about web services. I forwarded his post to my entire team. I feel that it represents the typical old-school, 20th-century, industrial-revolution, application-centric mindset that we encounter regularly when discussing XML Web Services. He talks a lot about using binary protocols instead of XML because of performance. What’s interesting is that his over-focus on performance leads down a path to tight coupling (or intimacy as Simon called it).

So, maybe you intend to keep your systems loosely coupled. I understand that. But let me ask you…Should they be loosely coupled in first place? Sometimes two systems are so tightly coupled that they should be just one system, to begin with. This usually happens in big companies, where political reasons force two groups to buy two solutions from two different vendors to solve two parts of the same indivisible problem that cannot be addressed separately. [Michael Santos : Stop the hype about webservices!]

The thing is, there is no such thing as the “indivisible problem” in the enterprise. Enterprises don’t solve problems per se, they execute business processes. Developers tend to think in terms of nouns, which map nicely to objects, while business people tend to think in terms of verbs. For example, taking the canonical order processing scenario, the developer sees a single object – the order. Business people see the processes that surround that order – placing it, fulfilling it, paying for it. Typically, the developer sees these processes as methods: Order.Place(), Order.Fulfill(), Order.ProcessPayment(). However, these business processes don’t represent things the business object is doing, rather things being done to the business object. It’s a subtle difference, but it’s very important.

In Ivar Jacobson’s Object-Oriented Software Engineering, he talks about how over time objects tend to evolve to have methods that are only used in a single use case. He separated the concepts of the “entity” object – which represents a business object that has persistent state – and the “control” object  – which represents a process that modifies the state of one or more entities. (Note, control objects in this context are different from the controller object in the MVC pattern). In my experience, mapping use cases to control objects is a good first order approximation of your final system design.

However, implementing controls and entities with objects implies an intimate relationship as part of a single autonomous system. In practice, this is very difficult to maintain over time. First off, it’s a bad model of reality. Going back to the order processing scenario, different departments and people are responsible for executing the “fulfill order” and “process order payment” business processes. The departments don’t have an intimate relationship for good reasons, like trust and security. Those reasons should be reflected in the code. Secondly, business process changes much more often than business entities. You never know when you’ll want to change a step, modify the order of steps or completely rethink the process in the face of market and / or technology changes. In other words, you want the connections between the processes and the entities to be loosely coupled. If you tightly couple everything together, then you’ll need to change everything every time something changes. This leads to a stagnation that a customer of mine once compared this to carrying a big pile of cow manure – once you put it down, you don’t want to pick it back up!

If you step back from the OO mindset, you can model controls and entities in terms services pretty effectively. At PDC, we discussed the idea of resource vs. activity oriented data and the idea of service-masters vs. service-agents. These ideas are very similar conceptually to the control / entity separation. Control objects become business process services (also known as service agents or sometimes emissaries). However, when using services instead of objects, you gain power and flexibility that you just don’t get from the OO model.

Article on Ward

From John Alexander’s Blog, I found a link to an article in the Seattle PI about Ward Cunningham joining Microsoft. The article focuses primarily on descibing wikis, but it does mention he now works for PAG doing pattern work. I liked this quote:

“I write the seed of the idea and I come back in a week and see how the idea has grown.”

It’s also interesting to see that it took a month and a half for the news to go from blogs to a “mainstream” news source.

Architecture Symposium on the PDC DVD

Like others, my PDC DVD arrived today. Nice to see that all three Architecture Symposium sessions made the cut for the top 27 sessions of PDC.

Cool DasBlog Feature is Google Friendly

I was reading Steve’s blog with my browser earlier today when I noticed his odd permalink url’s. Instead of a url like “”, his look like “,guid,fc99ce5e-b748-44f0-853d-0a261632b885.aspx”. Turns out it’s a standard feature of dasBlog! Just check “Enable URL rewriting” in the config page and you’re set. Now my permalink url’s look like Steve’s.

Since Google doesn’t index pages based on query string, this feature should make my site more easily crawled and googled.

Update: This feature breaks sub category specific feeds, like “Blogging | dasBlog“, so I’m turning it back off until someone can fix the bug.

New MSFT Architect Blogger

Michael Platt, Field Architect in the UK, has started a blog. I know Mike and so I’m looking forward to reading his thoughts on the topics he lists in his first post. Subscribed.