Are you a .NET development shop, or a Microsoft development shop?
I am not sure if the market has clearly stated that there is a difference between being a Microsoft shop and a .NET shop. I watch a lot of places try to decide which way to go without realizing they are actually making the choice. Once you've gone far enough down one of the paths it becomes very dificult to turn back. I am not talking about allowing opensource through the door, I am talking about choosing products (open source or not) other than what Microsoft has available when their solution is within budget and meets the functional requirements of the need.
I see this happen for multiple reasons. The most obvious reason is because someone has sold the man (or woman) with the money on the idea that they should not put all there eggs in one basket. Just that analogy is stupid. Imagine carrying 12 baskets instead of one to get your eggs home. Then if you want to keep them cool not all the baskets are going to fit in one fridge. You may say that is good in case one of the fridges goes out. Well, you usually have eaten all the eggs or they have gone rotten by the time the fridge goes out.
Two examples of not wanting to put all the eggs in one basket-
-- I have seen this on a huge government project. They chose AquaLogic over SharePoint and then still forced development to be done in .Net. What a nightmare. That wasted millions of dollars on integration development, which still is not being done right years later.
-- I’ve watched Crystal Reports chosen over SQL Reporting Services (which they already owned with SQL Server) several times, strapping the projects into spending tons on Crystal support in the coming years.
Another reason for choosing tools other than Microsoft tools is lack of experience in enterprise level developers. Some come from smaller shops where open source is the way of life. It has to be in order to afford things. They come into the enterprise shop and all they know are the tools they learned in the smaller shops, so those are the ones they are allowed to continue to use. Others are just open source junkies. They want .NET, but Microsoft sucks, so at every opportunity they are reaching for any tool not coming out of Microsoft. It’s the cool thing to do. I see this a lot in the context of choosing between patterns and practices tools and their equivalent. If you are a Microsoft shop, you'll be using patterns and practices tools, unless they cannot meet the technical requirements you need. If you’re simply a .NET shop, any toolset will do.
I not only see this happen with open source tools, but I see toolsets being chosen that cost a bundle, upfront and down the road. I have seen teams convince management they must have the latest UI toolkit in order to implement the same functionality they could have implemented with the AJAX Toolkit or other out of the box controls. This adds tons of maintenance overhead to the project, time is needed to learn the tools, and licensing cost continues on forever. I can’t count how many times I have seen this, and the tools were not needed, not even close.
Again, let me be clear, if Microsoft does not have the tool available then you have no choice. Some examples are Rules Engines, UML tools, process authoring tools, and MDM solutions. Microsoft's rules engine is buried in BizTalk, their MDM solution has only matured to the point of being a decent reference table manager, Visio is good for pictures but not documentation like SPARX EA, and the Process Template Editor is still in bad shape when compared to EPF.
The advantages to having all your eggs in one basket and trying to stick with Microsoft tools are many. The top one is Modifiability (my favorite Quality Attribute) achieved through greater cohesiveness in your overall toolset. The different Microsoft teams have greater insight into the roadmaps of fellow team’s products, and that helps with integration plans. Choosing a partner product usually achieves the same results since Microsoft is committed to sharing with them.
In the end, when I am in a Microsoft shop, my rule of thumb is show me why we cannot use the Microsoft product, and then we will consider something else. Not all shops are Microsoft shops, and that is ok, but you should figure out what you are, and then move forward accordingly if you want to make life easier.
I see this happen for multiple reasons. The most obvious reason is because someone has sold the man (or woman) with the money on the idea that they should not put all there eggs in one basket. Just that analogy is stupid. Imagine carrying 12 baskets instead of one to get your eggs home. Then if you want to keep them cool not all the baskets are going to fit in one fridge. You may say that is good in case one of the fridges goes out. Well, you usually have eaten all the eggs or they have gone rotten by the time the fridge goes out.
Two examples of not wanting to put all the eggs in one basket-
-- I have seen this on a huge government project. They chose AquaLogic over SharePoint and then still forced development to be done in .Net. What a nightmare. That wasted millions of dollars on integration development, which still is not being done right years later.
-- I’ve watched Crystal Reports chosen over SQL Reporting Services (which they already owned with SQL Server) several times, strapping the projects into spending tons on Crystal support in the coming years.
Another reason for choosing tools other than Microsoft tools is lack of experience in enterprise level developers. Some come from smaller shops where open source is the way of life. It has to be in order to afford things. They come into the enterprise shop and all they know are the tools they learned in the smaller shops, so those are the ones they are allowed to continue to use. Others are just open source junkies. They want .NET, but Microsoft sucks, so at every opportunity they are reaching for any tool not coming out of Microsoft. It’s the cool thing to do. I see this a lot in the context of choosing between patterns and practices tools and their equivalent. If you are a Microsoft shop, you'll be using patterns and practices tools, unless they cannot meet the technical requirements you need. If you’re simply a .NET shop, any toolset will do.
I not only see this happen with open source tools, but I see toolsets being chosen that cost a bundle, upfront and down the road. I have seen teams convince management they must have the latest UI toolkit in order to implement the same functionality they could have implemented with the AJAX Toolkit or other out of the box controls. This adds tons of maintenance overhead to the project, time is needed to learn the tools, and licensing cost continues on forever. I can’t count how many times I have seen this, and the tools were not needed, not even close.
Again, let me be clear, if Microsoft does not have the tool available then you have no choice. Some examples are Rules Engines, UML tools, process authoring tools, and MDM solutions. Microsoft's rules engine is buried in BizTalk, their MDM solution has only matured to the point of being a decent reference table manager, Visio is good for pictures but not documentation like SPARX EA, and the Process Template Editor is still in bad shape when compared to EPF.
The advantages to having all your eggs in one basket and trying to stick with Microsoft tools are many. The top one is Modifiability (my favorite Quality Attribute) achieved through greater cohesiveness in your overall toolset. The different Microsoft teams have greater insight into the roadmaps of fellow team’s products, and that helps with integration plans. Choosing a partner product usually achieves the same results since Microsoft is committed to sharing with them.
In the end, when I am in a Microsoft shop, my rule of thumb is show me why we cannot use the Microsoft product, and then we will consider something else. Not all shops are Microsoft shops, and that is ok, but you should figure out what you are, and then move forward accordingly if you want to make life easier.
posted by tadanderson at 5:46 PM
0 Comments:
Post a Comment
<< Home