the ‘bee log

One of the things that’s been at the forefront of my mind lately is how to price software that’s being delivered in an on-demand, service oriented world.

In my research I’ve uncovered what seems to be a pretty common rule: take the cost of a perpetual user license for your software and divide by 16 to 18. So if you’re charging $500 for a perpetual, on-site user license, the user/month charge would be between $27 and $31 dollars. Here’s an example of this model in the wild at VersionOne…

That’s a tidy little formula for using conventional wisdom to develop your a SaaS pricing strategy, but what about hosting? I’d say that if you have fairly minimal storage and bandwidth requirements, then build it into your price-per-user. That the strategy VersionOne chose for their on-demand edition. In our case we have a HUGE storage requirement and a HUGE bandwidth requirement, so we’ve elected to separate the user/month license fee from the infrastructure fee.

Admittedly this is a pretty simple rule, “The Rule of Divide by 17,” but it’s something to consider if you have a product you’re moving to the on-demand world.

I’d like to do a little series on this topic. Fire off an email or post a comment if there’s something in particular you’d like me to cover, and I’ll do my best to help. Next up…

• Conventional Resources for Price-Setting
• Pay-Per-Feature and Future Pricing Models

Considering this entry in my feed reader off of Steve Eichert’s blog…

In our experience at Xclaim, it’s not CAB or ObjectBuilder that is the bottleneck for your average business application, it’s caching tons of lookup data and metadata (we have ~4MB of just metadata) in the beginning of the application. Really any service you’ve declared with [Service] or register in the RootWorkItem in the AfterShellStarted (or whatever it’s called) method of your CAB application class is a potential time hog.

In these situations have to be careful that the data that you’re loading is coming in on another thread and the UI metaphors you’ve chosen drip feeding (the hypnotic AJAX ball). We’ve moved to “layer supertypes” (fancy way of saying “base class”) for our services that are easily refactored to multi-threading and supporting a asynchronous style. What’s cool about CAB is that it gives you the tools to build this kind of application… it provides a nice base, but you need to take it to the last mile.

In our big-assed CAB app (nearing release!) we’re optimizing there on these fronts. Reflection performance issues will be the absolute last bridge we cross when squeezing the last ounce of performance from the app. Though it’s good to know that there are tools in the Mobile Client Software Factory to bake in some of the attribute-based reflection mechanisms pre-compile.

I just caught an interview with Stefan Tilkov in which he describes Service Oriented Architecture for the developer and highlights some of the architectural choices and implications involved in various SOA flavors, implementations, and incarnations. Check it out.

I took away a couple of points.

REST is best for exposing services at the Internet scale. Seems like common sense, but it’s a good point. If your architecture is consumer-facing it’s best to have a low-barrier, easy API for AJAX/mashup-style development.

You can’t buy a SOA. I agree, but I’m not hearing much of a marketing message around turnkey SOA. Does that message exist?

What you can buy - and vendors should supply - are SOA-friendly applications. As companies like salesforce.com blaze trail with more than application services, but service-aware platforms, I’d expect that some of the effort around evolving a service oriented ecology to be eased by third party application selection, portfolio management, and in-build product support for SOA enablement… another thing for enterprise architects to look for in the buy vs. build equation.

There’s a really cool poster available on Stefan’s company site (innoQ) that details the landscape of WS-* protocols grouped by functional area. It’s a handy visualization for seeing which vendors have authored and what problem area each specification attempts to address, useful as there are an overwhelming number of them.

Note that this post has nothing to do with technology.

I’m just throwing this link up for friends and family that have asked (or, more likely, heard me gush) about my latest, greatest toy: a custom fixed gear bike for urban riding.

It’s a fixie bike based on a Soma Rush steel frame. It has a particularly nice wheelset (Phil Wood, Velocity Deep Vs). I’m still feeling my way around the handlebar and planning on replacing it with a straight bar w/ pursuit handles. Right now I have bullhorns with a decent drop and the drop feels kind of uncomfortable. Otherwise an awesome ride; it just wants to go fast and although it’s super light, feels like a tank in terms of the construction and overall quality of the entire package.

Yeah… it’s quite nice. Check out the slide show right here.

Update: Björn wrote in to slap me straight; it’s lines of text in the output window. Too bad, it would have been a nice subtlety…

—

