Damon seems fired-up about the new DSL tools in Visual Studio 2005. But he asks:

Why limit the use of this tool to visual studio users?  Suppose you work in a business with a fairly well defined domain, such as selling mutual funds for a specific company.  If you could define your domain entities, attributes, connections, rules, etc and then put this tool into the hands of people like, oh, say, business analysts you may have a very powerful code-generation and/or documentation tool that is usable by the people who supposedly know the business best.

I'll tell you why.

When presented with the idea, most people will claim they want a tool that allows a domain expert, rather than a software developer, to create software. Or at least they’ll say they want a tool that lets the domain expert configure or assemble software. After all, who knows the business better than a business person? Give these people a nice DSL tool or BizTalk and let them construct the system.

In my experience, however, I've found this desire is not genuine. It's incredibly difficult to get the business folks to commit to a domain model. I’m not implying that we developers are necessarily any smarter or more analytical, but we’re better equipped – and more interested – in creating a logical domain model of a business than a business person is. If you, the developer, create a domain model, a business expert can probably tell you where the model falls short of reality. But I’ve yet to meet a business person that could synthesize a good domain model. Get five business experts in the room and you’ll get five varying models (of the same business).

More importantly, business folks don’t really want responsibility for the solution. For most developers, our work is an expense to the business and the business will (rightly) try to minimize that expense. A company needs to keep its toilets operating; this is another expense. The company also wants to spend as little money as possible on toilet operation. But, when a toilet breaks, the business folks don’t want an easy-to-use, next-generation set of pipe-wrenches. They want a plumber – someone with valuable expertise in something other than the business’ own core-competency.

Likewise, a company needs to keep its software operating. The moment a business person makes a software change that unexpectedly halts the inflow of revenue, they won’t want a great tool. “They'll want a throat to choke,” as my friend Philippe says.

Despite these comments, I’m a firm believer in modeling tools. I think they are useful and will become increasingly effective. But they won’t turn business analysts into programmers. They will be used by software developers to make ourselves more productive – much like a better pipe wrench could make a plumber more productive. These tools will alter the nature of our work, and businesses will earn a better return on their software development investment. But the role of the software developer won't be going away. Luckily for us, nearly all companies need toilets and software to stay in business.

[Grady Booch] ... Glen Vandergurg's collection of quotations on software design make for fun reading.

I've seen many of these before. A few that I haven't are hilarious.

To a database person, every nail looks like a thumb. Or something like that.

- Jamie Zawinski

Bob Parsons, the founder and president of GoDaddy.com, has a blog. There are at least five reasons why this is guy interesting.

First, I know everybody has a blog these days, but I’m still surprised when I see an executive of any sizeable corporation blogging (without a ghost writer). Today, an executive identity and opinion that is separate from a meticulously-crafted corporate message feels strangely out of place (not that I mind).

Second, Bob has unconventional opinions. When most technology companies are trying to find ways to cut costs through offshoring, he posts a contrarian view:

I can tell you right now, Go Daddy is simply not interested in moving its operations offshore.

Bob seems to (rightly) regard software engineering as a source of competitive advantage, rather than an short-term expense that should be minimized regardless of long-term consequence.

Third, there’s the controversy around Go Daddy’s Super Bowl commercials. Conventional wisdom is that a little-known dot com should not purchase a spot in the Super Bowl. That was conventional wisdom circa 2001. But the commercials were a big success for Go Daddy.

Fourth, there are lots of programmers who spout opinions in blogs. Not all of them have created software companies with $100,000,000 in annual revenue.

Fifth and finally, he has rules to live by — sixteen of them.

After five months without posting, I was shamed into blogging again at the first Milwaukee area .Net geek dinner (thanks to Casey). I’ll take the fact that *Milwaukee* can support a geek dinner as a sure sign that the .Net platform has become ubiquitous.

It’s been an insanely busy year. I’ve typically been working on two or three projects concurrently – each with clients expecting to see regular progress. Since some of them read my blog, I’d have no excuse for not meeting a deadline but still having time to post.

