Looking for some good SPeW!

"System Performance Per Watt Hour" -- SPPWH -- seems like a new and important metric, which Patrick Schmid, Achim Roos and Tom's Hardware deserve kudos for establishing:

http://www.tomshardware.com/reviews/intel-atom-efficiency,2069-12.html#BOM_comments

Surprisingly, no other Google hits for this term exist right now on the internet other than in this article.

Since I constructed the acronym "SPPWH" above, I'm modifying it a bit in hopes of making it's adoption perhaps somewhat viral: "Systems Performance pEr Watt-hour" or "SPeW".

That's what I'm looking for in my next computer: one that's got some good SPeW!

This metric is clearly important when doing computational tasks like protein folding that are divided into work units. A high SPeW rating gives a lower overall power consumption for completing each given work unit. Here, a high SPeW is beneficial to humanity in 2 key ways: providing greater computational power in the effort to cure disease, while consuming fewer planetary resources!

The tooling is what's most important

Exploring the fundamentals of architecture and services in an SOA:

"the OrderService might be able to directly access certain information about order lines such as the number of lines on the order, without having to make a service operation call on the OrderLineService itself. In the same way, a call to the OrderLineService might return some basic order information as well, without the OrderLineService implementation having to make a call on the OrderService."

That may be true, but that's something that could be hidden from the developer. If the service-oriented approach is the most elegant from both an architectural and coding point of view, then, by all means, adopt that in each case, and optimize behind the scenes.

This is reminiscent of what IBM insightfully argues as to why they're still using EJB 2 rather than EJB 3 in the latest RAD 7.0 IDE release: it's the tooling that's most important! That's a very persuasive argument, and I agree completely with it. However, I have to ask: "where's the beef?" In other words, the existing tooling leaves a whole lotta room for improvement!

Components and Services

Blog (Handbook of Software Architecture): "the best service-oriented architectures seem to come from good component-oriented architectures, meaning that the mere imposition of services does not an architecture make..." --Grady Booch, writing in 2004.

Technical Service Maturity, continued

What might a fully robust service component framework and environment provide?

Service Monitoring (realtime and historical)
Service Structural Composition Management
Service Process/Workflow Composition Management
Service Dependency Management
Service Lifecycle Management
Service Configuration Management
Service Version Management
Service Binding/Rebinding Management
Service Location Management
Service Rerouting Management
Service Ontology Association Management
Service Session Management
Service Security Management
Service Transaction Management
Quality of Service (QoS) Management
Microfailover
Microreboot
Microrecover
Microrejuvenation
URSIGE="Ultra-Rich and Snappy Integrated Graphical Environment", both for design time and run time operations, including for all of the above, which could be themselves components exposed in a URSIGE

Technical Service Maturity

Your search - "technical service maturity" - did not match any documents.
Suggestions:
Make sure all words are spelled correctly.
Try different keywords.
Try more general keywords.

It looks like I'm the first to use the term: "technical service maturity". More about what that might mean in future posts.