jvdb.org Blog

For the past two days I’ve been visiting architecture sessions (ARCxxx) and a single one on Visual Studio 2005 Team System. After that I remembered why I don’t like sessions that focus on tools and instead prefer to just work with them myself for a while to get an idea of the functionality: every time I’m at a tool session every demo provides more questions than answers. I keep wondering about the situations where it could be useful and immediately think about whether it will or won’t work in those scenarios.

For instance, there was some talk of allowing you to set constraints on a check-in in the source control system, which seems like an excellent feature. When demonstrated, it showed an example where you had to associate a check-in with a work item and where you had to run code coverage. I then wondered how this would work: can you specify the type of warnings coming from code coverage to allow before a check-in is possible? And if you have to associate a work item with a check-in, can you only check-in on work items that were explicitly assigned to you? All in all, I think I’ll stick to messing around with CTPs to find out how the tools work.

The architecture sessions are very interesting. The focus this year is clearly not on implementation technology: last year there was a lot of talk of webservices and infosets, probably to get everyone to at least play with the tools. This year the message appears to be that business modeling should be the basis for coming up with business processes to expose and creating autonomous services around that. Interesting, but it appears that this is fundamentally very much like most component-based development concepts (even though it’s true most component-based architectures are hardly correct in this sense, but does anyone really believe the architects will get it right this time around when they roll our their SOAs?)

What’s very interesting to me is this shift from mapping OO onto everything to a more document-based approach when dealing with services. OO is ofcourse a great methodology to model software, but it’s quite pointless to hold onto this when describing services, that should be aligned with business processes that live in a mostly procedural world. So does this mean that responsibility-driven design will take a backseat again to the use case approach? This time around, these might actually map better onto services.