Home > Archive > Software Engineering > January 2005 > enterprise application development versus traditional software development
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
enterprise application development versus traditional software development
|
|
| jrefactors@hotmail.com 2005-01-15, 3:57 am |
| I try to compare enterprise application development with traditional
software development. Looks like the major difference is that
enterprise application development has deployment phase, but not in
other applications such as desktop applications.
please advise. thanks
| |
|
| jrefactors wrote:
> I try to compare enterprise application development with traditional
> software development. Looks like the major difference is that
> enterprise application development has deployment phase, but not in
> other applications such as desktop applications.
Where are you getting this stuff?
"Enterprise" development is a big sexy word for "in-house" development.
Compared to "shrinkwrap", you can cheat on a few issues.
The pipeline to your customers is much shorter. You typically don't need to
find a way to make them pay for your software. In return, you give them
_exactly_ what they ask for, not what your marketing department tells you
might sell.
Because the pipeline is shorter, you can take many shortcuts. You might need
to build full-featured installers, or localize to many languages, or adapt
to many different kinds of databases. Because so many technology decisions
are already made, you can save time hard-coding links to specific databases
and other "enterprise" applications. None of these links must be
"productized", or made optional.
These forces allow you to focus on giving specific customers exactly what
they need. That's why "enterprise" is lucrative if you do it right, like
Thoughtworks does. And it can be lucrative if you do it "wrong", too. The
right way is to deploy teams to enterprises to help customize the computers
at the centers of their businesses. The "wrong" way is to build One True
Program that can configure and tweak and deploy to any possible enterprise.
That kind of program is typically very lucrative to tune and configure for a
very long time, but not very lucrative to its clients.
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
| |
| Leif Roar Moldskred 2005-01-15, 8:57 am |
| "Phlip" <phlip_cpp@yahoo.com> writes:
> jrefactors wrote:
>
>
> Where are you getting this stuff?
>
> "Enterprise" development is a big sexy word for "in-house" development.
> Compared to "shrinkwrap", you can cheat on a few issues.
Since he mentioned a deployment phase, I'd assume he's talking about
Enterprise Java development, which is basically development of a
system under the J2EE architecture where the system will be run under
an application server such as Websphere, JBoss or WebLogic.
The term "enterprise application" is basically used for large
back-office business applications - accounting systems, directory
management systems, order tracking systems and similar. It does not
have any particular connotations of the system having been developed
in house, nor that it's created for one particular customer only.
--
Leif Roar Moldskred
Never turn your back on a gabbleduck.
| |
| Alan Gauld 2005-01-15, 3:57 pm |
| On 14 Jan 2005 21:37:59 -0800, jrefactors@hotmail.com wrote:
> I try to compare enterprise application development with traditional
> software development. Looks like the major difference is that
> enterprise application development has deployment phase, but not in
> other applications such as desktop applications.
Enterprise class geneally refers to large scale. The applications
might not be significantly different to other business type apps
but they have to cater for very large volumes of users(10000
plus) in many geographic locations (often including many counties
and time zones), they will be running 24x7x365 often with
reliability in excess of 99.99% so full high availability,
failover and recovery need to be built in. Also security may be
an issue.
In addition Enterprise apps usually have to integrate with lots
of existing applications, so there will likely be lots of
middleware technology involved, and the database may well be a
single corporate entity so you are restricted in the schema you
can use. Sumilarly printing may be done by a print factory or
external publishing house rather than traditional printers
(lasers etc).
As you mention Enterprise projects typically cover the end to end
lifecycle so in addition to developing the software itself you
need to provide deployment (and probably training and support)
The need to rollback a release and be able to operate several
versions of the software concurrently are also quite common.
Also hardware specs and even dedicated network designs may be
needed.
I think those are the key characteristics of enterprise as I saee
them. Others no doubt will have other factors to consider.
Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld
| |
| Shayne Wissler 2005-01-15, 3:57 pm |
|
"Phlip" <phlip_cpp@yahoo.com> wrote in message
news:Th2Gd.17418$by5.15702@newssvr19.news.prodigy.com...
> jrefactors wrote:
>
>
> Where are you getting this stuff?
School?
I don't think your answer is going to impress his teacher ;)
Shayne Wissler
http://www.thoughtsonsoftware.com
|
|
|
|
|