I totally disagree that Internal software is non-differentiating. In the age of the Internet where many companies are still looking for ways to take advantage of it to gain a competitive advantage (instead of just playing catch-up), I don't know how you could make such a blanket statement. Not only that, but aggressive adopters of new technology to run their businesses are often the most successful in their respective markets. Take WalMart for example.
Furthermore, that attitude almost guarantees that OSS will stay in the background because they will be chasing innovations brought about by others. Take some software that could be considered as somewhat non-differentiating - office suites. A lot of the push in the OSS world right now is to replace MS products with OSS, and they are doing so not by coming up with better designed software, but software that uses the same look-and-feel and file formats. Yes, the lower licensing cost is an advantage, but does it really do what software is supposed to do - make people more productive by giving them better access to relavent information? Taken in that light, the licensing cost and the availability of source code pales in comparison of the benefits of more proprietary, but easier to use and customize software. Good and easy to use customization capabilities (eg: scripting) built-into a product are far more valuable than the source code.
In fact, that very line of thinking is what can make software even more differentiating, because a competitor is certainly out there trying to come up with a system that will help him be more competitive. In other words, if the CIO of company 'A' says "I'll use OSS because it is "good enough" and cheaper. IT really doesn't differentiate us." and then the CIO of company 'B' takes the opposite approach and comes up with some killer BI application for the sales people that allows them to win the deal 80% of the time, well you certainly have a differentiator there. Or let's say that a CIO funds an effort to automate workflow based on Office Suite scripting and this allows them to process twice the number of special customer requests per day, thereby making even the Office Suite (the one with the best scripting capabilities) a differentiator.
What I'm doing right now is kind-of neat and I think may be a large part of the future of IT in this country. I'm (a 3rd party) part of a team automating business workflow processes for a large Fortune 500 company - but I'm not doing it for the IT dept., I'm doing it directly for the business group completely outside of IT influence (although we use IT infrastructure and work with IT in that regard). In this context, two huge issues of today have been kicked around:
1) Why not use OSS? Because the same quality of tools aren't there for what we are doing and it is far cheaper for us to license the tools than to re-invent the wheel by modifying OSS tools.
2) Why not offshore outsource? Because the size of the team would have to be increased to provide the business knowledge and business analyis and even then we couldn't guarantee the same software turn-around capabilities, thereby negating any price advantage and probably harming the quality and usefulness of the software. Also, the IT dept. does use offshore outsourcing... We recently had to integrate some of "our" software with "IT's" software, and they use foreign outsourcing. With the responsibiities (amount of customization) pretty much balanced, our estimate for the customization work was 40 hrs. and theirs was 240. And I suspect that their end of things will encounter more problems during the transition as well, because it involves more people of disparate organizations.
I think the "non-differentiating" argument is a big mistake, not only for OSS but vendors out there trying to make the same old processes cheaper, when they should be looking to innovation to make the processes better at supporting core businesses. In other words, we are in a race to the bottom right now, which does not support the potential value of IT to an organization.
Yea - there's terrible poverty there, but the people getting the IT jobs are almost certainly in the upper part of their caste system because of the education it requires. Those weren't the people you saw starving, and just as many of those people are still starving.
A lot of the difference in rates between here and India and China is the strong US dollar. Factor that in and you'll see that there isn't such a huge advantage they have over workers here in the US price-wise. The dollar has to soon de-value on the world market (it's already starting) and then we'll be on a more even playing field in that respect. There is historical precedence for much of this back in the early '90's.
Given that, taking US IT jobs away to give to members of the upper class in India's caste system is not what I would neccessarily call a good thing for India and it certainly isn't good for folks here.
And of course there is the other big issue that the code coming from there - when it happens to actually get finished and follow specs. - often doesn't work.
From what I've seen the only thing reliable the is worth a shit about most code coming in from offshore are the backdoors they put in it.
I think it will be the opposite. The companies that sit back and scoop up the talent that is left behind will be the next darlings of Wall Street.
Custom Software Development - you know, the kind that actually gives a company a competitive advantage - is not like creating shoes, tools or even cars. Good, on-task communication is much tougher and more vital because there are a lot more variables, and poor communication is the #1 reason for SD project failures. Anything that further impedes good communication is not going to be worth the projected savings.
I've also run into a lot of anecdotal evidence lately (via people working on offsourced projects) that suggests Indian firms are having trouble fully staffing a lot of projects right now. And when they can actually fully staff and complete a project, much of it has to be re-worked. This isn't my opinion - just what I'm hearing from others. This is only going to get worse when the true "offshore rush" kicks into high-gear, and the good ones over in India (their IT workforce is still pretty immature) are all taken by the first ones over.
It sounds like this is going to be one of those issues where, like many of the large ERP projects, we don't hear about the failures from the C-level executives (busy covering their asses) until the poor stockholders are left with funding complete re-writes or seeing their investment go to through the bankruptcy courts.
I hope the IT trade rags would start looking for and reporting these failures before the "best-and-brightest" leave the field, or the country, for other opportunities.
There's a throught - write InfoWorld, eWeek, etc. and give them an idea for their next big headline.
I've designed and written a few.NET apps, and have found them to have extremely good performance ("performance" here always refers to both scalability and snappy single-user response times) on low-end boxes, expecially compared to ASP and JSP.
There have been a couple of posts w.r.t. proper architecture... While arch. is no doubt important, I've found that it is not hard at all to get good perf. out of even a minimal expenditure on arch. for.NET apps. Heck, for a couple of those apps., the team hardly even touched a whiteboard, but just sat down and started rapping out code using good old-fashioned common sense. In my book, follow the KISS principle for.NET apps. whenever possible for architecture and you'll come out way ahead in almost every aspect of performance, time to market, maintainability, etc. Take it from someone who almost blew a multi-million dollar project because of "over-architecting" the application. We got things working fine, but I lossed a lot of stomach lining over the deal, and the customer wasn't too pleased either. Before I jump off of the soapbox on the arch. issue, I always try to remember that just one often used part of an app. can kill scalability, and a complex arch. always makes the bottleneck a lot harder to find and often to fix w/o a re-write.
Here's where I've found the bottlenecks and easy ways to solve them:
1) Don't put SOAP calls in tight loops. If you seem to have to do this, redesign things. This may seem obvious, but the reason SOAP doesn't really scale well on any platform is because of the function call overhead, so minimize that as much as possible. Make sure to cache results local to the caller for stuff that doesn't change very often (see #4 below).
2) For DB updates, use SqlConnection transaction handling instead of MTS whenever possible. In the old ASP/COM+ world, it was imperitive to use MTS so you could take advantage of the other COM+ features, but the.NET runtime removes this burden as long as you don't have to jump through coding hoops to wrap dependent updates, etc.
3) Make sure to use the correct transaction isolation level for your transactions. For highly transactional apps. that also do lookups on the updated tables, the one I've had the best luck with is IsolationLevel.RepeatableRead. I can't stress the importance of this enough - do some rudimentary testing (Microsoft ACT that comes with the.NET IDE installation is fine for most) of the parts of the app. that update the DB and test with different isolation level settings. As long as rule # 1 is followed, this has been the single most important factor in maximizing the scalability of transaction applications, and the default setting for this usually doesn't give the best results.
4) Use HttpContext.Current.Cache and related in your code to cache stuff that doesn't change too often (like product description lookups, etc.), especially for SOAP calls.
5) Adjust the "Minimum query plan threshold for considering queries for parallel execution (cost estimate)" once you move your app. to an SMP system, depending on if the DB server is standalone and how highly normalized the database is. For a highly normalized DB (lots of JOINs) on a standalone SQL Server box, set this at 0 or 1 because most of your queries could probably benefit from a parallel execution plan, or at least the small extra overhead won't really hurt. This setting alone dramatically and immediately boosted the performance of one application and took all of 2 minutes to implement.
6) Make sure to apply indexes where it makes sense. For example, on one app. 4 hours of query research and index tunning based on that provided a 10 fold better response time for one query, which probably increased scaleability for that database by 100 fold because of how often that query was used.
7) Read and follow this simple advice for SQL Server clustered indexes on MSDN:
Slashdot Mirror
I totally disagree that Internal software is non-differentiating. In the age of the Internet where many companies are still looking for ways to take advantage of it to gain a competitive advantage (instead of just playing catch-up), I don't know how you could make such a blanket statement. Not only that, but aggressive adopters of new technology to run their businesses are often the most successful in their respective markets. Take WalMart for example.
Furthermore, that attitude almost guarantees that OSS will stay in the background because they will be chasing innovations brought about by others. Take some software that could be considered as somewhat non-differentiating - office suites. A lot of the push in the OSS world right now is to replace MS products with OSS, and they are doing so not by coming up with better designed software, but software that uses the same look-and-feel and file formats. Yes, the lower licensing cost is an advantage, but does it really do what software is supposed to do - make people more productive by giving them better access to relavent information? Taken in that light, the licensing cost and the availability of source code pales in comparison of the benefits of more proprietary, but easier to use and customize software. Good and easy to use customization capabilities (eg: scripting) built-into a product are far more valuable than the source code.
In fact, that very line of thinking is what can make software even more differentiating, because a competitor is certainly out there trying to come up with a system that will help him be more competitive. In other words, if the CIO of company 'A' says "I'll use OSS because it is "good enough" and cheaper. IT really doesn't differentiate us." and then the CIO of company 'B' takes the opposite approach and comes up with some killer BI application for the sales people that allows them to win the deal 80% of the time, well you certainly have a differentiator there. Or let's say that a CIO funds an effort to automate workflow based on Office Suite scripting and this allows them to process twice the number of special customer requests per day, thereby making even the Office Suite (the one with the best scripting capabilities) a differentiator.
What I'm doing right now is kind-of neat and I think may be a large part of the future of IT in this country. I'm (a 3rd party) part of a team automating business workflow processes for a large Fortune 500 company - but I'm not doing it for the IT dept., I'm doing it directly for the business group completely outside of IT influence (although we use IT infrastructure and work with IT in that regard). In this context, two huge issues of today have been kicked around:
1) Why not use OSS? Because the same quality of tools aren't there for what we are doing and it is far cheaper for us to license the tools than to re-invent the wheel by modifying OSS tools.
2) Why not offshore outsource? Because the size of the team would have to be increased to provide the business knowledge and business analyis and even then we couldn't guarantee the same software turn-around capabilities, thereby negating any price advantage and probably harming the quality and usefulness of the software. Also, the IT dept. does use offshore outsourcing... We recently had to integrate some of "our" software with "IT's" software, and they use foreign outsourcing. With the responsibiities (amount of customization) pretty much balanced, our estimate for the customization work was 40 hrs. and theirs was 240. And I suspect that their end of things will encounter more problems during the transition as well, because it involves more people of disparate organizations.
I think the "non-differentiating" argument is a big mistake, not only for OSS but vendors out there trying to make the same old processes cheaper, when they should be looking to innovation to make the processes better at supporting core businesses. In other words, we are in a race to the bottom right now, which does not support the potential value of IT to an organization.
Yea - there's terrible poverty there, but the people getting the IT jobs are almost certainly in the upper part of their caste system because of the education it requires. Those weren't the people you saw starving, and just as many of those people are still starving.
A lot of the difference in rates between here and India and China is the strong US dollar. Factor that in and you'll see that there isn't such a huge advantage they have over workers here in the US price-wise. The dollar has to soon de-value on the world market (it's already starting) and then we'll be on a more even playing field in that respect. There is historical precedence for much of this back in the early '90's.
Given that, taking US IT jobs away to give to members of the upper class in India's caste system is not what I would neccessarily call a good thing for India and it certainly isn't good for folks here.
And of course there is the other big issue that the code coming from there - when it happens to actually get finished and follow specs. - often doesn't work.
From what I've seen the only thing reliable the is worth a shit about most code coming in from offshore are the backdoors they put in it.
I think it will be the opposite. The companies that sit back and scoop up the talent that is left behind will be the next darlings of Wall Street.
Custom Software Development - you know, the kind that actually gives a company a competitive advantage - is not like creating shoes, tools or even cars. Good, on-task communication is much tougher and more vital because there are a lot more variables, and poor communication is the #1 reason for SD project failures. Anything that further impedes good communication is not going to be worth the projected savings.
I've also run into a lot of anecdotal evidence lately (via people working on offsourced projects) that suggests Indian firms are having trouble fully staffing a lot of projects right now. And when they can actually fully staff and complete a project, much of it has to be re-worked. This isn't my opinion - just what I'm hearing from others. This is only going to get worse when the true "offshore rush" kicks into high-gear, and the good ones over in India (their IT workforce is still pretty immature) are all taken by the first ones over.
It sounds like this is going to be one of those issues where, like many of the large ERP projects, we don't hear about the failures from the C-level executives (busy covering their asses) until the poor stockholders are left with funding complete re-writes or seeing their investment go to through the bankruptcy courts.
I hope the IT trade rags would start looking for and reporting these failures before the "best-and-brightest" leave the field, or the country, for other opportunities.
There's a throught - write InfoWorld, eWeek, etc. and give them an idea for their next big headline.
I've designed and written a few .NET apps, and have found them to have extremely good performance ("performance" here always refers to both scalability and snappy single-user response times) on low-end boxes, expecially compared to ASP and JSP.
.NET apps. Heck, for a couple of those apps., the team hardly even touched a whiteboard, but just sat down and started rapping out code using good old-fashioned common sense. In my book, follow the KISS principle for .NET apps. whenever possible for architecture and you'll come out way ahead in almost every aspect of performance, time to market, maintainability, etc. Take it from someone who almost blew a multi-million dollar project because of "over-architecting" the application. We got things working fine, but I lossed a lot of stomach lining over the deal, and the customer wasn't too pleased either. Before I jump off of the soapbox on the arch. issue, I always try to remember that just one often used part of an app. can kill scalability, and a complex arch. always makes the bottleneck a lot harder to find and often to fix w/o a re-write.
.NET runtime removes this burden as long as you don't have to jump through coding hoops to wrap dependent updates, etc.
.NET IDE installation is fine for most) of the parts of the app. that update the DB and test with different isolation level settings. As long as rule # 1 is followed, this has been the single most important factor in maximizing the scalability of transaction applications, and the default setting for this usually doesn't give the best results.
There have been a couple of posts w.r.t. proper architecture... While arch. is no doubt important, I've found that it is not hard at all to get good perf. out of even a minimal expenditure on arch. for
Here's where I've found the bottlenecks and easy ways to solve them:
1) Don't put SOAP calls in tight loops . If you seem to have to do this, redesign things. This may seem obvious, but the reason SOAP doesn't really scale well on any platform is because of the function call overhead, so minimize that as much as possible. Make sure to cache results local to the caller for stuff that doesn't change very often (see #4 below).
2) For DB updates, use SqlConnection transaction handling instead of MTS whenever possible. In the old ASP/COM+ world, it was imperitive to use MTS so you could take advantage of the other COM+ features, but the
3) Make sure to use the correct transaction isolation level for your transactions. For highly transactional apps. that also do lookups on the updated tables, the one I've had the best luck with is IsolationLevel.RepeatableRead. I can't stress the importance of this enough - do some rudimentary testing (Microsoft ACT that comes with the
4) Use HttpContext.Current.Cache and related in your code to cache stuff that doesn't change too often (like product description lookups, etc.), especially for SOAP calls.
5) Adjust the "Minimum query plan threshold for considering queries for parallel execution (cost estimate)" once you move your app. to an SMP system, depending on if the DB server is standalone and how highly normalized the database is. For a highly normalized DB (lots of JOINs) on a standalone SQL Server box, set this at 0 or 1 because most of your queries could probably benefit from a parallel execution plan, or at least the small extra overhead won't really hurt. This setting alone dramatically and immediately boosted the performance of one application and took all of 2 minutes to implement.
6) Make sure to apply indexes where it makes sense. For example, on one app. 4 hours of query research and index tunning based on that provided a 10 fold better response time for one query, which probably increased scaleability for that database by 100 fold because of how often that query was used.
7) Read and follow this simple advice for SQL Server clustered indexes on MSDN: