I recently posted on some important differences between DevForce and RIA Services. Someone posted a comment to the effect that DevForce and CSLA seem to be the same and invited me to comment.
I see the similarities between DevForce and RIA Services. I don’t think DevForce and CSLA are alike at all. Why would someone suggest that they are?
That got me thinking and lead to this post which reframes the question.
It first establishes what we have in common … and how to decide quickly if you should consider any of us … or none of us … for your application project.
Then it articulates fundamental criteria for comparing the three.
Important: These criteria are not evaluative. They are as neutral as I can make them. I feel pretty confident in that neutrality because, as I apply them to the three products, I can not tell which one of them is “better”. They help me organize my thoughts, not decide which one is “right.”
Let's start with the what we have in common.
DevForce, CSLA, and RIA Services target the same problem: building distributed business applications from end to end, server to client.
If you don't think you have this problem, none of us are right for you.
We offer .NET-only products. RIA Services is limited today to Silverlight applications; DevForce and CSLA support most .NET client technologies (I don't think any of us are ready for WP7 .. yet. CSLA may work on the CE; we do not). Your required server and client operating environments may make the choice for you.
We all have the same presumption of a relational database as the primary backing store. Sure we can also persist to other backing stores. But these alternatives appear in supporting roles if they appear at all. None of us are your best choice for building applications that primarily access data through messaging services or persist to one of the NoSql schema-less data stores.
We all attempt to solve your application problem within some flavor of "mobile business objects" paradigm. If you summarily reject a "mobile business object" solution on principle, none of us are right for you.
Finally, we are all framework products. We're not application generators. If you want to drag-and-drop your way to a finished product, we're not for you. If you reject 3rd party frameworks, we are not right for you either.
With me still? Because now we are ready to differentiate the three products.
You have looked at the problem and you've chosen to solve it by allocating some responsibilities to a framework, reserving others for yourself in the expectation that you will be writing custom application code.
Every framework is opinionated. Each says:
- We will be responsible for these tasks (the A-list).
- You will write custom code for these other tasks (the B-list).
- Our architecture and recommend development practices pretty much prescribe that you will write your custom code in manner C.
You look at these opinions and ask yourself
- Do I want the framework to do the things on the A-list?
- Do I want to write code for the things on the B-list?
- Do I want to develop in manner C?
- How productive will I be if I adopt this framework? How quickly can I write quality B-list code when I adopt manner C?
- What items on the A-list do I really have to do myself? Can I take these particular tasks away from the framework with acceptable ease and still, in the main, be using the framework the way it was intended?
- I wish some of the items on the B-list were handled by the framework. What will it take for me to write them myself or acquire them from someone else?
- I don't care about some of the items on the A-list; do these items get in my way and if so, will that be a serious problem?
- Do we have the skills and development culture to use this framework effectively? If not, can we and should we acquire those skills?
- How do these factors collectively influence my development timeline? Do I have a deadline? If so can I reasonably expect to hit the deadline with the resources I have using this framework?
You will also consider some “non-functional” factors
- Product quality and maturity
- Access to source code
- Support
- Influence on roadmap and repairs
- Product release schedule
- Community (resources, training, etc.)
- Company stability
I have conspicuously omitted one factor: license costs. CSLA and RIA Services have no license costs. DevForce does. Why doesn’t that matter?
It doesn’t matter because you’re building a custom application that you’ll be living with for years. A few thousand dollars of licensing fees are irrelevant … they are rounding error … compared to the application investment you’re about to make and the risks you are about to assume.
If this is not blindingly obvious to you, you shouldn’t be making this decision. You simply don’t have the requisite business acumen to make the right choice.
When you dissect the products according to these criteria – which you’ve refined and weighted to suit your business environment and requirements – the differences among CSLA, DevForce, and RIA Services will stand out in sharp relief. You will have a foundation for choosing among them.
I said the differences will be stark; I didn’t say that the choice will be easy. Even within the same organization people will weigh some differences more heavily than others.
You will at least have arranged matters so you can see more clearly what you’re arguing about.
15 comments:
You said,
"I have conspicuously omitted one factor: license costs. CSLA and RIA Services have no license costs. DevForce does. Why doesn’t that matter?
It doesn’t matter because you’re building a custom application that you’ll be living with for years. A few thousand dollars of licensing fees are irrelevant … they are rounding error … compared to the application investment you’re about to make and the risks you are about to assume.
If this is not blindingly obvious to you, you shouldn’t be making this decision. You simply don’t have the requisite business acumen to make the right choice."
WOW!!! That's quite a statement! It's also condecending, arrogant, and ultimately wrong.
What's blindingly obvious is that cost matters in some situations, like when the app you're building will be FREE! A lot of which are very complex apps, with the option for the vast majority of it being open source.
Secondly, the relationship between having to live with an application for years, and the cost of any component are two orthogonal concepts. The blindingly clear implication is that the two products you are comparing against are inferior, so paying for yours is the intelligent choice.
Even if that is true, you have made a really crude attempt to state it, and it really turns the reader off(at least it did for me).
I understand and accept that you're biased, but you bias is very offensive.
Sorry to offend, Fallon. Not my intention.
Nonetheless, I stand by my statement. Condescending and arrogant as I may be ... I am unequivocally right on this point.
If you want gooey platitudes and a nice pat on the head for gifting the world with your free software look elsewhere.
Hey, I enjoy free software as much as the next person. But I said at the top that these products target business applications built by and for business.
Stake holders make economic calculations regarding opportunity, time to market/production, and all development costs including the cost of paying developers for their time. Incidentally, even when working on free software, do you value your time at $0?
My point is that the costs and risks involved dwarf the licensing fees.
I neither said nor implied that my product was a priori better than the others. I said that the three products are different.
So different, in fact, that when you compare them in the manner I've suggested ... according to your specific development preferences and business requirements ... you will choose one over the others for reasons far more compelling than the cost of a license.
We're not talking about competing brands of soap.
Anyone incapable of grasping these points is ill-suited to making a business decision of such magnitude.
That's just a hard cold fact. Read it and weep.
Ward,
Having taken a class with you, using your product and experiencing your tech support and product lifecycle, I can appreciate your comments. Unfortunately for my company, we couldn't justify the cost of your product. I enjoyed working with it and your team, you guys are great.
Obviously, justification for cost and production usage play heavily into decisions, as short-sighted as they may be. The months spent re-inventing technology already present in DevForce is a dumb proposition, but companies do it all the time.
If your licensing model was a bit more relaxed, we would have stayed with you.
Good luck man!
Thanks, Anonymous. You reminded of two things.
First, DevForce pricing has changed substantially since you last saw it. You may want to look again.
I'm not supposed to be talking about pricing in this space but what the heck.
There is a free, no-time-limit version, constrained to a model maximum of 10 entities which is great for exploration but rarely sufficient for production apps.
Most DevForce 2009/2010 customers are paying $1000 per developer ... period. No runtime fees. No server fees.
Second, of course license fees are part of anyone's calculation.
I am saying ... predicting if you prefer ... that a few thousand dollars of license fees are peanuts compared to the total amount your company will invest in and derive from the timely arrival of your high quality, maintainable, "growable" application.
Some organizations will determine that RIA Services or CSLA is the better choice for them. When their reasoning is sound, the license fees will have played a negligible part in their calculations.
When you do your comparative analysis, if DevForce doesn't outdistance CSLA and RIA Services by far more than its license cost, please do not choose DevForce. It's that simple.
--
Now, can we please talk about the substance of this post?
To that end, I will exercise my editorial prerogative to ensure there is no more commentary on license fees in this post. You're welcome to email me directly: AskWard AT IdeaBlade DOT com.
You have to ask the question Why did Brad Abram's leave Microsoft.He was responsible for RIA Services,and while Ria Services is good at what it does, it is no where near what Devforce delivers.Ward it is a pity they did not hire you for the job.
Thanks for the endorsement.
I'm a HUGE Brad Abrams fan and I know better than Google how lucky they are to have him.
I hope MS has put RIA Services in good hands. I don't know the new leader personally.
Two further points, one minor, one major.
Minor: I'm done working for a big company. Plenty of heartburn running your own business but I like it and I like our IdeaBlade crew.
Major: I am not IdeaBlade. I am not the author of DevForce nor its chief architect. I haven't written a line of it. I'm heavily involved of course but the credit belongs to the great team of talented people who design, build, support, market, and sell it.
Ward,
I agree wholeheartedly that the cost of a development license is a drop in the bucket compared to the investment in building/maintaining the app itself and can be recouped easily when you considered increases in productivity.
Even in the case of free software, you're obviously building it for a reason and there's most likely going to be maintenance required for it. The question is do you want to lose productivity going against the grain of a tool because it's free or do you want to cough up a few dollars to get a tool that is better aligned to the other dimensions.
Like Ward mentioned, if you value your time at $0 the choice is a no-brainer. Personally, my time is priceless and if something helps me spend less of it (and I have the budget) guess what I'm going to do?
There is also one important point you forgot to mention, and that is 'who is behind the technology'. Yes, they are all 3rd-party products, but the chances of CSLA and/or Devforce being discontinued are much higher than those of RIA Services.
@sammy - long-term viability is a critical factor as you say. I'm not sure the probabilities are as clear as you suggest. CSLA has been around 12 years? IdeaBlade for 10. And, while Microsoft rarely discontinues support for a product ("Kin" anyone?), it does put them on ice. LINQ to SQL comes to mind.
Infrastructure buy-versus-build is a balancing act. You can - and should - insulate yourself from uncertainty with loose-coupling and isolation techniques.
Does the selected technology make that easy or hard? We've worked hard to make isolatation easier. I always recommend the Repository pattern, for example, as a means to increase application testability AND insulate the UI from the persistence machinery.
I think you'll also find that we keep alignment with Microsoft APIs at the points where you encounter those APIs frequently. This is somewhat self-serving ... it makes it easier to convert from RIA Services to DevForce; but it also facilitates a fallback to RIA if things don't work out.
I'm on the edge to go for DevForce to rewrite our ERP app from scratch. My biggest problem is: will DevForce be able to deliver for my big app? CSLA.Net is great, but it's kinda slow. RIA Services is not 'compleet' enough. Alternatives? There is LightSpeed, but no idea how well this performs either. XPO from DevXpress is not mature enough for SL.
Also, how many customers does IdeaBlade have on their latest version? This could proof the continouity of the company.
My app has a database of over 250 tables and should be able to handle more than 250 concurrent users. Will DevForce do?
@COBRASoft - thanks for your interest. My blog is not really for sales and marketing despite appearances I guess ;-/
Business continuity? We've been in business since 2001 and 2010 was our best year. Hundreds of new customers this year for sure.
We have several very large customers, among them a F100 institution with a customer-facing app that serves 5000+ small business customers (goal: 20,000+ by 2012).
We're excited about 2011 especially now that SL is more widely appreciated as a business application platform.
250 tables is modest size for our customers (some of whom have 1000+)as is 250 concurrent users. What really matters is what they are doing.
For more info, though, please contact sales@ideablade.com
mmm, this leaves one in a situation where you really have to take a sample of functionality and build it using all three frameworks in order to answer the questions you say one should be asking.
I guess my question is, has anyone done this? Has anyone compiled answers to these questions based on such an exercise?
--Shawn
@Shawnolius - A point of RIA/DF comparison is the Book Club by John Papa and the BookShelfDF by us.
It gives you a feel: no DomainService, testability, etc.
What you can't see in that example are all the things we do that you can't do in RIA ... because, perforce, they aren't in BookClub which is the baseline.
You also can't see what happens as you evolve your model. You can't see how much easier DF is to maintain.
I intend to demo that by pretending to change the model and following the steps. Try that yourself if you can't wait.
Harder to demonstrate is the consequences of our much greater agility. RIA has YET to release any changes since v.1. They have an SP1 waiting. But it won't go out until who-knows-when. They seem to be pinned to big and slow MS release cycles.
We release every 7 weeks. We respond to bugs and feature requests. You can ask us what is happening and we tell you. Try to find out what the RIA team is working on. Good luck.
I don't have anything to compare to CSLA. Frankly, we haven't run into CSLA competitively ... as we have run into RIA.
Very late for a comment to this post, but I am going round in circles on this one. DevForce seems to be claiming a major productivity improvement - and I can confirm that it is very fast to go from nothing to a first working app for a new developer. Is there, however, any metrics or other evidence availavble to demonstrate that a skilled DevForce developer will be significantly more productive than developer using a set of Microsoft-only technologies and appropriate other tools?
I am looking for something that I could use as the basis for a business case for purchase. If I could realistically say that using DevForce the average productivity, once the learning curve is eliminated, might be even 10% higher then I would have a strong case.
David - It's hard to cite statistics because no one tries to write the same application with all the variations under controlled circumstances.
I can tell you that we continue to attract customers who tried CSLA or RIA first. We have many accolades from them.
To my knowledge, only one customer has ever left DevForce for RIA. The reason, as best I could determine it, was the arrival of a new set of developers who favored following a Microsoft standard over all other criteria. I don't know how that panned out for them; I hope it went well. And I hope they have a plan for the coming years now that MS seems to have changed course (again).
I recommend you contact IdeaBlade directly and talk to someone there about your project and your previous experience. They might be able to point you to something more tangible.
All the best
Post a Comment