Next week I will have the pleasure of sitting with peer architects/developers while my most recent application design is scrutinized. Some of the critique will surround my application architecture, which includes the use of LLBLGen Pro.

This work is for a client of mine, a Fortune 100 company in the USA. There is concern about the choice I made to use LLBLGen. We've already mitigated some of the risk (of LLBLGen going under? of Frans' code being exposed as malware? of ...?) to our client by using an adapter pattern - the UI calls the "Business" layer that we created, which under the hood uses LLBLGen objects to do all the work. This adapter layer could under the hood use something else if they decide they don't want to use LLBLGen. But I don't want that decision to be made.

I'm hoping for some input from others as to why you've chosen LLBLGen, and specifially why you believe it is an excellent vendor for a large enterprise to choose.

I love that there is now a book describing enterprise development with LLBLGen, and that Scott Guthrie (ASP.NET product manager) mentioned LLBLGen recently as a tool worth checking out (http://weblogs.asp.net/scottgu/archive/2006/01/30/436944.aspx).

But has anyone else had to make the case for LLBLGen in the enterprise? I'd appreciate any feedback you could give me. Thanks.

I might be able to help, however, it might be useful if you can share the criteria that will be used by your peers at this 'review'.

this

We've already mitigated some of the risk (of LLBLGen going under? of Frans' code being exposed as malware? of ...?)

kind of leads me to the opnion that som key criteria is already been agreed as standard by your client.

sparmar2000 wrote:

it might be useful if you can share the criteria that will be used by your peers at this 'review'.

I wish I knew for sure. But my gut feeling is that they are mostly concerned (understandably so) that LLBLGen is a "flash-in-the-pan" company that is here today but will be gone tomorrow. The fact that the source code is available I believe mitigates that risk, but I'm afraid they may not agree.

If I could somehow prove that the product has reached enough critical mass to prevent a sudden-death to LLBLGen, I would have a powerful argument to keep it as the tool of choice. The productivity we've gained by using it is another obvious argument, but not enough to seal the decision to use it.

But I'm also interested in seeing if anyone else has had to make a similar sales pitch out there, and if so, what won your peers over.

Uh, wrote:

But my gut feeling is that they are mostly concerned (understandably so) that LLBLGen is a "flash-in-the-pan" company that is here today but will be gone tomorrow. The fact that the source code is available I believe mitigates that risk, but I'm afraid they may not agree.

If I could somehow prove that the product has reached enough critical mass to prevent a sudden-death to LLBLGen, I would have a powerful argument to keep it as the tool of choice. The productivity we've gained by using it is another obvious argument, but not enough to seal the decision to use it.

I did a quick count in the fortune 100 list, and there are at least 13 companies in there using LLBLGen Pro. And there are of course other very big companies outside the US that bought LLBLGen Pro as well. Maybe that will make your client feel better We're a very healthy company and plan to stay.

Aglaia

Aglaia wrote:

I did a quick count in the fortune 100 list, and there are at least 13 companies in there using LLBLGen Pro. And there are of course other very big companies outside the US that bought LLBLGen Pro as well. Maybe that will make your client feel better We're a very healthy company and plan to stay.

That's helpful info. Thanks.

13 out of the top 100. That's interesting. Would you be able to provide some of these company names? If not, how about some clues so we can guess?

We currently have some consultants in that are pushing hard for use of the Microsoft Enterprise Library for all data access, and trying to ignore my championing of LLBLGen O/R mapper approach.

Very few Pros where listed in a presentation by consultants. Here are the cons that where listed for O/R mapping:

1. Learning curve for using OR mapped entities and managers and app.
2. Integral layer of the app is tied to 3rd party software provider (concerns about support)
3. Adoption of this approach not prevalent in .NET community
4. Complex C# using OR mapping classes instead of SQL Sprocs
5. Code recompiles needed
6. Difficulties for query optimization by a DBA
7. MiddleTier programmer needs proficiency in creating SQL using OR classes.
8. Sprocs vrs Dynamic SQL performance debate

I explained that being a small shop where the underlying data has a tendency to change, that the O/R mapping code generation approach works very well.

I understand that they are going to champion the technology that they are most familiar with but it's a little disconcerting. I gave an fairly extensive run through of how the tool and code work within our current situation it still seems that they are not hearing me that well. Time will tell I guess.

[quotenick="Ren"]13 out of the top 100. That's interesting. Would you be able to provide some of these company names? If not, how about some clues so we can guess?

clues? haha 'blue' 'inside' 'mickey' planes lightbulb printer

We currently have some consultants in that are pushing hard for use of the Microsoft Enterprise Library for all data access, and trying to ignore my championing of LLBLGen O/R mapper approach.

Enterprise library for data-access? They must be payed by the hour then, as the Entlib doesn't add any productivity gain, just does things differently...

Very few Pros where listed in a presentation by consultants. Here are the cons that where listed for O/R mapping:

1. Learning curve for using OR mapped entities and managers and app.

There's always a learning curve, and if I may say so, the learning curve for the over-designed complex classes in the entlib isn't small either.

1. Integral layer of the app is tied to 3rd party software provider (concerns about support)

VB6 no service packs for vs.net since 2002...

1. Adoption of this approach not prevalent in .NET community

that doesnt make it bad, it just makes it unknown. In the java community however, it's a given.

1. Complex C# using OR mapping classes instead of SQL Sprocs

that doesn't make complex filters go away.

1. Code recompiles needed

Try to add a parameter to a procedure without recompiling...

1. Difficulties for query optimization by a DBA

That's always the case, also with procs, as the context in which procs are used isn't known to the dba, so calling a proc a lot of times in a given context is also not optimal. The thing is, the DBA should be used as a consultant and should work together with the developers to write the best possible application. They all work for the same company.

1. MiddleTier programmer needs proficiency in creating SQL using OR classes.

You have to explain that one.

1. Sprocs vrs Dynamic SQL performance debate

yeah well... if a person is payed by the hour, and don't need a reduction in development time, why would s/he bother of course...

I explained that being a small shop where the underlying data has a tendency to change, that the O/R mapping code generation approach works very well.

exactly.

I understand that they are going to champion the technology that they are most familiar with but it's a little disconcerting. I gave an fairly extensive run through of how the tool and code work within our current situation it still seems that they are not hearing me that well. Time will tell I guess.

Sorry to hear your work didn't pay off. It's often not easy to sell the obvious to a prejudiced crowd who thinks the opposite is great.

I'd like to add that using another approach doesn't mean that approach is bad or the app will suck, on the contrary. What I would like to see is that the choices are based on valid arguments...

Ren wrote:

13 out of the top 100. That's interesting. Would you be able to provide some of these company names? If not, how about some clues so we can guess?

We currently have some consultants in that are pushing hard for use of the Microsoft Enterprise Library for all data access, and trying to ignore my championing of LLBLGen O/R mapper approach.

Very few Pros where listed in a presentation by consultants. Here are the cons that where listed for O/R mapping:

1. Learning curve for using OR mapped entities and managers and app.
2. Integral layer of the app is tied to 3rd party software provider (concerns about support)
3. Adoption of this approach not prevalent in .NET community
4. Complex C# using OR mapping classes instead of SQL Sprocs
5. Code recompiles needed
6. Difficulties for query optimization by a DBA
7. MiddleTier programmer needs proficiency in creating SQL using OR classes.
8. Sprocs vrs Dynamic SQL performance debate

I explained that being a small shop where the underlying data has a tendency to change, that the O/R mapping code generation approach works very well.

I understand that they are going to champion the technology that they are most familiar with but it's a little disconcerting. I gave an fairly extensive run through of how the tool and code work within our current situation it still seems that they are not hearing me that well. Time will tell I guess.

That list is bullsh**. I've used the DAAP back when it was the DAAP and, if I remember correctly, you still have to write all of the data access code! And it's loosely typed, which means you never really know whether your database and DAL are in sync, which means you are dumb (not you personally, of course).

Take all of the time required to get up to speed on an O/R mapper and you still haven't come close to the amount of time required to manually code your whole DAL, and then rewrite it each time the underlying database changes.

