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.


Sorry, Harry, I just can't hold back responding to this barrage of OO hate mail :) Maybe since I started in real-time where OO is most appropriately matched. First off, I never get what people mean when they rail against OO. After all, isn't the .NET framework OO? Would you rather go back to c and win32 APIs? OO can be applied at different levels, and the question is where is the approach appropriate and where is it not. Getting back to one of Ram's points, I think services and objects should operate at different levels of abstraction. Objects work fine and for me are a preferred approach to implementing logic within a service. I honestly don't understand how one would implement complex business logic - such as a pricing engine - more effectively using a bunch of loosely coupled fine grained services, or what benefit "loose coupling" brings for logic that will never be externalized. Additionally ideas have moved in the OO world over the years (multiple inheritence is bad, shallow inheritence hierarchies are good, aggregration of behavior is generally preferred over inheritence, etc) - there is nothing about an object model that requires state to be mixed with behavior, and maybe that's the next evolution for a class of problems. It's ironic that you quote an OO book to make your point. I guess at least some OO guys can evolve. The question what is the right conceptual level for services and objects. I believe SOA is all about how the right way to model and externalize business capabilities - they are appropriate at the boundaries. I don't think it has to be my way or the hiway when it comes to services and objects.
Chris, we're in violent agreement. OO is the way to go inside the service and you KNOW I am a big fan of the .NET framework. Ram's opinion on abstraction levels was right on the money - I didn't reiterate since he did such a great job. Part of what I'm saying is that some OO ideas - i.e. the entity / control seperation - also work in an Service-Oriented (SO?) world. The problem is that many people still don't see the value of SO systems. Advocating an OO/SO balanced viewpoint over a pure OO one does sometimes look like OO hatemail. I didn't mean it to be. Hey, shouldn't you be writing this on a blog of your own? :)