But I’m not complaining. It’s a privilege, not an obligation, to get paid to do what I do. The day this becomes drudgery is the day I’ve lost all perspective. Anyhow, stay tuned for more posts; I’ve been implementing a lot with (and getting battle scars from) service-oriented architectures over the past year.

In a previous post, I've explained that I have an interest in rating engines. In fact, I have more than an interest -- I have an opinion. And that opinion is: If you plan on writing code to calculate an insurance premium, it's often best to write a custom rating engine.

But before I can expound on this, I need to describe what a rating engine is. I'll start by describing the problem that a rating engine is supposed to solve. Insurance companies - more specifically, the actuaries - capture a lot of knowledge that is used to calculate an insurance premium. That knowledge has a few annoying characteristics: It is complex, it is large, and it subject to periodic, if not frequent, change.

You could just write source code to calculate an insurance premium based on that actuarial knowledge. But your code would have a few annoying characteristics: It would be complex, it would be large, and it would be subject to periodic, if not frequent, change. Or, if you were diligent enough to prevent the first two characteristics, your code would accrue another characteristic: It would be very costly.

So a rating engine should incorporate all of that actuarial knowledge to calculate a premium, but be neither too large nor too complex. It should deal with change gracefully. But still, what exactly does a rating engine do?

A rating engine has one primary function and a few supporting functions. Expressed as a use case, the primary function is to Calculate Premium for a proposed set of coverages.

But in order to calculate that premium, the user (let's call them Rate Consumers) needs to know how to assemble a valid set of proposed coverages. Insurance companies have lots of dependencies and constraints that describe what coverages and options can go together. This aspect of insurance - product design - involves capturing the knowledge of the product designer. The engine needs to expose this knowledge to the Rate Consumer in some way. We'll call this use case Get Coverage Catalog.

It only stands to reason that when a Rate Consumer asks for a premium, the engine should check whether the proposed coverages are valid according to the coverage catalog. This functionality is really part of the Calculate Premium use case, but to draw attention to it, we'll put it in its own use case, Validate Proposed Coverage.

Finally, there needs to be some way to transform the knowledge that exists in the heads of the actuaries and product designers into a form the rating engine can use. The actor responsible for doing this is a Rate Administrator. We'll call this use case Manage Coverage Catalog and Rates.

You read it here first: The term service-oriented architecture shall be renamed to message-oriented architecture. SOA shall become MOA.

Well, not really. It won’t happen, even though it should.

The entire point of SOA is to achieve loose coupling between applications. That’s it. Loose coupling.

But that loose coupling has important second-order effects. It allows applications to evolve independently. It allows applications to scale independently. It allows applications to change deployment models independently. All without breaking one another.

As many have rightly pointed out, this goodness comes at a price: The only way to talk to a “service-oriented” application is to send it a message. You don’t get to see its types. You don’t know where it is really executing. You get to send it a message. It might send you a message in reply.

So, shouldn’t we call it, “Message-Oriented Architecture?”

In a previous entry, I brought up the challenge of preserving the original caller’s identity across tiers. Sure, this can be solved in a half-a-dozen ways, but which is the right way for the given situation? When designing a real software system, it’s all about the tradeoffs.

And the tradeoff I faced is that I want to know the identity of the caller even after I cross from the presentation tier to the application service tier to the database tier. But I don’t want to incur the cost of authenticating a second or third time (at each tier). Remember, my callers’ identities are not guaranteed to be in Active Directory, so a service invocation would mean an extra trip to my own authentication service and database.

My solution is to pass the caller’s identity, out-of-band, as I cross from the presentation tier to the application service tier. Note, I said the caller’s identity, not credentials (by identity, mean all of the information that is required to construct a custom Principal). On the application service tier, I’ll use an HttpModule to pull the identity out of a SOAP header, reconstruct a principal, and attach it to the current request. Now, I can perform role-based authorization in the application service tier.

Of course, passing identity information around the network, even within the external firewall, is dicey. I’ll use IPSec to preserve the integrity of the data that moves between these two tiers.

So, I get the benefit of a trusted-subsystem authentication model, without loosing the ability to perform role-based authorization based on the original caller.