The Smile-IT Blog » December 2014

Monthly Archives: December 2014

All Things Must Pass – Top Album Challenge No. 10/10


The No. 1 issue of “my” Top Album Challenge – in a way – ends with “The End”. No. 10 sort-of closes the loop to No. 1.

While the first marked the end to the only ever band in this world’s music scene which transformed multiple eras (yes, puritans, it wasn’t their last album), the latter marks the beginning of the solo career of one of its members, who’s work during the band’s time always remained a little neglected and underestimated (yes, again, it wasn’t his first solo album, either 😉).

However, by the time the Beatles broke up, George had the amount of a three-piece vinyl masterpiece of songs ready to be published. Issued – eventually – under the name of “All Things Must Pass”, mastered by the “infamous” Phil Spector (who’s art of “thickening” every song with a whole lot of doubled instrumental tracks and a huge and fat drum section I not always appreciate; however, in this case, this is how it has to be).

There isn’t really something authentic on youtube for presenting the album in its original form. I did, though, find this list which is pretty accurate. So, here’s the closing of a challenge I very much enjoyed. And here’s a “thanx” to Claudia for nominating me.


P.S.: And there is, of course, the following. It contains almost all the important songs of this album and more, played to honour their creator by his closest musical friends … May the holiday season provide time for enjoying the all-time-greatest concert ever: Concert for George, Royal Albert Hall, Nov 29, 2002.

Published by:

The Story of Little Milton – Top Album Challenge No. 9/10


Later – when announcing his epic live – Ian Anderson would say: “… we even did concept albums …” – with a little pitch in the tone on “concept”. Jethro Tull weren’t particularly a progrock formation, more like a genius crossover of folk, rock, a little irish/celtic here and there with progrock as the icing of the cake.

No. Wrong. The icing of the cake was Anderson’s art of playing and “singing” the flute at the very same time.

Anyway – there is one Tull album, indeed, rightfully to be claimed into the progrock section. And it is accompanied by a brilliant story (composed into a newspaper issue of the “St. Cleve Chronicle & Linwell Advertiser“) around a boy winning a literature contest and being disqualified afterwards as psychiatrists judged him to have a “seriously unbalanced mind”. Embarrassingly enough, it was years past my acquaintance with the record that I realized, the story was actually 100% fake 🙂

“Little Milton” named the poem he won with “Thick as a Brick”. And the newspaper reports are reprinted beneath the youtube link, I chose … Have fun with my penultimate top album challenge feature!


P.S.: When searching google for “thick as a brick newspaper“, one can find loads of copies of that 12 page St. Cleve Chronicle & Linwell Advertiser from 1972.


Published by:

Bedürfnispyramide / Hierarchy of Needs

… und auch wenn die allgemeine Digitalisierung und das dauernde Verbundensein grundsätzlich spannende und bereichernde Entwicklungen sind, dürfen wir – gerade dieser Tage – WLan und Akkuleistung auf der Maslow’schen Bedürfnispyramide ruhig ein wenig weiter oben einreihen. Tim Minchin hat da ein paar ganz gute Ideen dazu …


… and even though Digitalization and ubiquitous connection of everyThing are interesting and enriching advancements of mankind, we’re surely allowed – especially during these days – to put “WiFi” and “Akku” onto some higher places within Maslow’s “hierarchy of needs”. Tim Minchin has some nice ideas to this, indeed …


Published by:

A “Yes” for progrock – Top Album Challenge No. 8/10


Commencing the holiday season with my passion for progrock (and I won’t keep you long with words): “Yes” were my entrance into progrock. “Yes” were amongst my first ever bought LPs (and I still own those). “Yes” opened a way into music during my late teenage years like no other group. “Yes” – for me – remains the utmost musical art. It was a complete artistic masterpiece. Songs. Suite-style compositions. Ever-changing hard-to-follow rhythm and structure. And beyond-awesome album cover artwork by Roger Dean.

Meanwhile my collection – crazily enough – contains all the official Yes-work, the records of the “diaspora” era when Chris Squire and Jon Anderson had parted paths, the “Yes, Friends and Relatives” albums and a few semi-official stuff. Why I chose “Yessongs” for the Top-Album-Challenge? Because I’ve restricted myself to only one per artist 😉 – and this is the most comprehensive compilation of their early works. And it’s live – showing off their tremendous genius.