I would approximate the amount of time required to write your DAL and the probable amount of time required to maintain it over the years, factoring in of course the cost of mistakes made during that arduous, manual, repetitive process and multiply it times the average loaded cost of your developers and architects, then ask them whether they think it's worth it against that list. Aside from fears/trust issue in the third party vendor thing (which can be addressed by code escrow), I don't even understand the debate.

The only other good reasons I can think about is if there are a) special security requirements, b) special/real performance requirements (though I'd talk to Marcus about that first), or c) your application doesn't fit into the typical CRUD model (meaning you do mostly heavy, heavy server-side processing of data. Perhaps there are other good reasons, but so far the fact that you don't have to write and maintain your DAL seems like it covers most of those reasons given.

Jeff...

Thanks for the information guys.

We shall see how this turns out. I have been open to the alternatives and have kept an open mind, but yes choices must be based on valid arguments. Seeing our current environment and expertise should be a contributing factor towards a unbiased decision.

Frans - I agree, another approach may work, but the idea that I try to get across is 'what happens when you guys leave?' and my small team is left to support it? I want to support something that doesn't require me to make multiple changes in multiple places. I was able to argue pretty much all of the 'cons' listed as well. A standardized generated base is easy to work with as opposed to multiple developers with their own coding tendencies ( a black box is harder to screw up)

As far as not being prevalent in .NET, I think O/R mapping or at least dynamic sql will be more so especially with C# 3.0 and the Linq stuff on the horizon.

Jeffrey -

I would approximate the amount of time required to write your DAL and the probable amount of time required to maintain it over the years, factoring in of course the cost of mistakes made during that arduous, manual, repetitive process and multiply it times the average loaded cost of your developers and architects, then ask them whether they think it's worth it against that list. Aside from fears/trust issue in the third party vendor thing (which can be addressed by code escrow), I don't even understand the debate.

I may not be on the same vocabulary wave length as you. What do you mean by

which can be addressed by code escrow

? Otherwise this is some great information. Thanks.

I had to justify the use of the O/R mapping before when I first introduced it, but when the director of IT leaves and someone new steps in, sometimes you have to do it again.

Code escrow refers to the practice of some vendors of placing the source code of the product in escrow; essentially, if the vendor goes belly-up, the source code gets released to the customers. I think Frans mentioned this before, but I'm not sure if it's been implemented...

Jeff...

<Edit>I searched for an old thread that talked about code escrow; I knew there was one. The thread is a good read now, especially in the context of Linq et al as it talks about marketing and the positioning of LLBLGen Pro. It'll be interesting to see how much market share SD will gain in the Orcas timeframe.

The references to code escrow are on the second page.

Gosh, that is an old thread.

I looked so much younger then...

jeffreygg wrote:

The references to code escrow are on the second page.

To save you from wading through a lot of messages: we made arrangements with a notary that if we can't decide ourselves what to do with the code, it's released to the customers. As a company we have made arrangements that if we decide that we discontinue the application, it's also released to the customers. 'To the customers' means that the sourcecode is opened to the customers, that is the sourcecode of the designer, all other code is already open.

Since the birth of computers, there have been many wars, most of them created by IT Technicians/Consultants ...

The computer war - IBM v ICL v etc... Then the Unix v VMS v DG/AOS war the Unix wars - AIX v Ultrix v SCO v etc Linux v Windows Lotus Notes v Exchange

and so one....

each camp had 'good' reasons for their perticuler choise...but commercial reasons forced events. These are:

Costs - What will be the cost of developing a Entlib bases DAL ; compare that to the few minutes it takes to 'build' a LLBL bases 'DAL'. Conservative estimates are that there is a minimum of 30% savings on the overall project costs.

Risks - There are quite a few risks that get mitigated when LLBL is part of the solutions...technical skills, DAL testing, just to name a few

Time to market - Whilst the 'traditional developers' are building the Entlib based DAL, the LLBL boys are working on BL and refining reqirements with the users. LLBL project will be out of the door first.

{edit} try to involve in these decision a commercially minded person such as the sponser of the project, IT director, project manager