Laden...

Einsatz von Standard-Tools oder Eigenprogrammierung?

Erstellt von tASven vor 7 Jahren Letzter Beitrag vor 7 Jahren 6.441 Views
T
tASven Themenstarter:in
62 Beiträge seit 2012
vor 7 Jahren
Einsatz von Standard-Tools oder Eigenprogrammierung?

Da wir bei uns in der Firma aktuell eine Diskussion darüber haben, wollte ich diese hier im Forum auch mal anzetteln.

Es geht hier im Speziellen darum wie viel Standard-Tools gesund sind.. oder eben nicht.

Ein Beispiel:
Wir haben ein Ticket-System im Einsatz, welches ein Azubi während seiner 3 Jährigen Ausbildung programmiert hat.
Jetzt ist die Argumentation, dass man besser hätte ein Standard-Ticket-System kaufen können weil wir da versucht haben etwas zu bauen, was überhaupt nicht unsere Kernkompetenz ist (wir bauen eine Speditionssoftware).
Folgende Probleme bringt dieses selbst gebaute Ticket-System mit sich:

  • "keiner" kann dieses Programm anpassen
  • fehlende Dokumentation
  • Teilweise Heftiger Grützcode (ist halt von nem Azubi wo nicht immer jemand drüber geschaut hat)
  • Fehlende grundlegende Funktionen (z.b. Auto-Reply, Tickets aus E-Mails erzeugen, etc...)

Von solchen Beispielen gibt es so einige kleine und größere Tools, die irgend jemand mal gebaut hat, eine Zeit lang funktioniert haben - und wenn sie es nicht mehr tun, keiner mehr weiter weiß.

Darum jetzt die neue Anforderung: keine Eigenen Tools mehr bauen, sondern nur noch Standard-Software für Standard-Tools einsetzen. Dies hat z.B. auch den Vorteil, das ein "neuer" Mitarbeiter im Unternehmen diese Standard-Tools erlernen kann, was bei Eigenprogrammierungen eher nicht so gut geht, weil im schlimmsten Fall überhaupt keiner weiß wie dieses Tool denn korrekt funktioniert.

Ich als Entwickler denke wie folgt darüber:

  1. Eigenprogrammierungen sind wichtig für die persönliche Weiterbildung
  2. Die oben beschriebenen Probleme deuten auf falsche bzw. mangelnde Organisation hin.

Natürlich möchte ich das ein oder andere kleine Tool selbst bauen - immerhin möchte ich neu gewonnenes Wissen auch irgendwo anwenden können - wenn ich dies nicht in der bestehenden Software tun kann, welche meine Kernkompetenz darstellt, dann muss ich dies zwangsweise in einem anderen Projekt umsetzen.
Grundsätzlich muss man aber ein gewisses Bauchgefühl dafür haben, was Sinn macht selbst zu bauen - und was keinen Sinn macht, weil es schon X-Fach öffentlich erhältlich ist.

Darum jetzt die Frage an euch:
Wie viele Standard-Tools setzt ihr in euren Unternehme ein, und wie viele Tools habt ihr selbst Programmiert (obwohl es nicht eure Kernkompetenz ist), weil ihr meint das es euer Tool noch nicht gibt, ihr es besser machen, oder die kommerzielle Alternative einfach viel zu teuer wäre?

49.485 Beiträge seit 2005
vor 7 Jahren

Hallo tASven,

der Trend geht eindeutig zu Standard-Software, und das ist auch grundsätzlich sinnvoll. Allerdings ist das eben auch nicht ohne Probleme.

Bei einer Firma A, die ich kenne, ist die Entscheidung, ob ein Azubi ein Ticketsystem programmieren oder ein fertiges Ticketsystem eingekauft werden soll, genau andersherum ausgegangen als bei euch.

Mittlerweile wurde die Firma B, die das eingekaufte Ticketsystem (das Teil eines größeren Managementsystems ist) entwickelt hatte, von einer anderen Firma C geschluckt. Die Produktlinie der übernommenen Firma B wurde jedoch nicht weitergeführt, sondern nur Teile davon (und damit ist gerade nicht die Oberfläche gemeint) in das Produkt der Firma C integriert. Ein Update auf die neue Version hat daher bei der Firma A einen großen Umstellungs- und Anpassungsaufwand produziert und das Ergebnis war trotz dieses Aufwandes so wenig brauchbar, dass jetzt ein neues Ticketsystem beschafft werden soll.

