SOA desperately needs DDD

Talking with some colleagues, involved in SOA projects, I often have the feeling of a big hole in the perception of what SOA is really meant for, and what is needed for SOA projects to be successful.

I do believe that SOA is a great idea, it just sounds like large scale common sense. But I also do believe that “large scale common sense” is an oxymoron. Many dysfunctions in SOA projects are closely related to what normally happens in large scale projects, and in many cases those dysfunctions are transforming the whole stuff a whole big loss of money.

A common mistake, is to focus primarily on the architectural aspects of a SOA implementation. Which sounds like a rather obvious thing to do, considering what the A of SOA stands for. Unfortunately, this approach often turns out being narrowed to large scale OOP, only with a different terminology. Services (and their underlying model) are not reusable the same way objects are (and you remember a bit of the times where “reuse” was the buzzword and OO was hype, you probably know that also object reuse turned out being a lot different from the premises).

Behind its interface, a service is implemented according to a specific model. SOA makes no assumptions about the model, and allows for different implementation strategies: so far so good. Still one of the primary drivers for SOA is the need to rationalize the enterprise landscape, by removing unnecessary duplications and enforcing reuse of enterprise level services (we’re still in the “large scale common sense” here). Too often, the attempt to rationalize the landscape goes too far, trying to involve also the model in the process. This is often linked to the way SOA is conceived and implemented within your organization, a policy like “every significant entity will have to be wrapped by a service” will possibly lead to an enterprise scale CRUD moloch.

Enter Strategic Domain Driven Design
The point is that a service might be a significant reusable entity throughout the enterprise, while a model might not. A model should be the optimal solution to one specific problem, valid within a specific context. The context must have boundaries to allow for an optimal solution. An enterprise-level model will rapidly become blurred and some key abstraction will start to serve too many different purposes.

What is a Customer within an enterprise? Can you really find a one-size-fits-all model to represent a customer within the many context that must be supported by your enterprise scale SOA? My take on that is ...nope. Well, you’ll always be able to find some trivial entity that can be the same throughout the whole enterprise, but the odds will be against you if you start looking to some non-trivial entities existing in multiple domains.

In strategic Domain Driven Design there are some key principles to address this situation.

• “a model serves a specific use”: a model is a tool, and to be perfectly shaped for a specific use, the use must be well defined. Like a tool, a model can’t be really effective if the same object is used for many different purposes. Also, an effective model must be kept small enough to be coherent and manageable by a single skilled development team.
• “a model lives within a well defined context”: context and their boundaries are really important to define a coherent model. There are entities that can be used in different context, but sharing the same entity is not necessarily the best way to address the problem. Often the drawbacks are heavies than the advantages.
• “there will always be multiple models”: despite this sounding rather obvious on a large scale SOA, many times a lot of effort is dedicated to try to fight this situation, with minimal chances to win.

A typical problem with SOA is that implicit communication costs are rarely accounted. Sharing the vision of a model within a development team already has a cost which can be kept small enough if the team size is reasonable. Having the same vision within a 5 persons team is feasible. Sharing the vision among 40 people (or more) from different consulting or body rental companies (which is a common scenario in large-scale SOA development) is pure utopia.

Back from the Italian Agile Day 2008

It’s been a nice and hard day. I had two presentations to lead, and I wasn’t in great shape. But I think the overall result was not that bad. I just finished uploading the slides on slideshare (but they’ll be available also on the Italian Agile community web site). Here are the links.

Agile: il Piano B

Agile vs SOA deathmatch

Anyway, many ideas emerged on the related discussions... I guess I’ll blog about them for a while.

Agile SOA Presentation slides posted on Slideshare

I just posted the slides from my in-the-brain session @SkillsMatter on slideshare. If you want to have a look, just follow this link.

Tales from my first in-the-brain session

Just right after my long awaited holidays, I rolled to London as part of my recently started collaboration with Skills Matter as a trainer. As a side activity, I had the chance to held a so-called "in the brain" session, giving a presentation about how to make agility work in a typical SOA scenario.

I must admit that I am quite happy with the result: despite a couple of night spent fine-tuning the slides, with my laptop in miserable shape (I had no battery left, and the 'o' key was activated by pressing 'p' and 'i' meaning that when I typed "pippo" the result on the screen was "poiopopoo"), everything went quite smoothly and I had definitely a good time. Also, the pub follow-up has been largely appreciated.

By the way, if you're interested in the content, a podcast is available on Skills Matter website.

Tags: agile, SOA, Scrum, podcast

SOA without ESB?

I've just watched this presentation held by Martin Fowler and Jim Webber about SOA. It's both brilliant and controversial, but definitely worth a look.
More about this will probably follow... ;-)

Tags: agile, SOA

Doing Agile In Italy: Paperworks

In the last Agile Day in Bologna we had quite a few demonstrations of how to make Lo-Fi tools (such as Post-it, StoryCards, etc.) work, to master an Agile development process. Fascinated by Tim McKinnon's presentation, I then went to a local office supply shop to find some tools to play with. Unfortunately, when I started describing Tim's nylon attachable pocket board, the girl at the shop started looking at me quite …oddly (ok… if I describe it this way, nobody could understand, except the few that attended Tim's speech, but I assure you I did my best. I also looked for pictures of "the thing" in the 'net but I couldn't find one – …maybe because I don't know the name).

Anyway, I went to the shop. And what I asked for seemed odd. There was something similar, like cork boards – in this case you need some pins to attach story cards to the wall – or something else that could contain, buy not show the story cards. I then shifted on Post-It papers. Which are cool as long as you have the right board to stick them on. They also have some drawbacks: since they're sticky, you do not write anything in the B-side (while you do that in story cards or CRC cards). I also bought some Super-Sticky post it. They stick everywhere. But there's a smaller choice of colors so it feels like you're in Coldplay's "Yellow". I felt a bit frustrated but also eager to try to squeeze the best from what I had.

In a couple of days I had a chance to play with my Post-Its. My task was to define a development process that was suitable for a SOA environment, agile enough to be productive, formal enough to be used in a Banking Institute. We started playing with our Post-It and … worked. We were able to spot contradictions and missing pieces in a very short time. Writing the document will be the long and tedious stuff, but I guess in this case it's unavoidable: agility still has to cope with the suit-and-tie mismatch.

Tags: Agile, SOA, Italy, Development Process

Steve Jones's SOA vendor ratings - updated

As before, Steve Jones does a great job in summarizing the SOA vendor landscape in a few lines, here is the link to Steve's post. You may not agree with all the remarks, but it's certainly useful.

Tags: SOA

Designing to lower the TCO

I was reading this post from Steve Jones, and had mixed feelings: as I commented on his blog, I am trying hard not to be that type of architect. But forcing an organization to consider the Total Cost of Ownership for the whole project lifecycle is often a tough job.
Sometimes is the organization itself to be badly shaped, maybe with separated budget between development and production, so managers aren't enforced to save somebody's else's budget. Sometimes the cost of ownership is perceived as a "normal mess" and becomes alarming only when it's totally out of control, which can be ten times bigger than acceptable, or more, due to the "buffer effect" of the dedicated people.

Sometimes is the overall project planning that plants the seeds, for the "touch and go" architect. Time is allocated mainly before the whole development starts, so the architect can't see the developers in action. I mean, architecture is challenged by development, and by time too: developers could not behave as predicted and find different ways to solve coding problems, and evolving tools and framework could make the balance of forces that drove some design choices not any more valid (that's a good reason for architect to document the reasons of their choices). It's often not a matter of being right or wrong, but instead a matter of seeing the whole picture , which is - obviously - much easier at the end. Following a project till the late stages clearly makes a better architect, but seeing everything possible from the early stages is what software architects are paid for.

There's some sort of analogy with the traditional drawbacks of the waterfall approach with the analyst role. Agile processes have put of a lot of efforts in introducing iterative release cycles, which are just a way to anticipate real feedback as much as possible. Iterating architecture, for some reasons, seems to have a longer path, but I'd say it's probably the same problem, only with different category of users.

Tags: SOA, project management, enterprise architecture