Sit back and enjoy – 2+ hours of Yesmusic:


Published by:

The “Next Big Thing” series wrap-up: How to rule them all?

What is it that remains for the 8th and last issue of the “Next Big Thing” blog post series: To “rule them all” (all the forces, disruptive challenges and game changing innovations) and keep services connected, operating, integrated, … to deliver value to the business.

A bit ago, I came upon Jonathan Murray’s concept of the Composable Enterprise – a paradigm which essentially preaches fully decoupled infrastructure and application as services for company IT. Whether the Composable Enterprise is an entire new approach or just a pin-pointed translation of what is essential to businesses mastering digital transformation challenges is all the same.

The importance lies with the core concepts of what Jonathan’s paradigm preaches. These are to

  • decouple the infrastructure
  • make data a service
  • decompose applications
  • and automate everything

Decouple the Infrastructure.

Rewind into my own application development and delivery times during the 1990ies and the 00-years: When we were ready to launch a new business application we would – as part of the rollout process – inform IT of resources (servers, databases, connections, interface configurations) needed to run the thing. Today, large IT ecosystems sometimes still function that way, making them a slow and heavy-weight inhibitor of business agility. The change to incorporate here is two-folded: On the one hand infra responsibles must understand that they need to deliver on scale, time, demand, … of their business customers (which includes more uniform, more agile and more flexible – in terms of sourcing – delivery mechanisms). And on the other hand, application architects need to understand that it is not anymore their architecture that defines IT needs but in turn their architecture needs to adapt to and adopt agile IT infrastructure resources from wherever they may be sourced. By following that pattern, CIOs will enable their IT landscapes to leverage not only more cloud-like infrastructure sourcing on-premise (thereby enabling private clouds) but also will they become capable of ubiquitously using ubiquitous resources following hybrid sourcing models.

Make Data a Service.

This isn’t about BigData-like services, really. It might be (in the long run). But this is essentially about where the properties and information of IT – of applications and services – really is located. Rewind again. This time only for like 1 or 2 years. The second last delivery framework, that me and my team of gorgeous cloud aficionados created, was still built around a central source of information – essentially a master data database. This simply was the logical framework architecture approach back then. Even only a few months – when admittedly me and my then team (another awesome one) already knew that information needs to lie within the service – it was still less complex (hence: quicker) to construct our framework around such a central source of (service) wisdom. What the Composable Enterprise, though, rightly preaches is a complete shift of where information resides. Every single service, which offers its capabilities to the IT world around it, needs to provide a well-defined, easy to consume, transparently reachable interface to query and store any information relevant to the consumption of the service. Applications or other services using that service simply engage via that interface – not only to leverage the service’s capabilities but even more to store and retrieve data and information relevant to the service and the interaction with it. And there is no central database. In essence there is no database at all. There is no need for any. When services inherently know what they manage, need and provide, all db-centric architecture for the sole benefit of the db as such becomes void.

Decompose Applications.

The aforementioned leads one way into the decomposition pattern. More important, however, is to spend more thorough thinking about what a single business related activity – a business process – really needs in terms of application support. And in turn, what the applications providing this support to the business precisely need to be capable of. Decomposing Applications means to identify useful service entities which follow the above patterns, offer certain functionality in an atom kind-of way via well-defined interfaces (APIs) to the outside world and thereby create an application landscape which delivers on scale, time, demand, … just by being composed through service orchestration in the right – the needed – way. This is the end of huge monolithic ERP systems, which claim to offer all that a business needs (you just needed to customize them rightly). This is the commencing of light-weight services which rapidly adopt to changing underlying infrastructures and can be consumed not only for the benefit of the business owning them but – through orchestration –form whole new business process support systems for cross-company integration along new digitalized business models.

Automate Everything.

So, eventually we’ve ended at the heart of how to breath life into an IT which supports businesses in their digital transformation challenge.

Let me talk you into one final example emphasizing the importance of facing all these disruptive challenges openly: An Austrian bank of high reputation (and respectful success in the market) gave a talk at the Pioneers about how they discovered that they are actually not a good bank anymore, how they discovered that – in some years’ time – they’d not be able to live up to the market challenges and customers’ demands anymore. What they discovered was simply, that within some years they would lose customers just because of their inability to offer a user experience integrated with the mobile and social demands of today’s generations. What they did in turn was to found a development hub within their IT unit, solely focussing on creating a new app-based ecosystem around their offerings in order to deliver an innovative, modern, digital experience to their bank account holders.

Some time prior to the Pioneers, I had received a text that “my” bank (yes, I am one of their customers) now offers a currency exchange app through which I can simply order the amount of currency needed and would receive a confirmation once it’s ready to be handed to me in the nearest branch office. And some days past the Pioneers I received an eMail that a new “virtual bank servant” would be ready as an app in the net to serve all my account-related needs. Needless to say that a few moments later I was in and that the experience was just perfect even though they follow an “early validation” policy with their new developments, accepting possible errors and flaws for the benefit of reduced time to market and more accurate customer feedback.

Now, for a moment imagine just a few of the important patterns behind this approach:

  • System maintenance and keeping-the-lights-on IT management
  • Flexible scaling of infrastructures
  • Core banking applications and services delivering the relevant information to the customer facing apps
  • App deployment on a regular – maybe a daily – basis
  • Integration of third-party service information
  • Data and information collection and aggregation for the benefit of enhanced customer behaviour insight
  • Provision of information to social platforms (to influence customer decisions)
  • Monitoring and dashboards (customer-facing as well as internally to business and IT leaders)
  • Risk mitigation
  • … (I could probably go on for hours)

All of the above capabilities can – and shall – be automated to a certain, a great extent. And this is precisely what the “automate everything” pattern is about.


There is a huge business shift going on. Software, back in the 80ies and 90ies was a driver for growth, had its downturn in and post the .com age and now enters an era of being ubiquitously demanded.

Through the innovative possibilities by combining existing mobile, social and data technologies, through the merge of physical and digital worlds and through the tremendously rapid invention of new thing-based daily-life support, businesses of all kind will face the need for software – even if they had not felt that need so far.

The Composable Enterprise – or whatever one wants to call a paradigm of loosely coupled services being orchestrated through well-defined transparently consumable interfaces – is a way for businesses to accommodate this challenge more rapidly. Automating daily routine – like e.g. the aforementioned tasks – will be key to enterprises which want to stay on the edge of innovation within these fast changing times.

Most importantly, though, is to stay focussed within the blurring worlds of things, humans and businesses. To keep the focus on innovation not for the benefit of innovation as such but for the benefit of growing the business behind.

Innovation Architects will be the business angels of tomorrow – navigating their stakeholders through an ongoing revolution and supporting or driving the right decisions for implementing and orchestrating services in a business-focussed way.


{the feature image of this last “The Next Big Thing” series post shows a design by New Jersey and New York-based architects and designers Patricia Sabater, Christopher Booth and Aditya Chauan: The Sky Cloud Skyscraper – found on}

Published by:

Not the Best Show of Hands – Top Album Challenge No. 7/10


Yes, it is not the best of recordings. And: yes, it is not the best of their shows. BUT: It was the one show of Rush that – when having been confronted with them by my brother – left a scar in my striving. No – not to play guitar or keyboard the way Alex Lifeson or Geddy Lee do it. That would’ve been lightyears out of reach for me. The vow I – no: we! my brother and me – made when having seen this was: Once in a lifetime we WILL see that band live on stage.

Which was a pretty difficult thing to accomplish as the closest they normally get to Vienna is as far as Hamburg or Berlin. So, when eventually they were announced for London Wembley in October 2007 we had to be stupid enough to book a mediocre expensive flight and hugely expensive concert tickets for that once in a lifetime experience – and it was worth every single cent! Oh! Yes!

What you need to know before listening:

  • Geddy Lee plays bass, bass pedal, keyboard and sings (and the amps are always some kind of weird specially manufactured shape – like e.g. washing machines on some later tour).
  • Alex Lifeson plays all guitars (and normally these days has an armada of pet animals on stage in front of him).
  • The two write the songs.
  • I adore a few – only very few – drummers; and Neil Peart is one of them.
  • Neil’s drumset is always especially manufactured for the respective tour; it’s full circle and has all kinds of sample pads included – and he’s the only drummer in the world, I can listen to in a full-length drum solo (OK – except for Ginger Baker’s Cream and Blind Faith stuff, I think ;)).
  • Neil writes awesome progrock-kind-of lyrics.
  • What you hear is what the 3 guys play live. No joke. No tricks. No backing tracks or overdubs.
  • The 3 are friends. They still are. Since 1969.

And now: Raising the curtain for “A Show of Hands”, Birmingham, 1988 (the quality is pretty awkward, but this was the only version acceptably in sync):


Published by:

The “Next Big Thing” series: Digital Transformation

Beware! No. 7 of the “Next Big Thing” blog post series is probably going to be at the heart of all the big business disruptions to come:


“Digital Business”

as a term has more or less become a substitute for the formerly heavily stressed “Industry 4.0”. Digital Business can best be described by a couple of examples illustrating how every business – without exception – will be disrupted by the huge innovative potential rolling along:

Example No. 1 – Retail and Education

School notifies the parents of a boy that he needs a certain educative material by tomorrow; they do that by means of a private message to the parents coming from the school’s facebook profile. The boy’s mother investigates through her mobile phone where the particular material can be purchased, connects to the store chain by means of a mobile app and requests availability information. The store responds with availability and price (through their app) also informs that the particular item has to be sent from a remote outlet and requests confirmation for the purchase and delivery. The mother responds with payment data and the school’s address for target delivery whereas the store chain triggers delivery of the item to the nearest train station, notifies the train operating company that a parcel needs to be delivered by tomorrow to the respective address whereas the train company in turn arranges for delivery to take place to the school’s nearest train station and from there by a drone directly to the school.

Example No. 2 – Weather and Insurance

A terrible thunderstorm destroys a house’s window. The respective sensors thoroughly detect the reason for the breakage of glass not to be from human intervention but from bad weather conditions and notifies the smart home automation gateway of what has happened. The gateway holds police, hospital and insurance contact information as well as necessary private customer IDs. Location address is derived via GPS positioning. The gateway self-triggers a notification and remediation workflow with the insurance company, which in turn assesses the incident to be a valid insurance case, triggers a repair order with an associated window glassworks company. The glassworks company fits the order into their schedule as it is treated an emergency under the given circumstances, rushes to the given location, repairs the windows, the workers report back to the insurance via mobile app and the insurance closes the case. All this happens without any human intervention other than final approval by the house’s owner that everything is OK again.

Example No. 3 – Holiday and Healthcare

The wearable body control device of an elderly lady records asynchronous heartbeat also slowly decelerating. The pattern is maintained within the device as being a situation of life endangering heart condition, hence the device commences transfer of detailed health monitoring data via the lady’s mobile phone to her children on the one hand and to her doctor in charge on the other hand. Both parties have (by means of device configuration) agreed to confirm the reception of data within 5 minutes after start of transmission. As none of this happens (because the kids are on holiday and the doctor is busy doing surgery) the device triggers notification of the nearest ambulance, transmits the patterns of normal health condition plus current condition and includes name, location, health insurance and nearest relatives data as well as the electronic apartment access key. The ambulance’s customer request system notifies the doctor in charge as well as the lady’s children that they’re taking over the case, an ambulance rushes to location, personal opens via mobile phone using the received electronic key, finds the lady breathing short and saves her life by commencing respective treatment immediately.


Well – maybe, today. But technology for all this is available and business models around it have begun to mature.

What these examples show – besides that they all encompass the integration of Things with several or all aspects of the Nexus of Forces discussed earlier in this article series – is an aspect essential to understanding “Digital Business” and that immense digitalization of our daily life: “Digital Business” is nothing else than the seamless (mean it;. literally: s-e-a-m-l-e-s-s) connection of humans, businesses and things (as in the IoT definition). “Digital Business” is a merger of physical and digital worlds!

In turn, this means plain simply, that there will be no business whatsoever that goes without software. Businesses already penetrated by software will experience increasing software, automation and integration challenges and businesses that haven’t yet introduced software into their models will face an increased challenge doing so, as well as to integrate with the digital world around them. Essentially for nothing else than just for staying in business.


{the 8th issue of this blog post series covers a way to approach all those challenges through creating a true services ecosystem for the enterprise; and as it’s the last it also wraps up and concludes}

{feature image found on}


Published by:

The “Next Big Thing” series: Discussing The Thing

Opening chapter No. 6 of the “Next Big Thing” blog post series by discussing the Internet of Things!

What’s essentially so entirely new about the Internet of Things? Things are not. Connectivity and protocols might be – but not entirely. Mastering the data produced by things – well: we’ve discussed that bit in one of the earlier posts of this series.

What’s really entirely new is the speed of adoption that the topic now reaches; and this speed is based on the possibilities that technology innovation have begun to offer to new things-based ecosystems.

In order to understand that, one has to judge the elements of a things-based architecture. While the article “Understanding the IoT Landscape” offers a quite comprehensive simplified IoT architecture, I would tend to be a little more detailed in assessing the elements of a functioning IoT ecosystem:

Architecture building blocks in an IoT Ecosystem

Figure: Architecture building blocks in an IoT Ecosystem

  1. The Thing itself. The variety of what a “Thing” may be is vast: medical human wearable monitoring devices (e.g. heart monitor), medical measurement devices (such as a diabetes meter), sensors, transmitters and alert devices in automated cars, smart home automation sensors, fitness wearables or simply watches that take over several of the above capabilities at once, … and many more things that aren’t even invented or thought of yet (the aforementioned article gives a decent list of what Things could possibly be). Discussing implementation architectures for the Thing itself would exceed the scope of this article by far, obviously.
  2. The Thing’s UI: This is already an interestingly ambiguous architecture element. Do Things have UIs? Yes, they do. Sometimes only comprised of one or a few LEDs or the-like of it. They could, of course, also have none at all if in case interfacing with a Thing’s user is delegated to either a mobile phone or a gateway which the Thing is connected to.
  3. Thing Connectivity and Communication Layer: The purpose of which is solely to bridge the gap between the Thing itself and the first connectivity point capable of transferring data through well-established protocols. Thing Connectivity may sometimes be reached through WiFi but often also by just using Bluetooth or any other wireless near field communication protocols.
  4. Thing Gateway: Rarely will Things directly feed data into any backend analytics or application layer; simply because it is too costly and complicated to accomplishing high performant, secure and reliable data connection based on proprietary protocols over long connectivity routes. Hence, we’ll often see some kind of gateway being introduced with the Thing which in simple cases could just be a mobile phone.
  5. Data Store: By whatever way Things might be leveraged by the business’s backend IT, we will always see a data collection and storage layer introduced to directly capture and provide Thing data for further compute, analysis and application integration.
  6. Application Integration: One essential topic to consider when introducing Things into business models is to envision an application landscape around the Thing in order to offer app-based Thing interaction to the end consumer as well as information from Things and their usage to the Thing’s business plus to third-party consumers in order to drive cross-business integration. New cross-enterprise business models will evolve anyway – the better Things-centered businesses allow for integration and orchestration, the better they will be able to leverage and let others leverage their disruptive innovations.
  7. Analytics: No Thing-based business – no Things introduction – will make any sense without creating the ability to leverage the information produced for analysis and even more for prediction or even prescription. We will see more of that in the next section of the article.

The impact to IT when discussing the change through IoT cannot be overestimated. Just by assessing the layers described above it does become obvious that we will see quite a lot of new architectural approaches evolve which in turn need to be integrated with existing IT landscapes. Also – as with all the more recent disruptions in enterprise IT – the orchestration of different services maturing in the “Things” space will be key for IT organizations to offer utmost business value when leveraging the Internet of Things.


{No. 7 of this blog post series will cover “Digitalization” and “Digital Transformation” – and what it really means to any business}

{feature image borrowed from the IoT wikipedia article}


Published by:

Sunday afternoon fun: The Web and the Net

A friend of mine posted that pic on facebook – together with the post from the Status-Q blog archive, saying:

This has been circulating on Twitter, courtesy of Jeremy Geelan – taken at W3C20. Tim Berners-Lee is on the left, Vint Cerf on the right, and the joke is on those who don’t know the difference between the web and the ‘net.

