> Where is the proof that 'non-core' processes (which is > s poorly defined by itself) should not be handled by a > business?
IMO it's not something provable, is a choice you can make either way. If you do it yourself, you need to take over the whole management and infrastructure costs for that development effort, which is in no way insignificant.
> > Still, in the world as it is today, most programmers work > > for companies which live off selling development services, > > not software products. > > I don't think it does. That most developers work for > those companies is a symptom of the problem.
Right. But small companies and contractors are not in a position to change the current situation, and large companies have no interest in doing so.
> Let's take the analogy and flip it around. Let's say the > farmer works the way that most companies do. He sits down > and says "what does my farm sell? Cows and chickens." > Next, he decides to 'optimize' his business by > y outsourcing things that are 'non-core'. He doesn't make > money off of growing grass. That's not core. But he > needs grass to feed the cows. So he hires someone to make > sure the grass grows. That company comes in and throws > down fertilizer. All they are there to do is grow grass.
:D I think that is a quite nice description of the contemporary corporate world. Except that most companies sell either chicken or cows, but not both.
I think we are working in a much too young domain, at least in relation to its complexity. Indeed, what programmers do is code and often design business processes. You have to keep in mind, however, that most of today's management is somewhere between completely ignorant and slightly aware of the existence of such things as formal business processes. In most companies things work simply because new people learn from old people how things work, not because somebody thought about how the company can work best. I would not trust such a company to write their own software for core processes and be successful with it. They'd probably get it right after the nth attempt, but they could well be bankrupt by then - due to exceptionally high costs associated with doing something they don't know (software development) and to losses in the core business due to business being supported (actually hampered) by inadequate business processes.
You complain about your company having trouble with a ready-made solution you bought. I don't know the details, but it could be that your company bought the wrong product. IMO,
what companies should do, in the current situation, is to buy platforms which help them develop on top of them with minimal effort, and have pure software development services companies (i.e. companies not developing any products, and doing software development as their core business) or individual contractors develop the code for their core and non-core applications, but only after establishing both a process architecture and pretty well defined standards regarding integration interfaces, user interface, coding and documentation standards etc. Then they'd get a coherent, properly working and maintainable infrastructure, one that's _designed_ to be maintainable, the same way cars or machinery is designed to be maintainable. After all, it's how the construction business works. No company does building, not even building maintenance, by itself. It's all outsourced - and plagued by some problems similar to software projects :D (overspending and delays in delivery). Nevertheless, it is wisdom earned over generations, from experience, that it's the right way to go.
The problem is, most companies try to keep IT costs as low as possible. This often results in buying the wrong platform, and getting only minimal services for the money they are willing to pay to developers. At least that's what my experience is.
IMO, if companies did outsource software development, but only after establishing the rules - platform, standards and the like - they'd pretty much be close to grass farming: external service providers for various services would have no other option but to work together, be they software developers, network/systems/database administrators, business analysts or whatever. However, each would need to graze only the lot where the customer drives him, and would depend on the chicken/cows/maggots/grass in that lot. Only by properly working together would they all be able to optimize the lot's workings and increase its yields for the farmer.
> I think we are working in a much too young domain, at > least in relation to its complexity. Indeed, what > programmers do is code and often design business > processes. You have to keep in mind, however, that most of > today's management is somewhere between completely > ignorant and slightly aware of the existence of such > things as formal business processes. In most companies > things work simply because new people learn from old > people how things work, not because somebody thought about > how the company can work best.
That's exactly how it works. The knowledge is in the company. Not outside of it. That's where it should stay. Once you move that knowledge out of your company, it's gone.
> I would not trust such a > company to write their own software for core processes and > be successful with it. They'd probably get it right after > the nth attempt, but they could well be bankrupt by then - > due to exceptionally high costs associated with doing > something they don't know (software development) and to > losses in the core business due to business being > supported (actually hampered) by inadequate business > processes.
That's the conventional wisdom that I am challenging. What I see is the opposite. Buying your software results in losses. The company I work for used to write it's own system (it bought code and enhanced it) then it was decided to buy the software. Costs have risen, quality has decreased and technical staff has increased in size. The excuse is given that the business failed to change it's processes to fit the software. In other words, let the decisions of a software company that doesn't understand your business define your processes. That's just dumb.
> You complain about your company having trouble with a > ready-made solution you bought. I don't know the details, > but it could be that your company bought the wrong > product. IMO,
There are only a few choices in out space and they are all mostly the same. We know that out competitors also pay for custom modifications because the vendor delivers their custom process documentation to us.
> what companies should do, in the current situation, is to > buy platforms which help them develop on top of them with > minimal effort,
I think you need to realize I'm not talking about developing everything from scratch. I mean pulling together the best tools available and building a solution. I'm not advocating developing your own operating system or database or software platform.
> and have pure software development > services companies (i.e. companies not developing any > products, and doing software development as their core > business) or individual contractors develop the code for > their core and non-core applications,
That assumes that 'software' companies are good at developing software. My experience is that they are often no better and often worse than internal IT departments. They do think they are better, and that's part of the problem.
> but only after > establishing both a process architecture and pretty well > defined standards regarding integration interfaces, user > interface, coding and documentation standards etc. Then > they'd get a coherent, properly working and maintainable > infrastructure, one that's _designed_ to be maintainable, > the same way cars or machinery is designed to be > maintainable.
Sounds good but by the time you do all of that, it won't be needed anymore. Business moves too fast.
> After all, it's how the construction > business works. No company does building, not even > building maintenance, by itself.
When you don't need a full-time person for a given job, it's less expensive to 'rent' those skills. When you do need a full-time person, it's almost always cheaper and more effective to bring that skill in-house. It's not black-and-white. There are lots of factors in making these choices. The problem is that sayings like 'we aren't a software company' are seen as equivalent to real arguments.
> It's all outsourced - and > plagued by some problems similar to software projects :D > (overspending and delays in delivery). Nevertheless, it is > wisdom earned over generations, from experience, that it's > the right way to go.
What generations?
> The problem is, most companies try to keep IT costs as low > as possible. This often results in buying the wrong > platform, and getting only minimal services for the money > they are willing to pay to developers. At least that's > what my experience is.
That's a pretty easy way to dismiss real problems. If you buy a platform and you have problems, you bought the wrong platform.
What do you think Amazon.com's core business is? I don't mean that rhetorically. What would you say it is?
Flat View: This topic has 16 replies
on 2 pages
[
«
|
12
]
Previous Topic
