Some business rules are complex to capture, and codify into an application. Some examples are when there is company policy that is interpreted (hopefully minimally) slightly differently by different parties, or requires complex analysis when the new system "gets it wrong!".

One example I came across was the logic surrounding whether or not a banking loan application falls within an automated decision process or whether it has to be manually assessed. We took three releases to satisfy all the different business stakeholders. Our issue wasn't so much the actual rule coding, but the actual individual circumstance that swayed the rules engine one way or the other given individual interpretation. Our output of true or false didn't give us any understanding (or the end-user) as to why a certain decision was made.

In the second release, I added a right-click menu item to the "Calculate…" button. This menu allows the user (normally under the direction of the help-desk) to perform the calculation AND populate the Windows Clipboard with a small text based diagnostic report detailing the following aspects –

1.   The data it is ACTUALLY using for the decision – in many cases we were incorrectly gathering this data, making our result difficult to predict
2.   A step-by-step progress – Step 1 (Parties over 18 years old) : PASSED, Step 2 … etc…
3.   The date, time and user logged-in
4.   The version numbers of all assemblies and rules loaded

The end-user would then email this to our team as part of an "In My Opinion – You Got it Wrong" bug report. These reports allowed our Business Analysts to quickly isolate an issue, or more commonly a mis-understanding by the end-user as to actual bank policy! We quickly took a major unstable area and by the next version reports were almost zero (at least a 95% decrease in one release).

The key takeaways for me were –

1.   When a feature has many stakeholders, or the feature might be complex to remotely diagnose – consider adding some features to support the help-desk gathering the information you need to improve that feature over time
2.   Building diagnostic reports into the Clipboard was a very low impact way of getting data from end-users, and was easy for the helpdesk to explain
3.   Make the features obscure (although easy for the help-desk staff to tutor end-users). You don't want these features negatively impacting the user experience for normal cases
4.   Consider privacy issues. Only expose underlying data that you actually need. No personally identifiable medical results :-)

Troy.

In the previous articles on dFM, we covered the basic concepts and how to determine the basic factors. This posting explains a simple process for building a matrix from these factors that will allow you to "cost" a scenario. A "scenario" is an option for building and architecting a software application. We then score this scenario using a score-card (described here), to compare the various scenarios.

This is a common weighted scoring system for decision support. Its not a perfect system; the subjective weighting are controlled to a degree by a democratic voting system, but a single factor could still play an unfair pivotal role in a final score for a potential scenario. This technique is shown to spark some ideas, not as a prescriptive technique.

Step 1 -  Brainstorm a set of factors that influence - cost, time, performance, security, and reliability.

Step 2 - Group similar factors under a topic heading

Many of the brainstormed factors can and should be measured by one metric. An example might be the number of web servers, and the number of database servers. This can be joined under the single topic heading "Number of Servers Required"

Step 3 - Build the "Scoring Matrix" for each group.

The complexity in this step takes an absolute measurement and maps it to a simple 1 to 5 score. All measures should be 1 being lowest "cost, effort, time, best performance, most secure, most reliable" and 5 being the opposite direction.

(These are just very simple samples. The list and scores are completely fabricated in this picture)

Step 4 - Determine the factor weightings (what is more important than what)

I have three basic approaches for this -

  a) You just decide relative importance and allocate weightings subjectively! Great if you can get away with it, but the intention of Design for Manufacturing is to find the "best" design from a balanced set of design objectives. If we just designed software for ease of development, we may not fully consider the operational aspects and the cost of ownership over time.

  b) Paired Options (or Pairwise comparison): Get the group of people representing different domains of expertise (operations, development, business, marketing, sales) together again and have them vote A versus B, A versus C, etc. to determine what is more "important" to that person. Take an average measure of the room (more think A is more important than B). Total up the number of votes for each factor, and determine what percentage that total is of the entire selection. % weight = (count / total pairs (15) ) * 100

  c) * my preferred* Stack ranking: Get each representative from each domain specialist (operations, developers, business, storage, etc) to stack rank the factors, most important to least important. This will uncover and account for individual biases. It is my preferred method because it also allows people to say "No Impact" for a specific factor on a "perspective" of the factor. Total up the relative ascending score (assign 1 to the lowest row that was a factor, and 2 to the next one up, and so on) and determine what percentage that score is of the total points available. This will look something like this -

Consider doing this for more than one perspective. E.g. As far as Cost, how would you rank importance. As far as time to market, how would you order these factors. What you are looking for is a way to mathematically represent that one factor has a much higher impact on a desired delivery "factor". Some axis of ranking might be:

    1. Capital expenditure - Upfront cost

    2. Operational Expenditure - Ongoing costs

    3. Time to market - How quickly can it initially be developed

    4. Performance - hitting agreed service and performance levels

    5. Security - what factors make a system more secure

    6. Reliability and Stability - what factors make a system able to handle failure more gracefully)

Whatever method you employ, the outcome needs to be a table of the factors, and a weighting multiplier, E.g.

    Number of Servers Required - 24%

    Bandwidth - 20.6%

    Searches / sec - 10.3%

    Number of Deployment Items - 17.2%

    Number of Third Party Components - 13.7%

    Number of Features - 13.7%

Step 5 - Score a Scenario and Multiply By Weights

Break out excel. Use the scoring sheet from Step 3 to score a scenario. Multiply each score by the weights determined in Step 4. Total all of the weighted scores. Do this for other scenarios to compare.

In the next installment of this article series, i'll demonstrate this basic technique with some real examples and prepare a final spreadsheet template you might find useful in doing your own option analysis.

Troy.

Its often difficult on large projects to keep track of all the additions as a system grows. When a project grows, it gets more difficult to keep all system drawings accurate and correct. If a drawing isn't automatically generated, then you can have little faith that it is absolutely up-to-date.

The alternative is to write tools that examine the code and draw representations of the systems continuously. This can be part of a nightly build, or a tool that can be run on-demand in order to make better decisions, resolve design issues early, and identify impact of changes.

In this instance I was having trouble keeping up with what Web Services we had; What Stored Procedures they relied upon, and what SQL Server tables those Stored Procedures depended upon.

The application we wrote in a couple of days simply hunts through all *.cs files and uses Regular Expressions to find applicable code. It then uses Microsoft Research's Graph Drawing Tool "GLEE" to visually represent it. GLEE is incredibly easy to use and integrate. The following screen-shot (with the sensitive names removed) took less than 15 lines of code to produce (and a few hundred to do the Regular Expression hunting).

A side-benefit of this tool is that it forces the team to conform to the coding standards. If they want their new code to be incorporated into the latest drawings, follow the patterns provided.

Its great to come into work each morning and see what has been added, and to ensure that the cross-coupling even at the database level isn't going to cause use duress later in the project. We can quickly see what a DB schema change will impact. Sleeping much better now....

Troy.

I've just been reading a well thought out article on Option Theory applied to software - "Real Options" Underlie Agile Practices, posted by Chris Matts and Olav Maassen.

I like the concept, and its common sense approach resonates well with my beliefs. I'll try and summarize, but you should read their article for the full story.

There are three possible decisions when faced with an option (in our case, an approach, an architectural choice, an implementation choice, etc) -

1. Yes
2. No
3. No Decision Yet

The 3rd choice is often overlooked and a decision is made earlier than it needs to be, curtailing any chance that you will learn more information and make a superior choice later on. The authors explain that when listing options, it is important to define when the true "must have a decision point is" for each option, and passing one of those "drop dead" points is actually making a decision "No" for an option.

The key points for me from this article were:

1. List options early, and keep looking for new options
2. Determine what the true last possible time an option is still viable, and regularly assess if these change due to other decisions
3. Make a solid "Yes" decision for an option at the last possible moment - this leaves open the opportunity for newer options to emerge

I came across this article by looking up the speakers at a local upcoming conference in Seattle. The authors are speaking at the APLN Agile Leadership Summit in Seattle (July 17-18).

Troy.

What are factors?

Factors represent an issue, or a requirement that has an impact on the final "cost" of a product. In electronics, a "cost" will either be an increase in monetary value of building an item, or an increase in time to delivery. "Costs" in the software domain might be -

• Cost of hardware or hosting monthly fee(s)
• Increase in time to develop or deploy
• Compensating technology required for security, or risk mitigation

This isn't a complete list, but its a good start. Our ultimate goal is to define a set of "Weighted Factors" that we will use to score a particular design option. But first, lets explore the different types of Design Options, and explore a few examples in the Software engineering domain.