Ich gehe davon aus, dass der (sehr gute) Azubi des Grundfunktion des Ticketsystems wohl ohne Weiteres in einem Monat hätte realisieren können. Und dann vielleicht noch ein, zwei Monate, um es so zu ergänzen, dass es alle Anforderungen (so gut wie) perfekt erfüllt. Dem gegenüber standen beim Kauf Anschaffungskosten im mittleren fünfstelligen Bereich. Selbst wenn beides in einem Totalverlust geendet hätte, wie es bei der (zweiten) Kaufsoftware tatsächlich eingetreten ist, hätte die Azubi-Lösung weit geringere Kosten verursacht - bei möglicherweise für die konkrete Firma in der Zwischenzeit besser passenden Lösung.

Sobald es jedoch um komplexere Software geht, die zudem ständigen äußeren Einflüssen (z.B. geänderte Benutzeranforderungen, Gesetzesänderungen, Änderungen von Schnittstellen wie SEPA statt Lastschrift) ausgesetzt ist, wird es wohl so sein, dass der Änderungsaufwand bei einer selbst entwickelten Software den Kaufaufwand - selbst für einen ggf. erforderlichen Neukauf - einer Standard-Software schnell übersteigen. Deshalb sollte man sich schon genau überlegen, wo eine Eigenwicklung sich auch auf die lange Sicht rechnet.

herbivore

16.806 Beiträge seit 2008
vor 7 Jahren

Finde die Frage zu weit gefächert.
Du wirst bei großen Unternehmen SAP und Sharepoint finden, bei dem durch Freelancer i.d.R. die Workflows angepasst und programmiert werden. Da machste aus ner 15.000€ Investition schnell ne Million Ersparnis.
Ab einer gewissen Größe musst Du einfach zumindest Erweiterungen oder Anpassungen durchführen (können).

Meine alte Firma - eben so ein Großunternehmen - hat i.d.R. immer Standardtools für die IT-Landschaft gesucht.
Erst wenn nichts gepasst hat, hat man entweder versucht was zu finden, was man anpassen kann - und im letzten Schritt selbst entwickelt.

Ticketsysteme waren mind. 3 im Einsatz, wobei nur eines selbst entwickelt war. Aber soweit ich das nun als nicht mehr Betriebsangehöriger mitbekommen hab, wollen sie auch das standardisieren.

Bei so einer Anforderung musst Du immer zuerst an die Firma denken.
Ist ja schön, dass Du was anwenden willst - das will jeder Entwickler - aber es bringt nichts, wenn es ein infrastrukturelles Thema ist, das der Firma eher langfristig ein Problem macht als hilft.

Solche Service Desk Systeme fangen zB bei Atlassian bei 10€/Monat/Mitarbeiter an.
Das kannst Du niemals so günstig selbst entwickeln oder anpassen - und am Ende auch nicht so günstig betreiben.

3.003 Beiträge seit 2006
vor 7 Jahren

Wir haben ein Ticket-System im Einsatz, welches ein Azubi während seiner 3 Jährigen Ausbildung programmiert hat.

So fangen tolle Geschichten an, die sich Programmierer gegenseitig am Lagerfeuer mit der Taschenlampe unterm Kinn erzählen 😁

Wie viele Standard-Tools setzt ihr in euren Unternehme ein, und wie viele Tools habt ihr selbst Programmiert (obwohl es nicht eure Kernkompetenz ist), weil ihr meint das es euer Tool noch nicht gibt, ihr es besser machen, oder die kommerzielle Alternative einfach viel zu teuer wäre?

  • sämtliche Tools für continous integration, sämtliche Tools, die in Richtung Softwaremanmagement gehen - auch das Ticketsystem -, Quellcodeverwaltung, Code-Qualitätssicherungstools, kurz die gesamte Infrastruktur ist nicht von uns. Wieso? Weil das nicht unsere Kernkompetenz ist. Weil wir damit kein Geld verdienen.

  • es existieren jede Menge kleine Tools, die von uns sind, und das Leben leichter machen für Anwendungsfälle, die speziell bei uns auftreten. Fast alle (mir würde jetzt nicht ein einziges Gegenbeispiel einfallen) sind ursprünglich von einem Entwickler gebaut worden, um sich selbst die Arbeit zu erleichtern. Darunter fallen so Dinge wie ein Datenbank-Managementtool (eine Art Sql Management Studio light), das aber vollständig über unseren DAL läuft, also nicht direkt auf die DB zugreift. Ein Tool, das die Build-Dateien für nant automatisch aus den VS-Projektmappen generiert und dabei unsere Besonderheiten berücksichtigt. Ein Tool, das unsere Hardwäre ähnlich anspricht wie die Software, die der Kunde benutzt, nur viel mehr kann. Erweiterungen für unser firmeninternes Wiki (das nicht von uns ist). Erweiterungen für die ständig und kontinuierlich laufenden Tests.

