embedlets-developer

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

[Andrzej J. T. <an...@ch...>]

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

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
>
>

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

[Christopher S. <cs...@oo...>]

< 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.

Maybe he has, but is so efficient that he came in at 30% of the budget and 6
months early!

Andrzej, you have been milking your clients too long!