Key Point: Each factor varies in how linearly it will effect the "cost" value. Higher costs are bad, lower costs are good. Costs will be normalized by the weighting scale applied to each factor to ensure one factor doesn't overly control the outcome.

Types of Factors

Binary Decision Factors

Binary factors are those constraints that are an absolute Go or No-Go. Any factor that will clearly eliminate an option should be the first criteria analyzed. If a certain criteria is met (or not met), the highest cost should be assumed - ensuring that this option can never be chosen (not without due negotiation anyway!)

Tipping Point Factors

Some factors have no "cost" impact until they pass a certain threshold. An example might be disk space use. Until your product passes the requirement to need more than 100MB of disk space, there is no cost; After that you pay a premium. These factors need to place the lowest cost on a factor, once the tipping point is reached, the factor must assume the highest cost ensuring this option cannot be chosen, otherwise this factor should be zero and not impact the rest of the decision tree.

Scaled Factors

These are general quantifiable factors. The offer a mechanism to determine (and indicate) how a factor impacts cost. E.g. Adding an extra business service layer will increase the deployment complexity and may need extra servers. We'll discuss how to formulate a scale for these factors in a future article, but in this example you can imagine that adding servers has a cost, and each extra architectural layer increases the cost accordingly.

Determining the Relevant Factors

This is the crux of the story. We need to identify the factors that we will score. There is no master list of factors to draw upon. It is important that each factor fall into a category listed above - Binary, Tipping Point or Scaled.

