Slashdot Mirror
Software - Different Traits for Manufacturing vs Service?
tachin asks: "We've all been hearing about software as a service industry as opposed to manufacturing, there are some differences that favour that view, but I wonder if the type of industry affects the fundamental design of a software system. Considering the differences between those two types, are there some software constructs that are appropriate for one type of industry but would be undesirable for the other? As economies everywhere are becoming more service-oriented, what are the main characteristics a software system must provide to work well in such environments?"
In order to serve customers well, you have to be able to quickly deliver a solution. The keywords in a service oriented software world are rapid prototyping and scripting. In a manufacturing oriented software world, hardware costs are more important, so you're going to see less cpu intesive programming styles. A prime example for manufacturing oriented software is the embedded market: Still lots of low level programming to keep code sizes down and speed high.
You can blow all kinds of holes in these arguments by clearly defining what "tangible" really means. To say that because you cannot touch, smell or taste software it is intangible is incredibly flawed logic.
The code behind software can be printed. It is stored physically on a disk. These two things are good enough for the patent office and copyright law. They should be good enough arguments that software is indeed tangible. Another, somewhat easier, way to look at it is this: "Once you pay for it, it's yours forever."
You could also look at it this way:
If you are contracted to write a specific piece of software for a company you are performing the role of the manufacturer, and they are the customer. The price is variable, but once the project is complete the price becomes fixed. The company has a tangible product and does not need to contact you further. (Support contracts and the like really are separate products entirely, which most certainly qualify for the "service" mindset.)
Likewise, when a company employs an IT staff to maintain it's internal systems it really is a service role.
You can play all kinds of accounting tricks when you're supporting software. Does the cost of support add to the cost of the software? Not technically, the real cost comes from the hiring of support staff who likely service a wide range of internal systems. You can assign additional VALUE to the software though, since you have an established knowledge base with it.
The web complicates things a little. You subscribe to access to a web-based service. It is not tangible to YOU. It is tangible to the company you are subscribing to. These services fit both the manufacturing and service mindsets:
- The service provider contracted or hired the talent to build the software in the first place. This is manufacturing. Major upgrades and additions to the software are also manufacturing.
- The service provider contracts / hires the services of programmers to maintain their environment.
- The customer is purchasing a service from the provider.
I'm not sure if this even answers the questions asked. But it's 5:30am and it looks pretty good to me.
The website claims that "Information Wants to be Free" is a myth:
Interesting. I guess the point is that even if the cost of replicating code/software/information is very close to zero, the marginal utility can certainly be greater than zero. (high school economics, pull me through!)
on how the answeree interprets your question. Personally, I've got no idea what you're trying to ask. Software is not standard manufactoring as such because nothing is physically produced. It is closer to a horoscope service than to a tinned food plant.
The two top arguments in the article for why software is a service were erroneous.
1. 19/20 jobs are for in-house programmers This ratio may be true, but the conclusion that most software is written at the point of use as a service is false. If that one-in-20 commercial software company programmer writes commercial code that that sells even one thousand copies, then commercial code becomes 1000/(1000+19) = 98.1% of the code instances in use.
Another way to look at this is to examine the code inside the average company server for the ratio of in-house versus chimerical code. You will find maybe 10 million lines of code in a commercial OS, millions of lines of code in commercial enterprise applications (e.g., SAP, Oracle, Exchange Server, etc.), and a comparative fraction of that in code written in-house (config files, business rule scripts, report generators, PERL scripts, custom applications, etc.). Look inside the average desktop and the ratio of in-house to commercial code is even more extreme.
2. Remainder bin software: This argument is partially tautological. People (and retailers) devalue discontinued items or items from defunct makers because of the often valid perception that the item (or maker) was discontinued for good cause. If something did not sell on the shelves and the maker goes bankrupt, there is probably a reason. I will grant that future value plays a role in buying software, but part of the discount for remaindered goods reflects the low present use value.
Enterprise Does Have a Service Component: I think part of the difference lies in the distinction between enterprise software and consumer software. Clearly, enterprise software requires much more configuration, maintenance, and support -- its much more service oriented. The Accentures, EDSs, and IBMs of the world have made a ton of money on service related to software and IT.
Consumer Won't/Don't Pay for Service: In contrast, consumer software is much more manufacturing driven. There is simply no way that a $49 retail piece of software can come with any service. Nor, judging by the income statements of software makers, do these makers provide much service. There is simply no room in a $49 price point to cover the costs of real on-going tech support. Even upgrades are hardly a service -- the upgrade price is software half or 2-3rds the full retail price and given that the software maker gets to keep a bigger cut by selling upgrades direct, upgrades are a massive profitable product sales.
I doubt consumers will move to a subscription model for software (see Microsoft's attempts to do this) and I doubt they would like a pay-as-you-go model either. Most people bitch anytime that have to buy service (fixing a car, hiring a plumber, etc.) because most people place a less-than-salary value on their own time while the cost of service is always a more-than-salary amount (to cover benefits, employers taxes, support costs, profit, etc.) Do-it-yourself retailers like Home Depot and AutoZone have gotten very rich on consumer's asymmetric valuation of service labor. Consumers only want free service and that means bundling service into the retail price of a saleable manufactured asset.
Rising Ease-of-Use == Less Service:But I even wonder about the service model in all kinds of software. I would further argue that as ease-of-use improves, the need for service drops. The more a piece of software "just works" the more it acts like a manufactured good.
Even in configuration-heavy enterprise software systems, better interfaces could reduce the amount of coding-labor required to configure, maintain , and support big enterprise systems. The move from all-in-house applications to commercial enterprise apps also reflects a move to manufactured software. And as the enterprise apps accumulate functionality (SAP has 27 different inventory management algorithms), it becomes harder to justify paying in-house programmers to write one-off application. Now I'm sure that enterprise system will continue to need lots of service, but I wonder if the amount of service (per function point) won't decline as the systems become more plug-n-play, point-n-click.
Two wrongs don't make a right, but three lefts do.
One of the dangers of buying software as a service is that the vendor company may be tempted to forgo quality or ease of installation/changes if the contract specifies that installation, changes, or bug fix services are conducted under a time and materials contract. In that case, the service company has an incentive to provide as much "service" as possible since that means more money.
I once worked for a consulting company that was a partner to compensation software company. I got this feeling that the compensation software company didn't feel the need to make their products easy to implement or of high quality (bug wise) because all contracts were essentially time and materials contracts. Thus, the harder the packages were to implement, the more money that the software company (and my employer) made. Thankfully, I only stayed with the consulting company for 9 months before moving on.
As economies everywhere are becoming more service-oriented, what are the main characteristics a software system must provide to work well in such environments?"
- Low monetary cost of purchase and human cost of deployment.
- Low monetary and human cost to maintain.
- Easily adapted to suit changing business needs, including moving between different hardware and software systems.
From what I've seen, current software offerings only partially fulfill this laundry list.Which means there's room for improved products.
Once the purchasing costs are pushed down low enough, what matters most is that service-industry employees are made more productive by using the software; i.e., human factors.
And, if your software can make cheaper human beings function more like expensive human beings, then that's a plus. [Throw the rotten vegetables at me, but recognize it's because passing off cheaper workers for more expensive workders been done so poorly, so frequently, and, face it, can never be done completely.]
"Provided by the management for your protection."
Hey, if burger flipping can be manufacturing, why can programming?
If copyright violation can be considered theft of intellectual property, then I suppose the creation of that property could be considered manufacturing.
In the early part of the century, automobiles were big, technically complex, unreliable, and needed expertise to run and maintain them. To put it simply, if you wanted to use an automobile, either you needed to be a technically sophisticated hobbyist or you needed the services of a chauffeur and a mechanic.
Now, they're product-like.
Software should be product-like. It is service-like because a) we still haven't figured out how to do it, and b) there is a combination of interests that is well-served by the status quo.
"How to Do Nothing," kids activities, back in print!
"You can blow all kinds of holes in these arguments by clearly defining what "tangible" really means. To say that because you cannot touch, smell or taste software it is intangible is incredibly flawed logic."
And yet such an argument is the basis for every P2P "pirate's" defense.
Fred Brooks made a lot of insightful observations about software. But they can all be boiled down into one: "Software is unlike anything else in our experience, so don't treat it like it is." (that wasn't his observation, that's my high level executive summary). If you treat software like manufacturing you'll get it wrong. If you treat it like service you'll get it wrong. If you treat it like anything else in the world, you'll get it wrong.
The next time someone says "we have to treat software like [anything other than software]", rest assured that they're wrong. But or course, your boss is paying attention to them, so you might as well learn the new buzzwords for the month...
Don't blame me, I didn't vote for either of them!