Im Endeffekt alles, was die Produktivität steigert, aber so speziell ist, dass es kein Tool dafür bereits gibt.

Aber wie gesagt, gute Geschichten fangen nicht mit Sätzen wie "wir brauchten ein Wiki, und haben uns da etwas selbst programmiert" an 😉. Es sei denn, man hat vor, ein Wiki-Anbieter zu werden.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

T
tASven Themenstarter:in
62 Beiträge seit 2012
vor 7 Jahren

Unser Wiki war vorher ein Jahrelang ein Dokuwiki mit 3 kleineren Plugins welche wir selbst gebaut hatten.
Da in dem Dokuwiki nur begrenzt dokumentiert wurde (Argumentation: diese Wiki-Syntax sei viel zu umständlich, Bilder lassen sich nur umständlich einfügen) wurde über längere Zeit ein neues Wiki gesucht und letzendlich wurde sich für Confluence entscheiden.
In der tat wird seit dem mehr dokumentiert (vor allem, wenn man es mit Bildern dokumentieren kann und möglichst wenig dazu schreiben muss) - aber auch hier dibt es diverse defizite wie z.b. Fehlende Formatierungsmöglichkeiten was Schriftarten und Farben angeht. Außerdem kann man namensräume nicht mehr so nutzen wie man es vorher gewohnt war, weil eine Seitenname (z.B. "Info") nur ein einziges mal im ganzen namespace vorkommen kann.
Das ganze Confluence hat uns nicht nur die Investitionskosten der Software gekostet, sondern auch eine massive Hardware-Erweiterung des "Wiki-Servers".
Wo das Dokuwiki vorher ein simples PHP Script war, welches auf einer VM mit einer vCPU und 512MB RAM auskam, läuft Confluence jetzt halbwegs flüssig auf einer VM mit 4 vCPU´s und 8 GB RAM - wie gut das Hardware-Preise immer mehr sinken 😉
Zusätzlich hat sich noch niemand die zeit genommen die Einträge aus dem alten Wiki in Confluence zu übertragen, weshalb aktuell 2 Wiki-Systeme im Einsatz sind - wobei das Dokuwiki nur readonly ist.

Immerhin dokumentieren die meisten Entwickler hier jetzt mehr.

Ein anderes Beispiel ist unser Interne Build-Infrastruktur.
In der Basis ist es ein CruiseControl.net mit viel MSbuild und NAnt Scripten, etwas WIX für Installer und noch ein haufen anderer tools.
Dieses ganze System ist zum größten Teil entstanden weil anfangs keine finanziellen Mittel da waren um sich z.b. einen TFS anzuschaffen und dafür Schulungen zu bekommen. Darum der Weg der Open-Source / kostenlosen Tools und "learning by doing".
Das ganze System funktioniert sehr gut und sehr stabil - es wird jedoch nicht als "Standard" angesehen. Ein Standard wäre nach heutigen Vorstellungen eben z.B. ein TFS der diese ganze Build-Geschichte übernimmt, integrierte Quellcode-Verwaltung und Integriertes Projektmanagement mitbringt.
Vermutlich wird es auf kurz oder lang eines der nächsten Projekte sein alles auf TFS umzubauen.
Jedenfalls ist hier auch wieder die Aussage vom "Entscheider": "Das sind alles nur irgendwleche kleinen Tools, welche sich irgendwer mal zusammen gesucht hat - aber kein aktueller Standard, für den man im Idealfall ein gewissen KnowHow von neuen Mitarbeitern erwarten kann".

16.806 Beiträge seit 2008
vor 7 Jahren

Wir haben auch Confluence genutzt und wenn man es richtig verwendet, dann gibt es keine/sehr wenig Probleme.
Dass eine Bezeichnung in einem Namensraum nur ein mal verwendet werden kann, ist erstklassig - aber ihr braucht dazu ein Konzept. Wenn ihr mehrfach die gleiche Seite in einem Namensraum angelegen wollt, dann stimmt zB das Konzept nicht. Bzw. ist das ein Hinweis auf eine suboptimale Struktur.
Jeder sollte so ein Wiki nach gemeinsamen Regeln nutzen, sodass die Qualität nicht Kraut und Rüben ist. Das gilt auch für die Formatierung.
Dann hat man richtig Spaß damit und man nutzt es auch besser und mehr.

Confluence ist wie die gesamte Atlassian Suite Ressourcen hungrig.
Aber deswegen gibt es auch - vermutlich unterm Strich auch günstiger - das Cloud Hosting.

Warum ist eine Gesamtlösung in der Cloud (zB. Visual Studio Team Services) nichts für euch?
Da kriegste für nen paar Euro im Monat alles für einen Application Life Cycle. Für kleine Teams sogar kostenlos.

Ein paar Vorteile als Ausschnitt:
* keine Hardware Kosten
* keine Hardware Wartung
* keine Software Wartung
* i.d.R. höhere Verfügarkeit
* Datenschutz ist der selbe, da Europa
* einfache Administration
* eine Gesamtlösung
* Steuerlich attraktiver

T
tASven Themenstarter:in
62 Beiträge seit 2012
vor 7 Jahren

Warum ist eine Gesamtlösung in der Cloud (zB. Visual Studio Team Services) nichts für euch?

Ganz einfach: Wegen dem "Cloud".
Der Quellcode unserer Anwendungen liegt ausschließlich Inhouse und auf Band bei den Geschäftsführern zu Hause im Safe 😉

Dazu kommen Argumente wie: "Wir wollen uns nicht abhängig machen" oder "Da weiß doch niemand was mit den Daten passiert" oder "Wenn das Internet weg ist, können wir alle nicht mehr arbeiten".

ne ne ne.. mit Cloud brauchst du hier nicht zu kommen 😉

H
523 Beiträge seit 2008
vor 7 Jahren

Darum jetzt die Frage an euch:
Wie viele Standard-Tools setzt ihr in euren Unternehme ein, und wie viele Tools habt ihr selbst Programmiert (obwohl es nicht eure Kernkompetenz ist), weil ihr meint das es euer Tool noch nicht gibt, ihr es besser machen, oder die kommerzielle Alternative einfach viel zu teuer wäre?

Ich vertrete bei mir im Unternehmen den Standpunkt, dass man das Rad nicht selbst neu erfinden muss wenn es passende Standardsoftware gibt. Warum sollte man beispielsweise ein Ticketsystem selbst entwickeln und warten, wenn es fertige Systeme gibt? Warum sollte man sich neben dem Tagesgeschäft auch noch damit belasten? Ich bleibe lieber bei unserer Kernkompetenz: Entwicklung und Wartung unserer branchenspezifischer Lösungen.

Weiteres Beispiel:
Wir haben einen großen Kunden (mit mehreren tausend Filialen in Deutschland, also entsprechend große IT-Abteilung) der einige Tools von uns entwickeln lässt weil er sicherstellen möchte, dass das Know-How für die Tools nicht verloren geht wenn ein Entwickler seiner IT-Abteilung das Unternehmen verlässt.

16.806 Beiträge seit 2008
vor 7 Jahren

ne ne ne.. mit Cloud brauchst du hier nicht zu kommen 😉

Ok.
Ihr entscheidet offensichlich nicht Anhand von Fakten und Zahlen, sondern aus "Aber"-Gründen.
Dann wundert mich nicht wirklich, dass ihr eure Infrastruktur stand heute nicht plant und es an allen Ecken hakt 😉

Man muss die Cloud nicht nutzen. Niemand wird (gezwungen).
Aber man sollte zuhören und nicht so Käse-Argumente wiedergeben, mit denen man sich eigentlich nur selbst ins Bein schießen kann. 😉

OnPremise ist in den aller meisten Fällen viel teurer, viel mehr Aufwand, weniger Flexibel.
Das müsst ihr halt akzeptieren und dürft euch dann nicht in diesem Punkt beschweren.
Könnt ihr denn selbst die wichtigen Punkte wie Ausfallzeiten in eurer Infrastruktur so beantworten, dass ihr mit mindestens gleichwertigen Ergebnis raus kommt?
Alles redundant, auch ein zweites, gespiegeltes RZ am Standort? Wenn nicht, dann ist das Äpfel vs. Birnen und Schönrederei - nichts anderes 😃

T
tASven Themenstarter:in
62 Beiträge seit 2012
vor 7 Jahren

Ich denke dieses Erwachen kommt erst, wenn es so einen Ausfall mal wirklich gab 😉
Server und Storage sind redundant bei uns ausgelegt - ausfälle gab es shon öfter, aber nicht so schlimm das man nicht weiter arbeiten konnte.

16.806 Beiträge seit 2008
vor 7 Jahren

Redundant heisst nicht, dass ein zweiter Server bereit steht.
Redundant heisst auch, dass der Standort abfackeln kann und trotzdem alles (noch) da ist.

Wie ist eure IT dahingehend geschützt, dass ein Mitarbeiter einen kleinen Hass hat und einfach den Quellcode zieht (kein Entwickler, der den Source eh hat)?
Frage ich wegen

"Da weiß doch niemand was mit den Daten passiert"

Einfach mal ne Stunde mit der Cloud beschäftigen, dann lernt man die Prinzipien von AWS/Azure mit dem 4/6 Augen Prinzip bzgl. Kunden(betriebs)daten.

Ich sag das deshalb, da ich selbst aus einer Speditionsinhaber-Familie komme.
Auch hier ist das Thema Cloud omnipräsent, das heisst die Fahrer wollen ne App für die Fahrtverwaltung, die Disponenten ne Übersicht, wo der Fahrer ist und wann er Leer ist.
Optimalere Wege automatisch berechnet anhand von Fähr-Fahrzeiten, Stau-Vorhersagen etc etc...

Ihr könnt aber keine moderne Speditionssoftware erstellen, wenn ihr das Thema nicht selbst akzeptiert und umgehen lernt 😉
So, was ihr macht, Cloud einfach "vergessen" / verdrängen ist ne Milchmädchenrechnung, Dart via Blinde Kuh. Nicht mehr, nicht weniger.

Das gilt für die von euch eingesetzten Tools wie auch eure Software.

Vielleicht evaluiert ihr die Cloud mal richtig und kommt evtl. auf eine Speditionssoftware as a Service Marktlücke 😉

Noch ne Anekdote, womit ich das Cloud Thema für eure Software Evaluierung von meiner Seite als Diskussionsgrundlage abschließen will:
mein MVP Kollege Mike Kaufmann hat dazu in seinem Vortrag "Der agile Festpreis mit Scrum und Prince2" auf den ALM Days nen nettes Zitat von Gartner gebracht (1:45min).

Schon bis 2017 wird jedes vierte Unternehmen seine derzeitige Marktposition aus Gründen "Digitaler Inkompetenz" verlieren.

C
1.214 Beiträge seit 2006
vor 7 Jahren

Darum jetzt die Frage an euch:
Wie viele Standard-Tools setzt ihr in euren Unternehme ein, und wie viele Tools habt ihr selbst Programmiert (obwohl es nicht eure Kernkompetenz ist), weil ihr meint das es euer Tool noch nicht gibt, ihr es besser machen, oder die kommerzielle Alternative einfach viel zu teuer wäre?

Ich finde die Frage jetzt etwas zu allgemein formuliert, weil ein "Tool" alles mögliche sein kann.
Gerade ein Ticketsystem ist nichts, was ich selber schreiben würde, u.a. weil es schon so viele ausgereifte Systeme auf dem Markt gibt. Muss man nicht mal kaufen, gibt genug Open Source. Und trotzdem haben wir ein eigenes 😉 Weil das vor 15 Jahren mal ein Open Source Produkt war, dass wir immer weiter erweitert und umgebaut haben und das hat mit dem Originalprodukt überhaupt nichts mehr zu tun. Das ist auch sehr stark an unsere Bedürfnisse angepasst, ins CRM integriert, bildet unsere Workflows ab usw... Nichts, was ein Azubi in paar Monate schreibt, da waren Vollzeitentwickler jahrelang beschäftigt und arbeiten immer noch dran. So wirklich sinnvoll finde ich das immer noch nicht, aber ich kenne mich da auch nicht im Detail aus und weiß auch nicht, was er für fertige Lösungen gibt und wieviel Aufwand es wäre, ein fertiges System entsprechend anzupassen.

T
2.219 Beiträge seit 2008
vor 7 Jahren

@Coder007
Soetwas in der Art haben wir auch erst vor einigen Monaten angefangen.
Unser Support hat ein Open-Source Ticketsystem bekommen.
Dieses soll aber bei eingehenden Mails dann in unserem Bugtracker direkt aus den Email Texten einen Bugtracker Punkt anlegen.

Die fertig Lösung wurde dabei angepasst und läuft auch seit einiger Zeit Problemlos.
Es macht eben kaum Sinn solche Standardprobleme immer von Grund auf neu zuentwickeln.

Gerade wenn ich höre, dass der Azubi dies machen soll, halte ich das schon für einen sehr schlechten Ansatz.
Azubis haben kaum Erfahrung um solche Systeme sauber und auch nach einige Prinzipien der OOP umzusetzen.
Dabei meine ich z.B. Wartbarkeit und Wiederverwendung.
Solche Feinheiten lernt man erst im laufe von einigen Jahren.
Und wenn sich schon Probleme wie fehlende Dokus und unsauberer Code aufzeigen, dann ist der Code wahrscheinlich an vielen Stellen redundant und ggf. unperformant.

Solche Systeme, wie schon geschrieben, sollte man auch nicht selbst entwickeln wenn es schon Open-Source Systeme gibt.
Spart euch am besten die Zeit + Geld und nehmt eine fertige Lösung, die eure Bedürfnissen zum großteil entspricht und passt diese an.

@Abt
Unsere Firma entwickelt eine Flottenlösung, die auch für Speditionen ausgelegt ist.
Wir nutzen nur eigene Hardware, da die Cloud hier nicht den Bestimmungen beim Thema Datenschutz entsprechend kann.
Würde mich ehrlich wundern, wenn ihr eure Software ohne Bedenken in die Cloud bei Amazon/Microsoft auslagert.
Soll nichts gegen die Systeme an sich sein, aber viele Kunden würden ein System, was nicht auf dedizierter Hardware läuft, nicht akzeptieren.
Hier müssen wir sogar häufig entsprechende Verträge mit dem Kunden abschließen in dem wir auch zusichern, dass die Daten bei uns auf unseren Servern und nicht in der Cloud liegen.
Ebenfalls müssen wir auch gewährleisten, dass die Daten wirklich nur für diesen Dienst gespeichert und verarbeitet werden.
Also ganz so einfach und bedenkenlos alles in die Cloud auslagern ist gerade im B2B Bereich keine Option.
Können uns aber gerne per PM unterhalten, möchte das Thema hier nicht zu sehr vertiefen 😮

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

16.806 Beiträge seit 2008
vor 7 Jahren

Wir nutzen nur eigene Hardware, da die Cloud hier nicht den Bestimmungen beim Thema Datenschutz entsprechend kann.
T-Virus

Die Aussage ist einfach Käse und unwahr. Und wegen solchem verbreiteten Irrsinn und Falschberatung haben so viele Angst vor Cloud.
Richtlinie 95/46/EG gilt für eigene Rechensysteme genauso wie für die Cloud. Zudem gibt es 2010/87/EU, die ebenfalls vollständig erfüllt wird - schon ewig.

Rest per PN.

T
2.219 Beiträge seit 2008
vor 7 Jahren

@Abt
Hab dir schon per PM geschrieben.
Das Thema können wir dort weiterbesprechen.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

T
tASven Themenstarter:in
62 Beiträge seit 2012
vor 7 Jahren

Könnt ihr mir die Sachen bitte auch schicken? Fände ich auch interessant 😃

709 Beiträge seit 2008
vor 7 Jahren

Ich muss gestehen, dass ich die Diskussion auch gern weiterverfolgen würde.

16.806 Beiträge seit 2008
vor 7 Jahren

Die Diskussion ist bereits beendet - wer aber gern über Cloud reden möchte, da nehm ich mir die Zeit.
Da persönliche Inhalte in den PNs enthalten waren, möchte und werde ich die PNs so nicht 1:1 veröffentlichen.

Wenn es mehrere Personen sind - die wirkliches Interesse haben - dann eröffne ich einen Cloud-Diskussions-Thread.
Läuft es auf eine Stigmatisierung raus, werde ich das aber schnell wieder beenden 😃

Schickt mir per PN einfach die Themen, die euch bei der Cloud interessieren (Datenschutz, Zugriffsschutz, Zugriffslegitimation, Skalierung...).
Die erwähne ich dann im Eingangspost des Diskussionsthread, sodass die Antworten dann darauf basieren können.

Ich werde dann am Mittwoch ein Thema eröffnen.

16.806 Beiträge seit 2008
vor 7 Jahren

Viel Spaß beim Lesen
Cloud Diskussion