The basic process is to get all the stakeholders into a room and extract (brainstorm) factors that will in their opinion cause an extra cost. No factor is too small at this stage (we'll filter them later), just keep the crowd focused on identifying issues that can increase/decrease effort, cost, time and risk.

By then end of a session you should have a stack of post-it notes littering a whiteboard. Use post-it notes so that you can join and link duplicate concepts and ideas. If you involve the right people, you should end up with a big list of factors. How many are too many? Impossible to quantify, but once a list of Factors is defined, the weighting process should spotlight those factors that fall below a level that will alter any outcome. These factors can then be dropped.

I've not got a complete list, or even a recommended list at the moment. Hopefully sometime in the future I'll have something more, but for the fact of this article, here are a few I jotted down in three minutes (some overlap, some are duplicate, some can't be measured, and some don't make sense at all - all problems to look at later)-

• Bandwidth utilization
• Disk space required
• Number of Architectural Layers
• Database size
• Number of Database Objects
• Number of different development languages
• Number of different technologies
• Number of integration points
• Number of external partners integration points
• Number of config settings, and ease of changing
• Production event logging, how much, to where, how often?
• Ease of deployment
• Number of Servers
• Number of third party components
• Ease we could host at a co-located facility

In future articles, we'll look at how to take this list and refine it down to a manageable set, and how we would scale and weight each factor.

Troy.

In electronics design, many elements can directly impact the cost of manufacturing a product. DfM aimed to move the tradeoff analysis for decisions affecting manufacturing as early as possible in a design phase. I'll attempt to move this into the software architecture realm in a future article, but for now I want to explain how this worked in Electronic Product design.

What design decision matter in Electronics?

In electronic product design, here are a few to start your thought process -

Component Selection - Choosing components from an approved supplier and components that meet requirements but don't exceed specification (giving latitude to safety margins) directly impact cost of an item. Assisting engineers choose preferred part, parts already purchased and in inventory, and offering alternatives can really decrease costs and improve turnaround time.

Printed Circuit Board Size and Shape - Small PCB's aren't made one at a time. They are panelized onto larger sheets, fabricated and even assembled (components positioned and soldered into place) in that form before being broken apart and put into their cases. The more individual boards you can fit to a panel, the less waste and fewer panels need to be moved through auto-assembly equipment.

Printed Circuit Board Technology - If you make the board smaller to fit a certain device, you often need to add 'layers' for interconnecting components. This adds cost; If you make individual features smaller to fit more interconnects onto fewer layers, the manufacturing yield decreases due to mis-registrations. Its a real trade-off and highly dependent on your partners capabilities.

Printed Circuit Board Hole Count and Sizes - For some PCB technologies, drilling holes can be time consuming. Smaller holes needs to be positioned more accurately and these drill bits break more often. Normally, fewer holes of larger sizes is the cheapest way to go; However, some PCB technologies don't incur a cost per hole - which one will you specify?

Component Placement - Where is it safe to put large components? Where will the battery connect? Where are the pushbuttons? All of these decisions need to be considered when the PCB is being designed - BUT they seriously impact the final case design. How can the electronics designers and the mechanical (and brand) designers collaborate to agree on an acceptable design? For extremely high volume designs, placing similar components in the same orientation can reduce the number of machine rotations and component reel changes which reduces the total time of assembly. Saving 1 minute for 1 million pieces is substantial!

Early Focus and Scoring Matrix Definition

Design for Manufacture initiatives aimed to bring focus on the types of decisions made above and allow engineers and designers to perform trade-off analysis as early as possible in the process. The product might have to be smaller than a competitors and that forces a smaller PCB size and shape, which then causes a specific choice of technology - However, the key aim was to understand that early and make informed choices about which remaining options fulfill the global good.

To build a Report Card or Scoring Matrix, the basic process is -

1. Get together with all of your partners, suppliers, fabricators and designers and brainstorm a set of issues that impact cost. Similar to the list provided above, the idea is to get the 'issues list' on the table.
2. Group these issues into a sub-set that can actually be measured and scored. E.g. "Number of boards per panel", "Number of holes smaller than 0.5mm", "Number of different components types", etc.
3. Determine relative weighting for each measurement. Some requirements cannot be broken, other just incur a cost. I'll propose a process for determining this weighting in a future article; for now, just understand they won't all have the same weighting factor.
4. Build the scoring scale for each factor. This step tries to normalize the different scales of measurements into a smaller linear set (i.e. 1 to 5, rather than 1 to 1 million for one factor, and 1 to 10 for another)
5. Calibrate the scorecard by testing on existing systems. Agree and alter the specific factor "Weightings" until you gain confidence in the scorecard
6. Use the scorecard on future design discussions.

Summary

Is it just as simple as substituting "IT Operations" for "Fabricators"; "Usability/Interactive Designers" for "Packaging Designers"; "External Hosting Partners" for "Suppliers"? 

In future articles i'll look deeper into -

• How to build a weighted score card based on issues relevant to software
• Propose some software specific issues and attempt to weight those appropriately
• Test our new scorecard and determine if it is achieving the goal we intended.

Be interested in comments as to whether other people agree there might by parity between DfM in Electronics to DfM in Software.

Troy.

I started out in the electronics engineering field, and moved into the software side of electronics design automation business shortly after that. Back in the early 1990's a lot of effort was being put into Design for Manufacturing. This was in the recognition that very small decisions made early by an isolated engineer, could have massive consequences down the road impacting costs. There were a few leaders and advocates in the field, mainly from HP and IBM at the time.

One incident recalled by Happy Holder, a HP engineer at that time was the reduction in cost of the HP Laserjet III printers. By altering the size of the main printed circuit board size by a few inches one way, they were able to double the production yield of that assembly, halving the raw material cost of the PCB. Happy Holden and IBM's Tucker Garrison at the time came up with a few simple methods for evaluating designs and allocating a report card. The most complex part of the process was getting the right people in the room to agree on the right criteria to measure, and to weight those measurements in the right way.

Manufacturing optimization comes down to improving production yield (reducing waste) and speeding up the process (reducing touch time); These principles are well known to all those proponents of Lean Manufacturing and Theory of Constraints. This book is a good start - Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results (The Coad Series).

Is software yield (throughput) equivalent to DFM for Electronics "Speeding up the process"? The aforementioned books clearly describes the process of improving throughput by reducing the waste and understanding the current blocking issues. But I cannot find a process that brings focus of the cost of decisions back to the earliest possible decision point, when it is relatively simple to move many directions.

It seems obvious there is room for innovation here. Provide a framework (what DFM calls report cards) that developers and architects can use to assess possible solutions and designs for a requirement. I plan over the next few weeks to explain how the Electronics DFM process worked, and suggest a few techniques that might improve our up-front decision making process.

Troy.

How much up-front design or architecture to do in an agile project is always a contentious issue. Having the job title with "Architect" in it makes me personally biased; Having a background as a developer and product manager in successful agile XP gives me a huge respect for agile development practices and somewhat balances my development approach. This posting tries to define my current view on how to balance good up-front architectural planning (minimal, but where it counts) and how to assess whether more or less architectural oversight needs to be applied during a project through intervention.

Many agile scenarios promote that a project be split in a set of features; These features prioritized into milestones by the "Customer" and then these features be worked in in almost a serialized fashion. The focus is on completing the current feature, whilst promoting that refactoring be the tool of choice when a later feature adds or alters a previously signed-off complete and closed item.

I can see some issues with this when followed blindly. My definition of "Refactoring" centers on improving currently functional code with lessons that emerge throughout a project. What I see in many projects is that "Refactoring" is the title given to an almost rewriting of a previously closed feature because the number and scope of changes to keep it operating in the face of the new feature. This is bad, and it is seriously affecting development velocity.

Here is my proposed compromise, that allows features to be built in (semi)-ignorance of future features, whilst still allowing for intervention if a pattern of serious re-writing (or refactoring if you want to water the terminology  down) begins to affect velocity -

• Up-front architecture that should always be carried out as iteration 0 of any project includes anything that WILL BE NEEDED for EVERY feature (or requirements that will cause a registration of almost every feature that has already been completed). This includes technology choices, communication and integration patterns, operational requirements like logging, deployment strategy and localization requirements can be used as a starting list.
• At regular intervals (e.g. 1/4, 1/3, 1/2, 2/3, 3/4) of the way through features in a project analyze the task breakdowns of the latter features to determine if there is a class of task that might be eliminated by an architectural building block or by more holistic design/planning

It is the second bullet point I want to discuss further in this posting.

My boss David Anderson run a pretty tight Lean Software software development department. A lot of the lean principles are facilitated by using a Kanban tracking system (and its electronic counterpart being the data captured in Microsoft TFS). The data captured is very thorough and used as a management tool in determining progress, bottlenecks and general project health. My goal is to use the feature and tasks completed so far to assist in determining where architectural intervention or more up-front planning could avoid that class of task being necessary in future work.

Lets look at an example - In a current project that is very integration heavy with a large ERP/CRM system, that our lack of solid planning for the interface specifications (which weren't ready when we started, but are available now) is cause way too much rework as we move through the features in a linear fashion. It way pay dividends in team velocity to introduce a feature right now that looks at the spectrum of interface specifications we now have and strawman the entire message / web service interfaces. If this reduces the number of tasks in future feature that would have revisited completed interfaces and added that extra field, or changed that database schema - improved velocity is inevitable.

But there is a balance - striving for perfection in this planning intervention would also be catastrophic to feature completion velocity. Going overboard with architecture is just as evil as sticking ones head in the sand and simply working longer hours or hiring more developers to close the backlog gap.

Be interested if other teams have analyzed task types to look for patterns or work that might be eliminated by a targeted architectural focus.

Troy.

I've often heard and seen large teams struggle when implementing some agile project practices in large enterprises. I recently joined Corbis who were using many agile practices (introduced by my boss, David Anderson who wrote Agile Management book), but Continuous Integration and Automated Builds weren't on the list.

We discussed why CI was needed for a while, and then successfully implemented it. During this process, I kept careful notes on the barriers we encountered and how those barriers were overcome. On David's urging (I mentioned he was by boss right and does my reviews), I put together this draft article (Continuous Integration at Enterprise Scale.pdf (681.47 kb)). I'm keen to hear feeback on it.

Here is the Introduction -

Introduction

Continuous Integration and an Automated Build process are common practices employed by many high-functioning agile software teams. Many small teams are reporting high productivity improvements, but success stories of Continuous Integration and Automated Builds for Enterprise Scale software projects are much rarer. Some agile pundits have stated that there is a scale limitation for agile practices and these practices are in-appropriate for Enterprise Scale (or high staff count) projects.

This article aims to explore if and why the measurable benefits of Continuous Integration and Automated Build processes begin to decline as application size, and team size grows.

Our conclusion is that there is no inherent reason why Continuous Integration and Automate Build processes won’t scale to any size team. In fact, this article concludes that the problems these techniques solve are a higher pain point for Enterprise Scale applications and become more essential than ever. In addition, this article provides guidance on how to scale agile practices and how to make smart architectural choices up-front to ensure smooth adoption of Continuous Integration and Automated Builds leading to smoother projects and improved success rates.

Interested in your thoughts....

Troy.

Continuous Integration at Enterprise Scale.pdf (681.47 kb)

How can we put a price on or demonstrate one system architecture against a proposed (or actual) new system architecture? For instance, how can we predict in advance if a major project is going to require a reduction of increase of staff to maintain? Or is it more important that a proposed architecture position a company in a position where it can respond to market pressures with more agility?

I'm currently trying to generate such number to assist our management team with real factual data to support decisions. My problem is - I can't find a lot of material on this subject via Google! So I'm throwing it out there to you guys to give me some ideas.

Here is my basic approach -

1) Find facts we can measure about the hardware environment pre and post project

2) Find facts we can measure about the software architecture pre and post project

