{feature image (C) “Loop21 Mobile Net GmbH” – gefunden auf futurezone.at}
Dieser Tage eine Schlagzeile: “WLAN auf der Schipiste wird zum Standard“. Der Artikel erklärt weiter, dass das WLAN besonders in der Mittagszeit genutzt würde (hoffentlich von jenen abseits der Piste, denk ich mir noch) und dass die Frage nach dem WLAN meist die erste beim Betreten einer Hütte wäre. Ein unmittelbarer Realitycheck bei den Kids bringt hervor: Jaja – das kennen wir schon lang!
Kurz überlege ich mir: Mit dem Handy in der Hand auf zwei Brettern den Berg runtersausen (Anm.: Ich bin kein Schifahrer) – interessant. Könnte cool aussehen und sich schmerzhaft anfühlen – mitunter. Man müsste Helmvisiere mit Dateneinblendung haben (gibt’s ja bereits fürs Motorrad). Da lese ich schon: “Skiwelt amadé lockt mit Datenbrille zum Ausborgen.” – Also auch schon alt.
Trotzdem: Ein paar Probleme – abseits einer gewissen Kollisionsgefahr beim beliebten Downhill Race Livestream – bleiben doch. Die könnte man eliminieren:
Strom: Die Hütten und Liftsäulen haben zwar jetzt alle ihre ordentliche WLAN-Abdeckung, haben aber wohl vielfach zum Aufrüsten ihrer Steckdosen vergessen. Wenn etwa 500 ausgehungerte Schifahrer zu Mittag essen, trinken, sich sonnen und mit den Freunden snapchaten wollen, dann brauchen wir Steckdosensäulen bei jedem Tisch. Oder …
Das Hochleistungs-Akkupack in der Tasche. Oder noch besser: In die Schijacke verbaut. Am Rücken einer mittelgroßen Jacke gehen sich so 5 – 7 LiPo-Zellen locker aus (auf die feuersichere Verbauung achten).
Alternativ wäre die Verbauung von Solarzellen im Schulterbereich des Anoraks denkbar. Ein kleines Zimo-Panel bringt angeblich etwa 5-6V. Bei gutem Schiwetter wohl ausreichend, um ein bisschen Surfen, Route Checken oder Chatten auf der Schipiste zu ermöglichen, bis Zeit für einen Stop und den nächsten Schnelladevorgang ist.
Der könnte sich übrigens mit USB-Ladestationen auf längeren Sesselliftfahrten ausgehen.
Nachts will dann das ganze Zeug ordentlich für den nächsten Tag vorbereitet werden, weshalb auch die Hotelleriebetriebe gut daran tun, ausreichend Steckdosen in den Zimmern vorzusehen (ich reise ja mittlerweile mit dem persönlichen Dreifach-Stromverteiler auf Grund dieses immer virulenter werdenden Problems)
Routenplanung: In kurzer Zeit möglichst viel des auserkorenen Urlaubs-Schigebiets kennen zu lernen hat schon seinen Sinn, finde ich, weshalb die Gebietsbetreuer gut daran täten, entweder in der eigenen App oder auf deren Website optimierte Schischaukel-Tagesrouten anzubieten. Inklusive wählbaren Schwierigkeitsgrades, Starring (“like” – möchte ich nochmal fahren – …) und natürlich der Sharing-Möglichkeit mit Freunden (wozu sonst Online-Sein; “ich bin hier; wo bist du gerade”).
Die Routenanweisungen werden dann per Bluetooth-Lautsprecher in den Helm durchgegeben, wenn nicht grade das Lieblingslied läuft (gibt’s schon – ich weiß; “Warte, Schatz, ich muss erst mein Handy rausnehmen und die Musik abschalten, damit ich dich verstehen kann.”)
Selbstredend blenden die Hütten- und Attraktionen-Betreiber entlang der Strecke per iBeacons an den Liftsäulen und Bäumen den p.t. Schigästen die besten tagesaktuellen Angebote abhängig von deren Vorlieben ins Helmvisier ein – das nur zum Drüberstreuen.
Und wenn ich dann von der Bergstation aus mein Mittagsmenü per Voice-Command bestelle, bekomme ich 10% Rabatt und einen Jagatee extra.
Zugegeben: Mein letztes Mal auf Brettern im Schnee liegt doch wohl schon so etwa 5 Jahre zurück (wenn nicht mehr). Der Test all dieser IoT Errungenschaften macht allerdings schon irgendwie Lust … Vielleicht stell ich mich in den kommenden Wiener Semesterferien wieder mal auf eine Schipiste und schau mir an, was von all dem schon geht. Um dann vielleicht festzustellen, dass die 4G-Abdeckung bereits so breit ist, dass das eingangs noch als Alleinstellungsmerkmal vermutete WLAN bald schon wieder völlig wurscht sein wird.
P.S.: Am Realitätscheck passionierter Schifahrer wäre ich übrigens brennend interessiert … bitte hinterlasst mir doch einen Kommentar hier. Danke!
Transkript meiner Keynote zum Post-Cloudalen Zeitalter. Slides hier zum Download.
Haben Sie sich schon immer mal gefragt, wo die Cloud begraben liegt? Bittesehr! Hier ist sie 😉
This is where the Cloud is burried!
Ich habe mich ja schon in einigen Publikationen mit der Sinnlosigkeit auseinandergesetzt, Cloud Computing zu diskutieren – nicht, weil die Cloud tatsächlich tot wäre (einen Talk damals im Jahr 2014 damit zu beginnen, war schon etwas – nunja – “frech”), sondern weil sie so allgegenwärtig ist, wie das Internet ansich – darüber diskutieren wir ja auch nicht mehr. Aber sehen wir uns die Geschichte einmal etwas genauer an:
Wussten Sie, dass Cloud Computing eigentlich auf das Jahr 1999 zurück geht? Damals wurde Salesforce gegründet – und hat mit Guerilla-Marketing die traditionelle CRM Szene ordentlich aufgemischt; der Erfolg gibt ihnen, denke ich, heute recht. In den Jahren danach wurde es dann doch erstmal etwas ruhiger – eine Zeit lang; doch ab etwa 2006 schossen Cloud Anbieter aus dem Nichts mit damals wohl noch ungeahnter Geschwindigkeit in die Höhe.
Heute diskutieren wir nicht mehr, ob es die Cloud gibt, sondern wie wir sie in unsere IT Strategie bestmöglich integrieren, welche Services wir sinnvoll nutzen können oder wie wir multiple Services und unser on-premise Rechenzentrum miteinander verbinden und effizient managen (RightScale hat da übrigens einen sehr vielversprechenden Ansatz mit deren Cloud Management Plattform). Und während man früher Logo-Landkarten für COTS (Commercial Off The Shelf) herzeigen konnte, zeigt man sie jetzt – wie hier – für z.B. SaaS.
Dort lauten – wie im Bild oben dargelegt – die 5 essentiellen Charakteristiken einer Cloud:
On-demand self-service: Ich bekomme also etwas genau dann, wenn ich es brauche, und dann sofort
Broad network access: Ich erreiche den Service mittels eines hoch-performanten Netzwerkes – wir sprechen hier von der Provider-Anbindung, nicht notwendigerweise von meinem Mobil-Telefon in den Bergen
Resource pooling: Die Ressourcen der Cloud sind derart gemanaged, dass ein effizientes Miteinander mehrerer Konsumenten der Cloud möglich ist, und jeder immer das bekommt, was er gerade benötigt
Rapid elasticity: Dadurch sind Services so effizient skalierbar, dass sie sich elastisch an den Bedarf anpassen
Measured: Jeder Konsum eines Services wird exakt gemessen und der Konsum nachvollziehbar dem Nutzer berichtet
Sollten Sie in Ihrem Rechenzentrum – in Ihrer IT – ein Service haben, das die Geschäftsprozesse Ihres Unternehmens nach diesen Gesichtspunkten abbildet, dann haben Sie de facto eine Cloud. Überlegen Sie an dieser Stelle kurz: Haben Sie eine Cloud? Haben Sie ein Cloud Service? Mehrere? Woher? Selbst gebaut? Integriert? … ?
Wir brauchen über die Existenz von Cloud Computing in allen unseren Geschäftsanwendung nicht mehr sprechen (Sie würden sich übrigens wundern, welche Firmen in Österreich beispielsweise vom eigenen Exchange-Server bereits auf Office365 gewechselt sind …)
Reden wir also darüber, was nun auf uns zukommt!
Und da haben Analysten schon vor Jahren – etwa 2013 beginnend – Modelle vorgestellt, die die Cloud in einen größeren Gesamtzusammenhang setzen. Bei IDC hieß das Konzept “The Third Platform” – bei Gartner hieß es “The Nexus of Forces”.
The 3rd Platform (Source: IDC)
Es gibt bestimmt noch andere. Eines ist allen diesen Konzepten gemeinsam: Sie postulieren die nächste Evolution in der IT und erklären diese durch das Zusammenwirken von 4 Kräften:
Cloud Computing
Mobility
Social Business / Social Media
und BigData/Analytics
Während das alles durchaus korrekt sein mag, glaube ich doch, dass diese Konzepte allesamt einen originären Fehler haben: Cloud Computing ist nicht Teil des Ganzen sondern die inherente Basis des gesamten Modells:
Cloud Computing as a basis to the 3rd Platform
Lassen Sie mich an Hand der anderen drei Paradigmen ausführen, warum das so ist.
1: Social Transformation
Social Transformation – from Profiles to Data Feeds
Das Bild oben zeigt wie Facebook 2005 und 2011 ausgesehen hat und wie es heute aussieht. Sie sehen, dass der Fokus am Beginn auf dem Benutzer und dessen Profil, dessen Eigenschaften, dessen Vorlieben lag. Mark Zuckerberg wollte ursprünglich einfach die ganze Welt miteinander verbinden. Dass sich so eine bahnbrechende Idee – wenn sie funktioniert – natürlich perfekt durch Werbung auf der betreffenden Plattform finanzieren lässt, liegt auf der Hand (2011 schon deutlich sichtbar). Heute können Sie viel mehr mit dem sozialen Netzwerk und Ihren eigenen Informationen tun: Sie können sie zu zielgerichteter Information für andere Systeme oder Gruppen von Menschen nutzbar machen: Wenn 1000 Menschen an einer sonst flüssig befahrbaren Verkehrsader jammern, dass sie im Stau stehen, wird das wohl stimmen, und es lässt sich unter Umständen aus den “Social Feeds” der Autofahrer ableiten, was auf der betreffenden Strecke gerade schief läuft.
Und wo ist hier die Cloud? Unter der Plattform “Facebook” selbst, die in einem streng nach Cloud-Elastizitäts-Merkmalen aufgebauten Rechenzentrum läuft, sowie in angeschlossenen Data Lakes, die in der Lage sind, nicht nur derartige Informationen in großem Maß aufzunehmen, sondern eben auch in entsprechend kurzer Zeit auszuwerten.
“BigData summarizes the legal, social, technology, application and business dimension of the fact that through applications being consumed … a vast amount of information is generated and needs to be managed and efficiently used”
Ich habe zur Vereinfachung des Prinzips und seiner Auswirkungen versucht, auf einen Blick darzustellen, wie zukünftig mit Daten umzugehen ist:
BigData Transformation – from ETL to ELT
Machen Sie sich keine Gedanken mehr am Beginn, was Sie am Ende mit den Daten anfangen wollen; sehen Sie, dass Sie der Daten habhaft werden, die sie für Ihr Geschäft benötigen könnten. In welcher Form (in welchem “Format”) auch immer. Eine Transformation zum Zwecke intelligenter Verknüpfung und Auswertung kann später folgen. Wir haben das früher so nicht gemacht, weil wir garnicht die Rechenleistungen bereit stellen hätten können, die nötig sind, um verschieden vorliegende Daten in Echtzeit zu konsolidieren und zu aggregieren. Und selbst ohne diese Fähigkeit waren unsere DWH-Systeme mitunter unwartbare Moloche, oder?
Die Cloud als Basis einer modernen BigData Architektur erlaubt die Elastizität und ad-hoc Rechenleistung, wenn sie zu Analyse-Zwecken benötigt wird.
Übrigens: Das bedeutet keineswegs, dass Sie sich gar keine Gedanken machen sollen, was Sie mit den mühevoll gesammelten Daten anfangen können – ich glaube sogar, dass diese Überlegung essentiell ist, um BigData strategisch effizient zu nutzen; ich glaube nur, dass diese Überlegung nicht mehr am Anfang stehen muss. Und dass dem so ist, ermöglicht uns Cloud Computing.
3: Mobile Transformation
Das ist einfach. Dazu reichen die folgenden beiden Bilder:
A very old mobile phone – some years maybe …
Mobile Payment – Mobile Banking
Zuerst ein Handy, das manche vielleicht noch kennen (es ist, sagen wir, etwa 10 Jahre alt, vielleicht ein bisschen mehr) – dann ein “etwas” Neueres mit implantierter Bankomatkarte (geht in Österreich seit Anfang Juni). Wo da die Cloud ist? Unter dem AppStore für die benötigten Mobile Apps, unter den Backend-Systemen für die Verknüpfung von Services, unter den Services selbst, die in Container-Technologie elastisch auf Benutzeranforderungen reagieren, …
Sie sehen also, Cloud Computing ist nicht eine “Force” in einem “Nexus”, sondern die Basis-Technologie schlechthin, die ein Zusammenwirken der anderen 3 Kräfte im 3rd-Platform-Modell überhaupt erst möglich macht.
Und was durch dieses Zusammenwirken erst möglich wird, lässt sich immer noch am Besten durch den Begriff
“Digital Business”
beschreiben. Ich möchte mich hier gar nicht mehr lang mit Begrifflichkeiten aufhalten (im oben erwähnten White Paper gibt es dazu bereits einiges nachzulesen, und über die Zeit haben sich – wie immer bei solch hochveränderlichen, innovativen Themen – Myriaden von “gscheiten” Menschen damit aufgehalten, was wie genannt werden darf oder muss (erinnern Sie sich nur an die viel-zitierte Behauptung, Industrie 4.0 dürfe nur in der deutschen Sprache verwendet werden, weil es eine Digitalisierungs-Initiative Deutschlands wäre).
Entscheidend ist nicht die Begrifflichkeit sondern das, worum es eigentlich geht: Eine Verbindung von Menschen, Systemen und Endgeräten (Dingen, Devices, Gadgets, …). Sich vor Augen zu führen, welche Möglichkeiten diese Verbindung, wenn intelligent umgesetzt, für uns bringt, bringt Digitalisierung überhaupt erst in Bewegung. In unsern Köpfen, unseren Innovationen – letztlich in unseren Unternehmen und im täglichen Leben.
Im Whitepaper “The Next Big Thing” erzähle ich am Ende ein paar kleine Geschichten; Szenarien, die illustrieren, was durch Digitale Transformation denkbar wird. Mittlerweile sind wir viel weiter als in diesen Geschichten. Teilweise sind die skizzierten Szenarien Realität, teilweise sind ganz neue Szenarien entstanden.
Connected Cars – Ist das heute Realität?
BMW (2014) with connected-car information panel
Vielleicht noch nicht überall. Aber das hier gezeigte Bild entstammt einem Artikel aus 2014. Heute haben alle modernen Fahrzeuge eine In-Vehicle-Plattform, die es ermöglicht, von außen Informationen in das Fahrzeug einzuspielen. An der Nutzbarmachung dieser Möglichkeit für den modernen Verkehr wird gerade gearbeitet.
Oder SmartCity?
Sanatander ist eine von vielen Städten rund um den Erdball, in dem Digitalisierung und die Digitale Transformation Realität geworden sind. Während jedoch beispielsweise in Amsterdam auf der “Beacon Mile” gerade mal ein paar Information an vorbei”gehende” Smartphones verteilt werden können, hat Santander sein gesamtes City Management – von öffentlichem Verkehr, über Taxi, Luftqualität, Beleuchtung, Müllabfuhr, … und vieles mehr auf Digitalisierungs-Paradigmen im oben erwähnten Sinne (Mensch – System – Device) umgestellt. Hier ein Film, der die disruptive Veränderung dieser Initiative für Santander näher erklärt:
Und im Hintergrund arbeitet eine Infrastructure Cloud, die die Integration all dieser Prozesse ermöglicht.
Übrigens: 2 Beispiele aus Wien:
Die SmartCity Strategie der Stadt Wien verfolgt genau die selben Ziele wie Santander
Und in Wien Neubau arbeitet ein Unternehmen gemeinsam mit der Stadt an einer in Kürze produktiv gehenden Multi-Mobilitäts-App, die es ermöglicht, aus mehreren Verkehrsangeboten das für die jeweilige Route beste zu wählen. Können Sie heute bereits als Labor-App nutzen. Laden Sie sich’s einfach vom AppStore runter; sie heißt “WienMobil LAB”.
Und wo ist die Cloud jetzt?
Cost of Broadband Subscription as a Percentage of Average Yearly Income, 2014
Allgemein werden für all diese Digitalen Transformationen 4 Treiber genannt:
Hohe Akzeptanz des Mobil-Telefons, eigentlich des Smartphones
Niedrige Kosten von Sensoren
Und in großem Maß verfügbare Rechenleistung
Da letzteres (nämlich: Rechenleistung) selbstredend in einem Cloud-Modell bereit gestellt wird, beantwortet sich die Frage nach der Allgegenwärtigkeit von Cloud Computing eigentlich von selbst, oder?
Security & Privacy
Security – Privacy – Control – Multi Tenancy
Abschließend noch zwei Wort an alle, die die Digitale Transformation als (persönliche oder unternehmerische) Gefahr empfinden: “Vergessen Sie’s!”
Warum?
Nun – lassen Sie mich das mit einer kleinen Geschichte aus den Anfangszeiten von Cloud Computing in Mitteleuropa beantworten: Im Jahr 2009 war ich zu einer Konferenz als Speaker eingeladen, in welcher Microsoft und Siemens die Potentiale von Cloud Computing gemeinsam zum Thema gemacht und diskutiert haben; damals hat ein sonst großartiger Kollege von Microsoft Multi-Mandanten-Fähigkeit leichtfertiger Weise mit Datensicherheit und Verschlüsselung verwechselt. Ohne den Irrtum auszubügeln, schlitterte sein Talk in eine Diskussion um die Unmöglichkeit, Cloud im Industrie-Bereich anzuwenden, weil es doch unmöglich sei, die eigene Unternehmens-IP vor der Konkurrenz zu schützen. Diese Art der Diskussion blieb uns über Jahre auf einschlägigen Events erhalten. Hat sie die Cloud aufhalten können? Nein.
Wenn Sie möchten, diskutieren wir gerne in weiterer Folge die Elemente
Sicherheit
Privatsphäre
Daten-Kontrolle
und Multi-Mandanten-Fähigkeit
Doch tun wir es bitte auf inkludierender Basis. Schließen wir neue Chancen, neue Dienstleistungen, Alltagserleichterungen nicht aus, weil wir Angst vor einer Verletzung obiger Werte haben, sondern schließen wir diese oben genannten Überlegungen mit ein in die Möglichkeiten, die sich uns auftun – und tun wir das auf Basis der Forderung nach größerer Transparenz!
Wenn ich weiß, was von wem wofür mit meinen Daten gemacht wird, dann werde ich sie gerne – kontrolliert – bereit stellen; weil ich nämlich dadurch einen Vorteil erfahre – in meinen eigenen Prozessen, in meinem eigenen beruflichen und privaten Alltag!
I’ve been following Ruxit for quite some time now. In 2014, I first considered them for the Cloud delivery framework we were to create. Later – during another project – I elaborated on a comparison I did between Ruxit and newRelic; I was convinced by their “need to know” approach to monitor large diverse application landscapes.
Recently they added Docker Monitoring into their portfolio and expanded support for highly dynamic infrastructures; here’s a great webinar on that (be sure to watch closely on the live demos – compelling).
But let’s – for once – let aside the technical masterpieces in their development; let’s have a look on their strategic procession:
Dynatrace – the mothership – has been a well-known player in the monitoring field for years. I am working for quite some customers who leverage Dynatrace’s capabilities. I would not hesitate to call them a well-established enterprise. Especially in the field of cloud, well established enterprises tend to leak a certain elasticity in order to get their X-aaS initiatives to really lift-off; examples are manifold: Canopy failed eventually (my 2 cents; some may see that differently), IBM took a long time to differentiate their cloud from the core business, … some others still market their cloud endeavours sideways their core business – not for the better.
And then – last week – I received Ruxit’s eMail announcing “Ruxit grows up… announcing Dynatrace Ruxit!“, officially sent by “Bernd Greifeneder | Founder and CTO”. I was expecting that eMail; in the webinar mentioned before, slides were already branded “Dynatrace Ruxit”, and the question I raised on this, was answered expectedly, that from a successful startup-like endeavour they would now commence their move back into the parent company.
Comprehensible.
Because that is precisely what a disruptive endeavour inside a well-established company should look like: Greifeneder was obviously given the trust and money to ramp-up a totally new kind of business alongside Dynatrace’s core capabilities. I have long lost any doubts, that Ruxit created a new way of technologically and methodically doing things in Monitoring: In a container-based elastic cloud environment, there’s no need anymore to know about each and every entity; the only importance is to keep things alright for endusers – and when this is not the case, let admins quickly find the problem, and nothing else.
What – though – really baffled me was the rigorous way of pushing their technology into the market: I used to run a test account for running a few tests there and then for my projects. Whenever I logged in, something new had been deployed. Releases happened on an amazingly regular basis – DevOps style 100%. There is no way of doing this within established development processes and traditional on-premise release management. One may be able to derive traditional releases from DevOps-like continuous delivery – but not vice versa.
Bottom line: Greifeneder obviously had the possibility, the ability and the right people to do things in a totally different way from the mothership’s processes. I, of course, do not have insight in how things were really setup within Dynatrace – but last week they took their baby back into “mother’s bosom”, and in the cloud business – I’d argue – that does not happen when the baby isn’t ready to live on its own.
Respect!
Enterprise cloud and digitalisation endeavours may get their learnings from Dynatrace Ruxit. Wishing you a sunny future, Dynatrace Monitoring Cloud!
This final chapter addresses architecture components for typical system orchestrators; comparing these with the blueprints for high-grade innovative automation solutions mentioned previously in this paper will reveal the close resemblance between automation and system orchestration patterns in a very obvious way.
The first figure below is system deployment architecture diagram describing the main physical components for a system orchestrator:
System Orchestration Deployment Architecture
Note, that:
the database normally needs to be setup in a clustered mode for high availability. Most orchestrator solutions do rely fully on the database (at least at design time).
the Management Server’s deployment architecture is depending on availability requirements for management and control.
the Runtime server nodes should be highly distributed (ideally geographically dispersed). The better this is supported by the product architecture the more reliable orchestration will support IT operations.
the Web service deployment is depending on availability and web service API needs (product and requirement dependent)
Logical architecture
The logical architecture builds on the previous description of the deployment architecture and outlines the different building blocks of the orchestration solution. The logical architecture diagram is depicted in the following figure:
System Orchestration Logical Architecture
Notes to “logical architecture” figure:
The Orchestrator DB holds runtime and design time orchestration flows, action packs, activities, plugins, logs, …
Management Server controls access to orchestration artefacts
Runtime Server provides execution environment for orchestration flows
Orchestration designer (backend) provides environment for creation of orchestration flows using artefacts from the database (depending on specific product architecture the designer and management components could be integrated)
Web Service exposes the Orchestrator’s functionality to external consumers (ideally via REST)
Action packs or plugins are introduced through installation at the design time (normally integrated into the DB)
The Orchestrator’s admin console is ideally implemented as web service, hence accessible via browser
The Design Client UI could either be web-based or a dedicated client application to be installed locally and using a specific protocol for backend communication
Of course, these building blocks can vary from product to product. However, what remains crucial to successful orchestration operations (more or less in the same way as with automation) is to have lightweight, scalable runtime components capable of supporting a small scale, low footprint deployment equally efficient to a large scale, multi sight, highly distributed orchestration solution.
The final compelling element to consider in an enterprise-grade automation solution is its ability to dynamically control – in real-time – how automation changes the behaviour of your IT landscape. This includes:
On-demand business process changes requested by stakeholders, mandated by regulatory requirements, or directly affected by events outside of the enterprise’s core business model
Risk of service level (SLA) penalties caused by an application failure or the system’s inability to handle a change of load demand
The ability of the system to support a rapid introduction of a new product line or service to meet changing business needs
When assessing such capabilities, the following architecture patterns within the proposed automation solution are of importance:
Dynamic just-in-time execution
As described earlier, object orientation forms the basis for aggregating artefacts built into the automation solution (such as: actions, tasks, workflows, file processing, reports). This capability shall be provided in a way that automation operations remain sufficiently granular and at the same time allow the solution to act as a large automation ecosystem. More importantly, the solution must retain the ability to dynamically re-aggregate executions on-demand as required.
If the automation platform handles each artifact as an object, then object interaction, object instantiation parameters, or object execution scheduling can be redefined in a matter of minutes. All that’s left is to define the object model of the actual automation implementation for the specific IT landscape – a one time task.
The best automation solutions include a library of IT process automation actions that can be aggregated throughout automation workflows. These “IT process automation” actions are ideally delivered as part of the solution as a whole or specifically targeted to address particular automation challenges within enterprise IT landscapes.
Examples are:
If IT SLA measures reveal a particular IT housekeeping task at risk due to an increase in processing time, dynamic adaptation of the specific workflows would involve assigning a different scheduler object or calendar to the task or re-aggregating the workflow to execute the process in smaller chunks. This assumes end-to-end object orientation and proper object model definition.
If a particular monthly batch data processing workflow is exceeding a particular transfer size boundary, the workflow can remain completely unchanged while chunk size definition is altered by changing the input parameters. These input parameters would themselves be derived from IT configuration management so dynamic automation adaptation would still remain zero-interactive.
Pre/post processing of automation tasks
Not only does dynamic execution require maximum object orientation patterns within the implementation and operation of the automation solution, but it must also provide the ability to:
Change the behavior of an object by preprocessing actions.
Process the output of an object for further use in subsequent automation tasks/workflows.
Adding pre or post execution logic instead of implementing additional objects for the same logic makes it an object property – an inherent part of the object itself instead of treating it as separate object within the model – which rarely occurs with pre or post-processing. These tasks thus become part of the concrete instance of an abstract automation object.
Examples for applying this pattern in automation are:
System alive or connectivity check
Data validation
Parameter augmentation through additional input
Data source query
Dynamic report augmentation
Automation solutions can offer this capability either through graphical modelling of pre and post conditions or in the case of more complex requirements, through script language elements.
Easy-to-use extensible scripting
The scripting language offered by the automation solution is the key to offering a system capable of implementing enterprise-grade automation scenarios. While scripting within automation and orchestration tends to evolve into supporting mainly standard scripting languages such as Python, Perl, JavaScript or VBscript, a solution that offers both standard and proprietary scripting is still optimum.
An automation system’s proprietary scripting language addresses the system’s own object model most efficiently while at the same time – through extension capabilities – enabling seamless inclusion of target system specific operations. The combination of both is the best way to ensure a flexible, dynamic, and high performing end-to-end automation solution.
Another decision one needs to make during the selection process is whether the automation platform needs to support multi tenant and/or multi client capability. How you choose can have a significant financial impact.
Multi tenancy versus multi-client
Multi tenancy is closely related to the Cloud. Although not strictly a cloud pattern, multi tenancy has become one of the most discussed topics in application and service architectures due to the rise of Cloud Computing. That is, because multi tenancy eventually enables one of the essential cloud characteristics, namely: virtually endless scaling and resource pooling.
Multi-tenancy
Multi tenancy partitions an application into virtual units. Each virtual unit serves one customer while being executed within a shared environment together with the other tenants’ units. It doesn’t interact or conflict with other virtual units nor can a single virtual unit remove all resources from the shared environment in case of malfunction (resource pooling, resource sharing).
Multi-client
In contrast, a multi-client system is able to split an application into logical environments by separating functionality, management, object storage, and permission layers. This enables setting up a server that allows logons by different users with each user having their separate working environment while sharing common resources – file system, CPU, memory. However, in this environment, there remains the possibility of users impacting each other’s work.
Importance of Multi tenancy and Multi Client
These concepts are critical because of the need to provide separated working environments, object stores, automation flows for different customers or business lines. Therefore, one should be looking for an automation solution which supports this capability out-of-the-box. In certain circumstances you may not require strict customer segregation or the ability to offer pooling and sharing of resources out of one single environment. This clear differentiation might become a cost-influencing factor in certain cases.
Independent units within one system
Whether your automation solution needs to be multi-tenant or not depends on the business case and usage scenario. Normally in enterprise environments having major systems running on-premises, multi-tenancy is not a major requirement in an automation solution. Experience shows that when automation systems are shared between multiple organizational units or are automating multiple customers’ IT landscapes in an outsourcing scenario, multi-tenancy isn’t required since management of all units and customers is controlled through the central administration and architecture.
Multi-client capabilities, though, are indeed a necessity in an enterprise ready automation solution, as users of multiple different organizations want to work within the automation environment.
Multi-client capabilities would include the ability to:
Split a single automation solution instance into up to 1,000++ different logical units (clients)
Add clients on demand without downtime or without changing underlying infrastructure
Segregate object permission by client and enable user assignment to clients
Segregate automation objects and enable assignment to specific clients
Allow for automation execution delegation of centrally implemented automation workflows by simply assigning them to the specific clients (assuming the specific permissions have been set)
Re-use automation artifacts between clients (including clear and easy to use permission management)
Share use of resources across clients (but not necessarily for secure and scalable resource pooling across clients; see differentiation above)
Segregation of duties
Having multiple clients within one automation solution instance enables servicing of multiple external as well as internal customers. This allows for quick adaptation to changing business needs. Each client can define separate automation templates, security regulations, and access to surrounding infrastructure. Having a simple transport/delegation mechanism between clients at hand, allows to implement a multi-staging concept for the automation solution
Nach langem wieder mal etwas Deutschsprachiges zum Thema “Digitalisierung” auf meinem Blog …
Gestern fand die Veranstaltung “Digitalisierung von Produktionsbetrieben” der Wirtschaftsagentur Wien gemeinsam mit dem Netzwerk “IoT-Austria” statt. Mein Antrieb, an der Veranstaltung teilzunehmen, entstand weniger aus einem konkreten Projektkontext, sondern weil ich neugierig war, was produzierende Betriebe in Österreich zum Thema zu sagen hatten (und wer überhaupt etwas sagen würde).
Spontaneindruck
Ein bunter Mix von Unternehmen unterschiedlicher Größe und völlig unterschiedlicher Produktportfolios (die Palette reichte von Steuergeräten der Fa. Tele Haase über die Schlösser der EVVA bis hin zum AIT mit UX oder LieberLieber mit dem Thema “Modellbasierte Softwareentwicklung”), dadurch ein bunter Mix von Blickwinkeln auf das Thema und ein übergroßes Interesse im Auditorium. Letzteres könnte man natürlich als Buzzword- und Hype-Interesse werten; mir ist die positivistische Interpretation, dass die Wirtschaft und Industrie in Österreich die Themen “IoT” und “Digitalisierung” in großem Stil annimmt, ehrlicherweise lieber …
Was blieb hängen?
In erster Linie vor allem die durchaus gute Qualität der Vorträge. Allesamt recht praxisnahe mit vielen konkreten Beispielen aus dem Alltäglichen des jeweiligen Unternehmens; kaum einmal eine Themenverfehlung und nur einmal aus meiner Wahrnehmung das “Weißwaschen” des eigenen Portfolios mit dem IoT-Begriff (es wäre ein Wunder, wenn nicht auch hier das passierte, was wir bei “Cloud” einige Jahre lang allerorts gesehen haben).
Die eigentlichen Aha-Erlebnisse allerdings waren:
1: Ein neues Anwenderbild
Sebastian Egger vom AIT machte dem Plenum bewusst, wo die Anwender der Digitalisierungswelle tatsächlich sind: In allen Gliedern der Wertschöpfungskette (und nicht am Ende beim Konsumenten des entstandenen Produktes). Prozesse verändern sich teilweise derart radikal, dass jeder einzelne Mitarbeiter in Zuliefer-Industrie, Produktion, Logistik, Endvertrieb, etc. radikal Neues vorfinden wird und damit einer Umstellung unterworfen ist. Wieviele werden dem gewachsen sein? Und welche der kommenden Digitalisierungslösungen kann sich effizient auf diese verschiedenen Anwendergruppen einstellen?
2: Das Alter, das Alter!
Produzierende Betriebe – wie z.B. Tele Haase – haben Innovation mit teilweise langjähriger, gutgängiger industrieller Substanz zu bewältigen. Produzierende Industriemaschinen haben Halbwertszeiten mehrerer Jahrzehnte. Man tauscht nicht so leicht und schnell aus wie man heutzutage Consumer-Elektronik, EDV oder “Dinge” tauscht. Damit geht schwierige Integrierbarkeit in eine innovative digitale Plattform automatisch einher. Auch der Wille zu radikaler Innovation – zur Neuschaffung der Digitalen Fabrik – kann da schon mal an “Banalitäten” wie der Nicht-Integrierbarkeit einer 20 Jahre alten Industrie-Maschine scheitern. Erfolgreiche IoT- und Industrie4.0-Plattformen werden dem in irgendeiner Form gerecht werden müssen.
3: KMUs haben in Österreich ein “Partnerschaftsproblem”
Gut – das mag eine radikale Übersetzung von Peter Liebers Aussage zu der Tatsache sein, dass er so gut wie keine Kunden in Österreich hat. Seine Analyse war jedenfalls, dass österreichische produzierende Betriebe (größtenteils klassische KMUs) ein Problem haben, mit Unternehmen kleiner 20 MitarbeiterInnen zusammen zu arbeiten. Auf Grund der Flexibilität und Dynamik derartiger Unternehmen ist allerdings gerade dort das nötige innovative Potential zu finden. Die Einzelperson – das Ein-Personen-Unternehmen – reagiert oft wesentlich wendiger und schneller auf Trends und Trendwechsel als größere Unternehmen mit meist schwerfälligeren Strukturen. Angst vor einem Verlust des Partners durch Verschwinden des Unternehmens? Nun – ein durchaus valides Argument; dem wäre allerdings die eigene Stagnation in der aktuellen Zeit des radikalen Wandels in Industriebetrieben entgegenzusetzen …
4: 1 Schloss – 16 Mio. Konfigurationen
Absolutes Highlight des Vormittags jedoch der Vortrag von Johann Notbauer von EVVA. Sein Vortrag spannte in gewisser Weise den Bogen über alle an diesem Vormittag behandelten Themen: Ein österreichisches Traditionsunternehmen, das mit langjährig erprobten mechanischen Schließlösungen einen deutlichen Platz am Weltmarkt einnimmt, das mit einem auf Nachgeschäft basierenden Geschäftsmodell den Hauptumsatz einfährt (Notbauer bemühte das Druckermodell als Vergleich für seine Schließsysteme: billiger Drucker gefolgt von teuren Patronen), das mit dem 4-blättrigen Magnetschlüsselsystem MCS 3D-Druck-kopiersichere Schlüssel am Markt hat, ist plötzlich konfrontiert mit
Software
Firmware
Software-Sicherheit
RFID
NFC
…
und vielen anderen noch nie zuvor im Unternehmen gesehenen Herausforderungen. Plus: Das oben zitierte Geschäftsmodell ist mit modernen Schließsystemen, die wesentlich seltenere System- oder Schlüssel-Wechsel nach sich ziehen, im Prinzip kannibalisiert. Kein anderer Vortrag an diesem Tag hat so unmissverständlich und klar deutlich gemacht, was Digitalisierung für ein Unternehmen eigentlich bedeutet und wie radikal man sich darauf einzustellen hat, wenn man reüssieren will.
Und die 16 Mio Konfigurationen aus der Überschrift stimmen wirklich – nur eben nicht mehr für digitale Schließsysteme …
5: Österreich hat ein IoT-Netzwerk
Last not least bleib aber vor allem eines an diesem Tag hängen: In Österreich gibt es bereits jetzt eine recht aktive Community von Menschen, die sich aus freien Stücken zusammengefunden haben, um der Digitalisierung und Industrie 4.0 in diesem Land auf die Beine zu helfen. Das Netzwerk “IoT-Austria” hat diesen Vormittag mit gestaltet, mit einem (zugegebenermaßen fast klassischen, die einschlägigen Themen bemühenden) Impulsvortrag eingeleitet und tritt als solider Mix von Technik-Fachexperten und strategischen Denkern in Erscheinung.
Noch ist das Potential an Unterstützung für die interessierte Industrie und Wirtschaft, das von diesem Netzwerk ausgehen kann, nicht ganz klar, aber die gestrige Veranstaltung zeigte, dass österreichische Unternehmen und vor allem “IoT-Austria” ganz offensichtlich auf einem guten Weg sind, der Digitalisierung in diesem Land auf die Sprünge zu helfen.
Today’s Automation solutions normally are ready-built enterprise products (or a consumable service) offering out-of-the-box functionality for multiple automation, orchestration, and integration scenarios. On top of this, ease of installation, implementation, and use would be of importance.
However, in less than 20% of cases, the automation platform remains unchanged for the first six months. This is why it’s crucial that from the beginning, the selected solution has the ability to extend and adapt in order to serve business needs. The architecture should be able to leverage technologies for hot plugging integrations and industry-standard interfaces while augmenting standard functionality through dynamic data exchange.
Hot plug-in of new integrations
Once basic automation workflows for an IT landscape are implemented, avoiding downtime is critical. While some automation solutions may offer fast and flexible production updates, the expectation on top of that is to be able to integrate new system and application adapters on the fly.
The first step to this level of integration can be achieved by rigorously complying with the SOLID object orientation principles discussed in the last chapter. Integrating adapters to new system or application endpoints, infrastructure management layers (like hypervisors), or middleware components is then a matter of adding new objects to the automation library. Existing workloads can be seamlessly delegated to these new entities, avoiding the need to stop any runtime entities or updating or upgrading any of the system’s components.
Hot-plugging, however, isn’t the main factor in assessing an automation solution’s enterprise readiness. In addition to being able to plug new adapters into the landscape, a truly expandable automation solution must be able to build new adapters as well. The automation solution should offer a framework, which enables system architects and software developers to create their own integration solutions based on the patterns the automation solution encompasses.
Such a framework allows for the creation of integration logic based on existing objects and interfaces, self-defined user interface elements specific to the solution’s out-of-the-box templates. Extensions to such a framework include a package-manager enabling third party solutions to be deployed in a user-friendly way. It must also take into account any dependencies and solution versions and a framework IDE enabling developers to leverage the development environment to which they are accustomed (e.g. Eclipse and Eclipse plugins).
Herewith, plugging new integrations into an automation solution can expand the automation platform by leveraging a community-based ecosystem of 3rd party extensions.
Leverage industry standards
Hot plugging all-new automation integration packages to adapt and expand your automation platform might not always be the strategy of choice.
In a service-based IT-architecture, many applications and management layers can be integrated using APIs. This means that an automation solution needs to leverage standards to interface with external resources prior to forcing you into development effort for add-ons.
The automation layer needs to have the ability to integrate remote functionality through common shell-script extensions like PowerShell (for Microsoft-based landscapes), JMS (Java Message Service API for middleware integration), REST (based on standard data formats like XML and JSON), and maybe (with decreasing importance) SOAP.
Dynamic data validation & exchange
Part of the adaptability and extensibility requirement is for the product of choice to be able to process and integrate the results of the resources previously discussed into existing object instances (as dynamic input data to existing workflows) without having to develop customized wrappers or additional interpreters.
This can be achieved through either variable objects – their values being changeable through integration like DB queries or Web Services results – or through prompts that allow to set variable values through a user input query.
To be truly extensible and adaptable, an automation solution should not only offer manual prompts but it should be able to automatically integrate and present those prompts within external systems. The solution should be responsible for automating and orchestrating IT resources while other systems – a service catalogue or request management application – handles IT resource demand and approval.
Together, all of the above forms the framework of an automation solution that can be extended and adapted specifically to the needs of the business leveraging it.
This blog post kicks off a series of connected publications about automation and orchestration solution architecture patterns. The series commences with multiple chapters discussing key criteria for automation solutions and will subsequently continue into outlining typical patterns and requirements for "Orchestrators". Posts in this series are tagged with "Automation-Orchestration" and will ultimately together compose a whitepaper about the subject matter.
Introduction & Summary
Recent customer projects in the field of architectural cloud computing frameworks revealed one clear fact repeatedly: Automation is the utter key to success – not only technically for the cloud solution to be performant, scalable and highly available but also for the business, which is using the cloudified IT, in order to remain in advantage compared to competition as well as stay on the leading edge of innovation.
On top of the automation building block within a cloud framework, an Orchestration solution ensures that atomic automation “black boxes” together form a platform for successful business execution.
As traditional IT landscapes take their leap into adopting (hybrid) cloud solutions for IaaS or maybe PaaS, automation and orchestration – in the same way – has to move from job scheduling or workload automation to more sophisticated IT Ops or DevOps tasks such as:
Provisioning of infrastructure and applications
Orchestration and deployment of services
Data consolidation
Information collection and reporting
Systematic forecasting and planning
In a time of constrained budgets, IT must always look to manage resources as efficiently as possible. One of the ways to accomplish that goal is through use of an IT solution that automates mundane tasks, orchestrates the same to larger solution blocks and eventually frees up enough IT resources to focus on driving business success.
This blog post is the first of a series of posts targeted at
explaining key criteria for a resilient, secure and scalable automation solution fit for the cloud
clearly identifying the separation between “automation” and “orchestration”
providing IT decision makers with a set of criteria to selecting the right solutions for their need of innovation
Together this blog post series will comprise a complete whitepaper on “Automation and “Orchestration for Innovative IT-aaS Architectures” supporting every IT in its strive to succeed with the move to (hybrid) cloud adoption.
The first section of the paper will list key criteria for automation solutions and explain their relevance for cloud frameworks as well as innovative IT landscapes in general.
The second section deals with Orchestration. It will differentiate system orchestration from service orchestration, explain key features and provide decision support for choosing an appropriate solution.
Target audience
Who should continue reading this blog series:
Technical decision makers
Cloud and solution architects in the field of innovative IT environments
IT-oriented pre- and post-sales consultants
If you consider yourself to belong into one of these groups, subscribe to the Smile-IT blog in order to get notified right away whenever a new chapter of this blog series and whitepaper gets published.
Finally, to conclude with the introduction let me give you the main findings that this paper will discuss in detail within the upcoming chapters:
Key findings
Traditional “old style” integration capabilities – such as: file transfer, object orientation or audit readiness – remain key criteria even for a cloud-ready automation platform.
In an era where cloud has become a commodity, just like the internet as such, service centered IT landscapes demand for a maximum of scalability and adaptability as well as multi-tenancy in order to be able to create a service-oriented ecosystem for the advancement of the businesses using it.
Security, maximum availability, and centralized management and control are fundamental necessities for transforming an IT environment into an integrated service center supporting business expansion, transformation, and growth.
Service orchestration might be the ultimate goal to achieve for an IT landscape, but system orchestration is a first step towards creating an abstraction layer between basic IT systems and business-oriented IT-services.
So, with these findings in mind, let us start diving into the key capabilities for a cloud- and innovation-ready automation solution.
Is it – as a committed social media aficionado – applicable to call for an opt out of it all? It is, once you’ve read “The Circle”, the 2013 fictional novel by author Dave Eggers.
Eggers portraits a powerful internet company making money through advertising (links to Google or Facebook are purely accidental, of course). Mae Holland is a tech worker and in her second job after having graduated she’s given an opportunity at The Circle – an opportunity which most tech workers these days desperately seek for. Mae got support from her college roommate Annie who had already made it to the group of the 40 most senior managers in the company, directly reporting to the founders – “Three Wise Men”: Tom Stenton, Eamon Bailey and Ty Gospodinov. While the first two actively involve themselves in the company’s endeavours, Ty works on new developments mostly secluded in the background.
Mae starts in Customer Experience and works herself up the chain by overcommitting to objectives and seemingly easily (but in truth with great personal effort and sacrifice) following the increasingly demanding involvement not only in her work duties but also all virtual and physical social interaction with fellow colleagues. She not-falls-in-love with one nerdy Circler she has sex with, whom she somehow admires for his technological development of a system protecting children from violence; she commences to desperately long for encounters with another Circler, who becomes increasingly mysterious as the company develops itself more and more towards total transparency.
Eggers, the author, does not keep the reader long from his message: One of the first major announcements of one of the Wise, Eamon Bailey, is a development called “SeeChange” – an extremely low-cost, top-quality A/V camera, capable of running on battery for about 2 years and streaming its crystal clear 4k images via satellite onto the SeeChange platform. Anyone can install cameras anywhere, they are barely noticed and everybody can logon to SeeChange with their unique – very personal and real – identity, their “TruYou”.
Rings a bell? Well, this is only the starting point into a rollercoaster of more awesomely cool technology tools, all aggregated through “TruYou” and made available to everyone anytime.
Dave Eggers is brilliantly creating a staggering balance between technological blessings and their benefit for employees, communities and the people as a whole on the one hand and the increasing sacrifice individuals could be demanded to make on the other hand in order to leverage that technological advance. This is – in short – the utter embarrassing red line throughout the whole book from the very first page until the closing line.
Of course, “The Circle” addresses the time we spend in social media, the way we communicate with each other (personally and virtually), the blessings and the threats that a modern, technology-based life bears. While reading, I was constantly torn between appreciating the sketched development (note: this isn’t science fiction, this is just the next step in a logical advance that we’re facing) and detesting the commitment it would demand from the ones making real use of it. Being into like two thirds of it and swallowing the book’s lines in nightly sessions, my only remaining questions was this: Will Eggers eventually manage to destroy my thorough belief in the two main importances of modern social media involved life and communication:
Utter transparency: I want to always know – or: be able to know – who does what with my data
And utter free will: I want to always be allowed to opt out, if I want to
I will not disclose the answer – I’d be “spoiling”. BUT – if you haven’t done so far, I recommend: Read “The Circle”. And then consider carefully, where and what to opt in or opt out of. It remains important.
P.S.: There’ll be a movie comin’ this year, starring Tom Hanks as Eamon Bailey. Don’t read the articles on it, as they all contain spoilers on one important turn of the story!