In 2014, that joke still seems to work – and why shouldn’t it? At least amongst folks not captured all day with technology stuff. But there’s an easy metaphor to know the difference:

  • You write a letter on a piece of paper – in your own words, your language – which (hopefully) the recipient – say: your friend – will understand. Letters get written to-and-fro between you and your friends, relatives, others; a whole lot of pages written fly across the earth. Pages in different languages and hopefully all the writers and recipients understand each other. To ensure exactly this – for electronic letters – Berners-Lee invented an ubiquitous language and called it HTML – so that everyone could understand those written pages, when displayed by something capable of reading HTML – a browser for instance 😉
  • And the letters? Well, they need transportation. The post offices, horse carriages, trains, ships, plains, … And busy postmen (and women, for sure) to deliver them to the recipients. All kinds of different transportation methods have to constantly join efforts and bridge gaps to get all those letters flying across the earth. To make that a little easier – for the electronic letters – Cerf thought of a unified method for transportation and called it Transmission Control Protocol (TCP); he even considered efficient addressing of recipients and called this the Internet Protocol (IP).

So, actually letters could exist electronically as pages, independently; everyone could understand them as they were all written in HTML, and recipients could decode them as they had browsers – here’s with the WEB.

Independently of this, writers and recipients could identify each other by addresses and could transport stuff between them – here’s with the INTERNET.

Needless to say – however – that the real breakthrough success eventually came with the joining of both (a little bit as in the pic, maybe ;))



Published by:

Wish You Another Final Lapse of the Moon – Top Album Challenge No. 6/10


While composing (long before actually publishing) post No. 6 of the challenge that my friend put onto me, my favourite online music store notifies me of the delivery of the “Endless River” CD (yes, I am still one with that old-fashioned utterly outdated habit of buying CDs). “The Endless River” is probably to be the real “final cut” of Pink Floyd’s oeuvre. It’s essentially compiled of abandoned tracks for the “Division Bell” album (1994) and at this very moment of writing I have no clue whether it will be able to beat any of the Pink Floyd masterpieces I could have chosen to be featured in this series (10 is far too few for a top album list).

I could have chosen “A Momentary Lapse of Reason”. That one was the first after Floyd’s breaking up with Roger Waters and Gilmour and Waters entering a year-long lawsuite about the IP rights for the band’s name. After Waters having had characterized Pink Floyd’s issues for years, the album is a solid representation of what Gilmour and the rest of the crew where capable of doing without other influence.

I could of course have picked the one before – “The Final Cut” – for a few of the greatest anti-war lyrics ever written in musical history and for the steps at the beginning of “Paranoid Eyes” which used to scare me to death when walking an empty dark street with my walkman’s headphones on …

I could’ve picked “Wish You Were Here”, of course, for “Wish You Were Here” and the “diamond ode” to Syd Barrett (at least as I see it). And I could probably have picked any of the other original Pink Floyd albums for they are all under my utmost favourites in musical history.

However, I picked the most obvious album I could possibly have chosen – “The Dark Side of the Moon” for each and every bit of it. To me it is kind-of a concept album even though the songs seemingly do not form that much of a story-line as in e.g. Jethro Tull’s “Thick as a Brick”. There’s glimpses of psychadelic in it (which I like a lot) as well as those awesome sound clouds that let the music kind-a sweep all over and around you + plus all kinds of real life sounds recorded – as always with Waters’ stuff – really live (like e.g. the interviews for accompanying songs with human dialogs)

Waters reportedly once explained the final song “Eclipse” and the album itself by stating:

I don’t see it as a riddle. The album uses the sun and the moon as symbols; the light and the dark; the good and the bad; the life force as opposed to the death force. I think it’s a very simple statement saying that all the good things life can offer are there for us to grasp, but that the influence of some dark force in our natures prevents us from seizing them.

Another detail (makin’ me chose this one before the others) is that little bit of Beatles in it: When listening to the original album on good gear, one can hear a glimpse of “Ticket to Ride” at the very end, which results – according to different sources – either from it being played in the Abbey Road studios while recording one of the interviews (to be precise, the famous words at the end: “There is no dark side in the moon, really. Matter of fact, it’s all dark.”) or from Alan Parsons (who engineered the record) using a tape which contained the song.

Why not “The Wall”? one might ask. Well … there is nothing compared to “The Wall”. “The Wall” is gloriously unique. Eternally unique. Hence, it cannot rank in any list. Never.

So – here we go – onto “The Dark Side of the Moon”:

Published by:
%d bloggers like this: