[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