3) Segment the companies over 120 software assets into major groupings of 5 areas (trying to analyze 120 product is too fine grained to be of interest).

4) Put all this data into excel, and do a weighted scale matrix for each measure. Total, Graph and Summarize...

I think it will turn out to be easy to demonstrate a "Better" or "Worse" indicator; But I want more - I want an actual score indicator that we can use to determine cost of ownership over time. I want to demonstrate a payback on investment in software architecture that may not be demonstrable through a sexy new website feature.

For the moment - I'm still looking at what variables we can measure (Steps 1 and 2 above). System measurement is basic enough - number of servers, number of upgrades per year, number of helpdesk calls. However software architecture become a little more interesting. Recently I did a quick option analysis and came up with three easier metrics to compare three architectural solutions.

What other metrics have people considered or used in the past when scoring software architecture?

Troy.

I got this email today posted from the HookedOnLINQ Wiki I host:

Troy -- 

	I am a new developer to the LINQ framework and had a few questions that I hope you can field.  
	

	Looking at a broad overview of LINQ, I see it as a way to simplify development, but it also raises a few other questions.   As most devs, I've been using the N-Tier architecture for having my applications access the data stores, requesting stored procs to do the processing, and returning the information that I'm interested in.  
	

	Is LINQ providing a way to eliminate the uses of stored procs, or is it just providing a more intelligent way to access the data?  
	

	For instance, in the past the way I have handled data access would be to have a separate class that shadows my stored procedures in my database.  When ever I would make a stored procedure, I would then have to go into my database interface class and create a subroutine with matching signatures to the stored procedure.  It would provide error checking, execute the data access object, then return a dataset for further processing.  From there it would loop through the dataset and display information as required.  
	

	When I think LINQ, the first thing that pops into my head is, will this eliminate that second layer?  Does LINQ provide a way to directly access the database without having to go through the process of constantly of creating a procedure, changing my code, and redeploying. 
	

	I've also had it hammered into me in the past that Inline SQL from within my code is a bad idea due to maintenance concerns.  
	

	As you can see, I am a bit confused.  I went over the 5 minute prep on your website, and understand manipulating objects with LINQ, but I'm not sure I get the whole picture. 
	

	Appreciate it, 
	

	G... 
	

All very good questions. I tried to answer some of them, but I must confess - I'm really interested to see what LINQ's impact is over the next few years.

	Hi G..., 
	

	I think the full LINQ story and what code it will replace is unfolding. Although I'll take a shot at answering some of your excellent questions: 
	

	1. LINQ to SQL can be used in a way that eliminates the need (in the vast majority of cases) for writing and maintaining Stored Procedures. You can write LINQ queries, update the returned object structure and apply changes back to the database without stored procs. 
	

	2. For LINQ to SQL to operate it needs to map its data entity classes to your database. You essentially have Three options, 
	

	    a) markup your own classes using LINQ .NET attributes ie. [DataColumn] 
	

	    b) use the DBML designer and drag tables from the Server Explorer in Visual Studio 
	

	    c) use an XML mapping file to link database objects to classes 
	

	    You do need to keep these in synch when you database structure changes. This will be interesting to see how teams solve this problem. 
	

	3. Inline SQL is bad from a "SQL injection" perspective (where malformed input into a text box could cause SQL you didn't really plan for being executed on your server). The mitigation for this is to pass data to the database via SQL parameters. LINQ does this (as do stored procedures, which is why they were the traditional workaround" 
	

	4. I think with LINQ, you are maintaining C# code which is type safe and checked during compilation. Inline SQL is just a string and you will only see it fail when it is executed (hopefully on a test box before it reaches production!). The jury is still out as to what maintaining over time a large amount of C# LINQ to SQL queries will be like - But until then, enjoy the intellisense, type checking and working in one coding language instead of two! 
	

	Hope this helps a little. Feel free to ask for clarifications, 
	

	Troy Magennis 
	

Did I answer G....'s questions?

Troy.