RE: [Embedlets-developer] Re: Cost analysis....

[James C. <ca...@vi...>]

> Your enterprise costing numbers are ludicrious...obviously you have never
> managed (nor had budget authority) for a large enterprise-level
> development

You want me to do a full breakdown here on a list just to make a point?

Simply tried to make the point that unit costs are the dominant feature in
many (no not all) embedded applications and that java doesn't stack up well.

It was to make a point that you seem to have agreed with in the end so I'll
cop my simplistic view of the world on the chin ;-)

James Caska
http://www.muvium.com
'Java Bred for Embedded'




> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of
> Andrzej Jan Taramina
> Sent: Sunday, February 02, 2003 9:48 AM
> To: emb...@li...
> Subject: [Embedlets-developer] Re: Cost analysis....
>
>
> James does a simplistic cost calculation:
>
> Your enterprise costing numbers are ludicrious...obviously you have never
> managed (nor had budget authority) for a large enterprise-level
> development
> team <grins>.  Cost of Project Management, Requirements Analysis,
> QA/Testing, Web Design, and Infrastructure/Tools/hardware to
> support all of
> these activities and the actual development would easily raise
> the cost into the
> million dollar category.  You can't just look at the coding costs.
>
> But no matter...the above is not really relevant to the embedlet
> situation.
>
> However, in the embedded world, I would expect that the QA/Testing
> requirements and costs would be even more substantial (hard to fix once
> you're burned the flash and distributed 100K devices into the field).
>
> > Java needs to compete head to head on cost to become a serious contender
> > in this market.
>
> Agreed to some degree.  But costs do have to include QA/Testing
> (typically
> much cheaper with Java than C/Asm), reliability (better with Java), speed
> (faster dev time with Java), ease/cost of finding qualified
> resources (again
> getting easier with Java developers, retraining costs would be
> much lower),
> and don't forget the most important part, which is a key idea of
> Outpost, the
> cost of integration with back end systems.
>
> You then also have to take into account that Java-based solutions
> might be
> more generic in nature, and thus you could potentially solve many
> disparate
> problems with only a single embedded hardware platform....which would
> reduce hardware engineering costs substantially.
>
> Also, think of the wide fan-out problem in corporations that wish
> to instrument
> their lower level processes to feed their enterprise systems (the
> Real-Time
> Enterprise that is being talked about in CIO-level publications
> these days, and
> the foundation idea that kicked of Embedlets in the first palce).
>  This is not the
> "classic" embedded market....and may not require 100K's of mass-produced
> devices...maybe just a few dozen...or a few hundred. In that
> scenario, the cost
> of the embedded device is much less of a factor, and the cost of
> development/integration becomes more significant.  Plus the
> familiarity with
> Java, Container-based systems, etc. will make corporations more
> comfortable
> with the embedded controller technology, since they would use Java-
> resources to develop everything from enterprise to embedded applications,
> with minimum retraining.
>
> Anyway, though your cost analysis has some validity, I think that
> the real
> market is not that clear or simplistic.  If it was, then
> MIDP/CLDC technology
> would not have become so prevalent so fast on consumer devices (like cell
> phones), since the same "costing" logic should apply there...but
> obviously has
> been superceded by larger concerns.
>
> > That is I think it is more important to ensure the minimal footprint of
> > the Embedlet spec is well conceived and that feature creep is kept to a
> > minimum to support our goals than is the thinking and resources required
> > for the wiring tool.
>
> I agree with this wholeheartedly!  The smaller the footprint and resource
> requirements (and prerequisite requirements) then the larger the
> potential
> market audience is.
>
> > These are by no means mutually exclusive goals, and I know you are very
> > focused on ensuring Embedlets will run on muvium and I want to support
> > whatever is needed to make that happen, special packages, serialisation,
> > whatever it takes..
>
> These goals are not mutually exclusive, but the balancing act
> will be delicate
> and non-trivial to get right.
>
> > I just want to ensure we all keep thinking lean!
>
> For sure, James!  Lean is one of my driving factors...as light as
> possible in
> fact.  But modular and extensible, so that more advanced (eg. less lean)
> features could be added for those platforms that can suppor them, without
> compromising the breadth of support for more constrained devices.
>
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>
>