At least one person was interested in an OPML of MSFT .NEAT and AE bloggers. So I hacked them out of my full blog roll and posted it on my site. I will be keeping it up to date, so check back every once in a while. I added a link to it in my nav bar so it is always available.

I love dasBlog. I was able to make one small change to the web.config file and now the OPML file is addressable while still being easily managed via dasBlog’s blogroll editor. Sweet.

Don pointed out to Goran that the Indigo definition of “a service is simply a program that one interacts with via message exchanges.” Goran pointed out that that definition “really doesn’t highlight how it’ll help a customer”. I think part of the reason they are both right is that they are talking about different things. I would say Don is talking about Service Oriented Programming where Goran is talking about Service Oriented Architecture. This gets back to the levels of architecture that I blogged about. Platform tools like Indigo are components used in systems. I’m guessing the customer’s Goran mentioned are at the system-of-system level for whom the messaging plumbing is below the abstraction level they care about. 

Of course, SO* buzzwords are thrown about with such frequency these days it’s hard to keep track of the difference.

I’In the space of 24 hours, Martin Fowler and Michael Platt both point to this article by Steve Cook about Microsoft’s views on MDA. This article plus Keith Short’s whitepaper and PDC presentation (slides) pretty much lay out Microsoft’s position on OMG’s MDA.

MDA is misnamed: it is not an architecture at all; it is a standardized approach to model-driven development based on abstraction of platform similarities. As promoted by the OMG, it does not address the broader issues involved in using integrated models, patterns, frameworks, and tools synergistically to support software product lines. Furthermore … the fact that the MDA is based on the use of the UML and MOF specifications restricts its usefulness even more. [Domain-Specific Modeling and Model Driven Architecture by Steve Cook, page 6]

Keith and Steve are architects in the VS.NET group, so this is straight from the horse’s mouth. Steve joined MS last year, leaving IBM where he had worked on (among other things, I’m sure) the UML 2.0 specification process. It’s interesting that someone who has worked on UML so extensively appears to have such a negative opinion of it’s direction.

Since “MDA” and “Model Driven Architecture” are registered trademarks of OMG (even though they are often used to refer to the generic approach of using models in the design process), Steve refers to Microsoft’s approach as “Domain-Specific Modeling” while Keith writes about “the idea of a family of inter-related, but individually specialized modeling languages the industry is calling domain-specific languages”. Here’s the short version of our vision / scope:

At Microsoft, we firmly believe that modeling is an increasingly important aspect of the software development process, and we will integrate support for modeling into forthcoming releases of Microsoft Visual Studio. We believe that it is essential to design modeling languages very carefully to suit the skills of their target users: we intend to delight our users by giving them an experience of modeling that is intuitive, agile, productive, and seamless. We are targeting our first modeling products at areas that we believe will give most immediate benefit to our customers. At the recent Microsoft Professional Developers’ conference, we announced modeling tools–we call them designers–that help the developer to design and deploy distributed service-oriented applications. [Domain-Specific Modeling and Model Driven Architecture by Steve Cook, page 5]

BTW, the tool we announced at PDC is code named “Whitehorse”. If you haven’t seen it, it’s described in our developer tools roadmap plus there’s a video about it on MSDN TV.

As a firm believer in UmlAsSketch approach, I’m very excited about what we’re doing in this space. It’s a very incremental approach. Whitehorse solves a very specific real-world problem while MDA is out trying to boil the ocean.

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.

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.