Today I went to build one of our solutions and my eyes were drawn to the right side of the status bar in Visual Studio 2005. You know, the section that has “Ln”, “Col”, “Ch”, and whether or not insert mode is on. Well, usually the “Ln” element tells you what line of code you are on. If you double click on it, you get a little dialog that lets you go to the particular line (also CTRL+G)…

Anyway, tangent. What I noticed today is that the line counter kicks into a different mode when you’re building a solution or project it counts up! Now I’m not sure if that’s lines of source code, lines of generated IL, or what, but, hey, potentially a fun little attention to detail.

Anyone know what this number signifies?

For those of you who haven’t read the original book on DDD by Eric Evans, this free book might be a good get. The original is a great, great book but is quite long and quite expensive. InfoQ just released a pared down version that hits the big concepts.

Get em’ while they’re hot.

Tom Hollander mentions the upcoming Validation Block slated for the next revision of Enterprise Library. Check out the announcement over here. Very cool stuff. Needed. I heard about this at the October p&p Summit (along with the potential of a block mini-factory that greatly eases custom application block development.)

From the looks of it it will serve as a kind of Specification Repository (see: Specification Pattern), in addition to providing a simple framework for validation rules such as regex, not-null, etc. I like the idea of a validation framework that works for simple forms yet still provides a consistent means of implementing custom specification-type validation.

I wonder how convenient/elegant (more the latter) it will be to build custom validators that look at object graphs.

The first thing I’d like to investigate with this is the possibility of building a concept of “severity” into custom validators. For example, I want to send this domain entity into a specification engine that will a) get all the related specifications and b) run through them serially. At the end it will produce a collection of ValidationResults that have two levels of severity. The first is “it’s okay to save this to the DB”, the second is “you can’t save this to the DB”. If savable to the database, I’d like to have a third level of severity that says “you had better not extract this record out for reporting (even though it’s in the DB)”.

I got this idea from Jimmy Nilsson’s DDD book where he expresses a preference for being able to save domain objects in the DB. Almost like saving them in a “draft mode.”

I really like that idea. Be easy on the user and having the system say ”sure you can save this object any old time, but I’m going to track that it’s not quite right to prevent you from shooting yourself in the foot.” Of course, a positive user experience would make this draft mode explicitly clear.

I think Scott hits the nail on the head right here. Specifically that the Microsoft tools, guidance, and message (as of late) have been heavily centered on DataSet, DataReader and the like. I think these

I agree an Object Relational Mapper with LINQ as the Query Object implementation is very, very cool and certainly beats the heck out of NHibernate’s HQL, embedded database awareness in DDD repositories, or a roll-your own. The goal is to insulate and encapsulate the data layer and this is very, very hard to do with the current tools. I think LINQ is a double edge sword; if you’re using DLINQ to rip objects right off your database and these objects are sent directly to consumers, you’ve introduced fragility problems in your architecture. Changing a table’s structure amounts to changing all the features in the stack that have a dependency on the object (essentially defined by the table) from UI, Services, Business Components, etc.

So what do you need? A mapping layer. This is something an ORM like NHibernate (or what they’re proposing with the next ADO.NET) should give you out of the box.

That aside, for larger applications it’s time to break our entity representations out. Consider a medium-scale enterprise application that’s architect with a smart client, web services, and encapsulating business logic on the server in an object oriented Domain Model:

1. I want to use Domain Model on the server.
2. I want to persist my Domain Model objects into SQL Server tables. 
3. I want to serialize XML messages and use these messages as the basis for orchestrating activities on my Domain Model.
4. I want to write hardcore SQL in my business user facing reports.

Count ‘em — four separate paradigms for managing “entity data”. Four! But I want all of these things; they are what the situation/layer/architecture calls for. The ADO.NET vNext vision purports to solve this by managing a “conceptual model” through which different tools (object mapping, reporting, etc.) can work through to get a common representation… I’m just a bit skeptical.

For me (right now in the real world) it’s time to get past the “mobile data object” that travels from database to middle-tier to client, etc; It’s a holy grail. Instead, I’ll choose (where I can) to leverage the right paradigm for the right job in the right layer.  You have to look at every layer of your application and say, “when this entity leaves this layer in what format should it be in”. Different architectural layers work better with different entity formats: XML, Object, DataSet, etc.

How are you solving the problem of moving data across (potentially distributed) layers? Or - like me - have you given up?