-
Amazon queues up new workflow service — Cloud Computing News
This is very interesting. Amazon brings cross-border orchestration to cloud(s) and enterprises; and presumably between business partners. Use for scale, flexibility and potentially integration.
“Amazon Web Services says its new Simple Workflow Service (SWS) will run applications that are distributed between customer sites and Amazon’s cloud infrastructure, further blurring the line between the customer’s data center and their chosen cloud.”
Archives for February 2012
Active Info: Data Dirt & Business Architecture
Posts by Om Malik and Brad Feld inspired me to write (rant) my thoughts on business architecture and its meta role as digital business image. The post link with official excerpt:
Combat data (and decision) dirt with meta business architecture
If we are to classify contextless data dirt, this first case illustrates superfluous, distracting data. I posit that an equally insidious type of data dirt forms when data is analyzed without regard to origin, business-system and business goal contexts.
Link Collection — February 19, 2012
-
What’s Your Mental Model Of Innovation? – Forbes
“Achieving continuous innovation, Hamel stresses, “lies outside the performance envelope of today’s bureaucracy-infused management practices.” It will require major changes in mind and heart. It will need, Hamel writes, new values, new processes for innovation, a greater adaptability, the infusion of passion in the workplace and a new belief system or ideology.”
-
Big Data’s Impact in the World – NYTimes.com
An excellent piece in the NYT on all things big data.
“GOOD with numbers? Fascinated by data? The sound you hear is opportunity knocking…”
-
The RedMonk Programming Language Rankings: February 2012 – tecosystems
“For years now, it has been self-evident to us at RedMonk that programming language usage and adoption has been fragmenting at an accelerating rate [coverage]. As traditional barriers to technology procurement have eroded [coverage], developers have been empowered to leverage the runtimes they chose rather than those that were chosen for them. This has led to a sea change in the programming language landscape, with traditional language choices increasingly competing for attention with newer, more dynamic competitors.
The natural consequence of this tectonic shift has been uncertainty. Vendors for whom supporting Java and Microsoft based stacks was once sufficient are being forced to evaluate the array of alternatives in an effort to maximize their addressable audience. Platform-as-a-Service (PaaS) stacks like Cloud Foundry and OpenShift are perhaps the best example of this; the differentiation for each at launch was in part their support for multiple independent runtimes from JavaScript to Ruby.
While the question is obvious – which languages should I support? – the answer, and mechanisms for determining an answer, have been considerably less so….”
Active Info: Data Scientists vs. Business Intelligence Pros; Predicting Linsanity
My latest posts on Active Information:
Data Scientists & Business Intelligence Pros, what’s the difference?
In a way, you could say data science leans towards innovation, while business intelligence leans towards optimization. Each are critical for business, government and societal progress.
For the vast majority, Lin’s breakthrough is a complete surprise. However, for numbers hobbyist Ed Weiland, Lin’s breakthrough was merely a matter of time.
Link Collection — February 12, 2012
-
It’s Time to Kill the Elephant | cloudeventprocessing.com
Colin on the need to break free of batch based MapReduce: “All of these recent shifts from companies like Google, Yahoo, and others no longer see a competitive advantage in batch based MapReduce. The future has arrived, let’s look at some evidence…”
-
Suffering-oriented programming – thoughts from the red planet – thoughts from the red planet
Excellent post / advice:
“I follow a style of development that greatly reduces the risk of big projects like Storm. I call this style “suffering-oriented programming.” Suffering-oriented programming can be summarized like so: don’t build technology unless you feel the pain of not having it. It applies to the big, architectural decisions as well as the smaller everyday programming decisions. Suffering-oriented programming greatly reduces risk by ensuring that you’re always working on something important, and it ensures that you are well-versed in a problem space before attempting a large investment.
I have a mantra for suffering-oriented programming: “First make it possible. Then make it beautiful. Then make it fast.””
