<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Do The Math: Third Party Add-Ons Are Your Friend</title>
	<atom:link href="http://mikefitzmaurice.wordpress.com/2008/06/25/do-the-math-third-party-add-ons-are-your-friend/feed/" rel="self" type="application/rss+xml" />
	<link>http://mikefitzmaurice.wordpress.com/2008/06/25/do-the-math-third-party-add-ons-are-your-friend/</link>
	<description>Mike Fitzmaurice commenting on SharePoint technology, Nintex technology, and sundry miscellany</description>
	<lastBuildDate>Fri, 02 Oct 2009 12:37:17 +0000</lastBuildDate>
	<generator>http://wordpress.com/</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: AlphaAlien</title>
		<link>http://mikefitzmaurice.wordpress.com/2008/06/25/do-the-math-third-party-add-ons-are-your-friend/#comment-59</link>
		<dc:creator>AlphaAlien</dc:creator>
		<pubDate>Wed, 10 Jun 2009 18:00:42 +0000</pubDate>
		<guid isPermaLink="false">http://mikefitzmaurice.wordpress.com/2008/06/25/do-the-math-third-party-add-ons-are-your-friend/#comment-59</guid>
		<description>For my work, we tried for a long time to avoid customization due to fear of maintainability. While I personally could manage and redeploy/extend functionality no one else in the organization is trained in how to do so. Due to user requirements over time we have had to do this, and because of this fear I have spent a lot of time documenting and scripting a lot of the basic processes so someone else can come in if I&#039;m gone/unavailable for whatever reason and get something that works in a fairly short period of time.</description>
		<content:encoded><![CDATA[<p>For my work, we tried for a long time to avoid customization due to fear of maintainability. While I personally could manage and redeploy/extend functionality no one else in the organization is trained in how to do so. Due to user requirements over time we have had to do this, and because of this fear I have spent a lot of time documenting and scripting a lot of the basic processes so someone else can come in if I&#8217;m gone/unavailable for whatever reason and get something that works in a fairly short period of time.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard Harbridge</title>
		<link>http://mikefitzmaurice.wordpress.com/2008/06/25/do-the-math-third-party-add-ons-are-your-friend/#comment-20</link>
		<dc:creator>Richard Harbridge</dc:creator>
		<pubDate>Wed, 27 Aug 2008 16:03:04 +0000</pubDate>
		<guid isPermaLink="false">http://mikefitzmaurice.wordpress.com/2008/06/25/do-the-math-third-party-add-ons-are-your-friend/#comment-20</guid>
		<description>The advantage of the third party component to a custom one in a nutshell is that it was developed typically as a product and is deployed to many customers. So the cost is always (seriously, always in my experience) far lower than that of customization (as noted in your comparison).

That said I think what most people miss is that the Deployment Process and Installation Process has seen an incredible change over the past few years. Now the issues with installation and configuration of new (especially well made ones) on new platforms is extremely easy.

Let&#039;s take Nintex and SharePoint, because SharePoint has a model for extensibility and that allows relatively easy deployment of new features, and solutions one of the biggest worries for customization over a third party component is considerably decreased.

The only real issue I see with a third party component is that it is difficult to extend upon (typically) from a deep down code level. But again if the third party (in this case Nintex) is built on a platform like SharePoint the SharePoint API is still the same, so it&#039;s easy to extend upon.

Just my personal opinion. :)</description>
		<content:encoded><![CDATA[<p>The advantage of the third party component to a custom one in a nutshell is that it was developed typically as a product and is deployed to many customers. So the cost is always (seriously, always in my experience) far lower than that of customization (as noted in your comparison).</p>
<p>That said I think what most people miss is that the Deployment Process and Installation Process has seen an incredible change over the past few years. Now the issues with installation and configuration of new (especially well made ones) on new platforms is extremely easy.</p>
<p>Let&#8217;s take Nintex and SharePoint, because SharePoint has a model for extensibility and that allows relatively easy deployment of new features, and solutions one of the biggest worries for customization over a third party component is considerably decreased.</p>
<p>The only real issue I see with a third party component is that it is difficult to extend upon (typically) from a deep down code level. But again if the third party (in this case Nintex) is built on a platform like SharePoint the SharePoint API is still the same, so it&#8217;s easy to extend upon.</p>
<p>Just my personal opinion. <img src='http://s.wordpress.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John</title>
		<link>http://mikefitzmaurice.wordpress.com/2008/06/25/do-the-math-third-party-add-ons-are-your-friend/#comment-15</link>
		<dc:creator>John</dc:creator>
		<pubDate>Fri, 27 Jun 2008 06:18:18 +0000</pubDate>
		<guid isPermaLink="false">http://mikefitzmaurice.wordpress.com/2008/06/25/do-the-math-third-party-add-ons-are-your-friend/#comment-15</guid>
		<description>Hi Jeff/Peter

I completely understand your predictment with third party products being sometimes more hassel than they are worth. With Nintex though and as Robin stated &#039;only&#039; Nintex the process of installing and configuring a workflow is a process that takes minutes literally. I say the hat goes off to the Nintex Guys... what a fab product. To be able to install and to demonstrate the business value to my boss in minutes gave instant gratification to my job. Sure beats me configuring workflows all day long, this makes me look good.</description>
		<content:encoded><![CDATA[<p>Hi Jeff/Peter</p>
<p>I completely understand your predictment with third party products being sometimes more hassel than they are worth. With Nintex though and as Robin stated &#8216;only&#8217; Nintex the process of installing and configuring a workflow is a process that takes minutes literally. I say the hat goes off to the Nintex Guys&#8230; what a fab product. To be able to install and to demonstrate the business value to my boss in minutes gave instant gratification to my job. Sure beats me configuring workflows all day long, this makes me look good.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robin</title>
		<link>http://mikefitzmaurice.wordpress.com/2008/06/25/do-the-math-third-party-add-ons-are-your-friend/#comment-10</link>
		<dc:creator>Robin</dc:creator>
		<pubDate>Thu, 26 Jun 2008 06:15:13 +0000</pubDate>
		<guid isPermaLink="false">http://mikefitzmaurice.wordpress.com/2008/06/25/do-the-math-third-party-add-ons-are-your-friend/#comment-10</guid>
		<description>Hi Mike,

I also a agree but what Jeff is saying is spot on as well.. I guess it also depends on what type of functionality you are bringing in. Maybe the comparison was better if you used Nintex Reporting instead of Nintex Workflow, since building workflows require consulting and Nintex Workflow &#039;only&#039; makes life easier in building and maintaining workflows. 

As in the Reporting product there is not much need to do consulting to get the business requirements because they just want reports about their environment ;)</description>
		<content:encoded><![CDATA[<p>Hi Mike,</p>
<p>I also a agree but what Jeff is saying is spot on as well.. I guess it also depends on what type of functionality you are bringing in. Maybe the comparison was better if you used Nintex Reporting instead of Nintex Workflow, since building workflows require consulting and Nintex Workflow &#8216;only&#8217; makes life easier in building and maintaining workflows. </p>
<p>As in the Reporting product there is not much need to do consulting to get the business requirements because they just want reports about their environment <img src='http://s.wordpress.com/wp-includes/images/smilies/icon_wink.gif' alt=';)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Peter</title>
		<link>http://mikefitzmaurice.wordpress.com/2008/06/25/do-the-math-third-party-add-ons-are-your-friend/#comment-9</link>
		<dc:creator>Peter</dc:creator>
		<pubDate>Thu, 26 Jun 2008 04:14:46 +0000</pubDate>
		<guid isPermaLink="false">http://mikefitzmaurice.wordpress.com/2008/06/25/do-the-math-third-party-add-ons-are-your-friend/#comment-9</guid>
		<description>First, let me state I tooooooooooootally agree. I&#039;m with you. Nintex Workflow specifically saves a lot of time.

Now. I&#039;m sure these will not come as a surprise to you, but let me assume they are. Here are the main problems with buying third-party products:

1. Friction in the buying process. This means everything from budgeting to getting AP to add you as a vendor to getting the license key to install the product.

2. Hassle of installing. I recently worked through installing a small, specific-vertical-targeted third-party add-on, and had to follow a deployment process I&#039;ve named &quot;Call Chuck.&quot; Because there is no installer, the documentation is wrong, and the only hope you have of making progress is to call Chuck, the vendor. As a sort of representative example, it took three tries to make sure I had all the files I needed to install the product. First try was missing files, second try was missing files, ahh, third try: we got em! It&#039;s always great to have demos to assure me you&#039;re not one of &#039;those &#039;call Chuck&#039; vendors, but...the fear is there.

3. Upgradeability/escape plans/long-term plans - Microsoft is a huge company.  is much smaller and is at a higher risk of exiting the market and stranding their customers. I don&#039;t know what you can do to combat these fears, if anything. Demo a Nintex Workflow upgrade to vNext as soon as possible?


All this is just my experience. I&#039;ve worked with other &quot;Enterprisey&quot; applications and they follow these same patterns. I think the SharePoint ecosystem scores well, better on all three points, than the other systems I&#039;ve seen.</description>
		<content:encoded><![CDATA[<p>First, let me state I tooooooooooootally agree. I&#8217;m with you. Nintex Workflow specifically saves a lot of time.</p>
<p>Now. I&#8217;m sure these will not come as a surprise to you, but let me assume they are. Here are the main problems with buying third-party products:</p>
<p>1. Friction in the buying process. This means everything from budgeting to getting AP to add you as a vendor to getting the license key to install the product.</p>
<p>2. Hassle of installing. I recently worked through installing a small, specific-vertical-targeted third-party add-on, and had to follow a deployment process I&#8217;ve named &#8220;Call Chuck.&#8221; Because there is no installer, the documentation is wrong, and the only hope you have of making progress is to call Chuck, the vendor. As a sort of representative example, it took three tries to make sure I had all the files I needed to install the product. First try was missing files, second try was missing files, ahh, third try: we got em! It&#8217;s always great to have demos to assure me you&#8217;re not one of &#8216;those &#8216;call Chuck&#8217; vendors, but&#8230;the fear is there.</p>
<p>3. Upgradeability/escape plans/long-term plans &#8211; Microsoft is a huge company.  is much smaller and is at a higher risk of exiting the market and stranding their customers. I don&#8217;t know what you can do to combat these fears, if anything. Demo a Nintex Workflow upgrade to vNext as soon as possible?</p>
<p>All this is just my experience. I&#8217;ve worked with other &#8220;Enterprisey&#8221; applications and they follow these same patterns. I think the SharePoint ecosystem scores well, better on all three points, than the other systems I&#8217;ve seen.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff Dalton</title>
		<link>http://mikefitzmaurice.wordpress.com/2008/06/25/do-the-math-third-party-add-ons-are-your-friend/#comment-8</link>
		<dc:creator>Jeff Dalton</dc:creator>
		<pubDate>Thu, 26 Jun 2008 01:58:49 +0000</pubDate>
		<guid isPermaLink="false">http://mikefitzmaurice.wordpress.com/2008/06/25/do-the-math-third-party-add-ons-are-your-friend/#comment-8</guid>
		<description>Your argument is interesting.  If the solution was turn key then your value proposition would be dead on.  But with workflow products the real work does not begin until the workflow engine is installed and configured.  That is when you create something of business value.  I am sure you already know this.

What I find is that we spend about the same in terms of consulting $$$ and aggravation even if we use a third party product to make things simpler.  For example early in our SharePoint implementation we decided to purchase the Rad controls from Telerik.  Looking at those we felt that they would save us a ton of time because they had functionality to meet some of our business requirements for content editing.  Well 8 months into the project we now know that Telerik controls ended up saving us nothing because we still had to do quite a bit of configuration to get the control to look and behave the way we wanted too.

So perhaps people are gun shy because they have been burned too many times.

BTW your reporting product looks really interesting.  Our company sees reporting KPI&#039;s as the next big thing from SharePoint.  What I mean is we are looking to the KPI&#039;s to tell the business what ROI has been received from the hugh SharePoint investment.</description>
		<content:encoded><![CDATA[<p>Your argument is interesting.  If the solution was turn key then your value proposition would be dead on.  But with workflow products the real work does not begin until the workflow engine is installed and configured.  That is when you create something of business value.  I am sure you already know this.</p>
<p>What I find is that we spend about the same in terms of consulting $$$ and aggravation even if we use a third party product to make things simpler.  For example early in our SharePoint implementation we decided to purchase the Rad controls from Telerik.  Looking at those we felt that they would save us a ton of time because they had functionality to meet some of our business requirements for content editing.  Well 8 months into the project we now know that Telerik controls ended up saving us nothing because we still had to do quite a bit of configuration to get the control to look and behave the way we wanted too.</p>
<p>So perhaps people are gun shy because they have been burned too many times.</p>
<p>BTW your reporting product looks really interesting.  Our company sees reporting KPI&#8217;s as the next big thing from SharePoint.  What I mean is we are looking to the KPI&#8217;s to tell the business what ROI has been received from the hugh SharePoint investment.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
