Technologie

//Eine Frage neulich auf Reddit, und meine spontane Antwort dazu. Aus dem Englischen übersetzt und leicht angepasst.//

//Die Frage://

Mein Arbeitgeber hat vor etwa einem Jahr Scrum eingeführt, und wir haben's jetzt endlich drauf. Wir haben ein großartiges Team im Einsatz, und dazu die richtigen Führungskräfte. Ich war bisher Fachexperte, und habe das Jahr über eng mit dem Scrum-Team zusammengearbeitet. Das hat mir echt Spaß gemacht. Nun werde ich zu einem Product Owner, und bin ziemlich aufgeregt. Ich habe eine ganze Menge Wissen über unser Geschäft. Über die vergangenen acht Jahre habe ich ein Team geleitet - es wird Zeit für eine neue Herausforderung. Habt Ihr Ratschläge für den Übergang? Mein Arbeitgeber will mich zu einer Scrum-Schulung schicken, so dass ich all die notwendigen Details lernen kann.

//Meine Antwort://

Konzentriere Dich auf den Business Value (Geschäftswert). Risikomanagement IST ganz sicher Geschäftswert.

Kultiviere und kommuniziere das WARUM. Immer. Selbst wenn keines da sein sollte, kommuniziere auch das. Vertraue dem Entwicklungsteam und seiner Fähigkeit, zu liefern. Der Scrum Master hilft Dir, zu verstehen.

Experimentiere damit, Einträge im Product Backlog gemeinschaftlich zu schreiben. Es geht um Empathie, //Alignment// und gemeinsames Verständnis. Delegiere das Aufschreiben von Akzeptanzkriterien etwa an Entwickler mit Tester-Profil.

Lerne den Unterschied zwischen Verifizierung und Valdierung.

Fange damit an, das Agile Manifest zu lesen. Lies den Scrum-Guide. Der ist nur eine von vielen möglichen Anwendungen des Agilen Manifests. Lies das noch einmal. Und noch einmal.

Sprich mit Stakeholdern. Sprich mit PO-Kollegen.

Trau Dich, "Nein" zu sagen. Auch wichtigen Stakeholdern. Finde heraus, ob Du //wirklich// authorisiert bist.

Überfülle Dein Produkt-Backlog nicht - zwei oder drei Iterationen gut verstandener Einträge ist gut genug. Darüber hinaus ist es unkartiertes Land mit einem nur groben Überblick.

Sei nachsichtig und freundlich. Zu Dir selbst, Deinem Team und Deinen Stakeholdern.

In der Gesetzgebung der letzten Jahre gibt es den Trend, die sogenannte //Organhaftung// auszuweiten: Für Compliance-Verstöße wird auch die Vorstandschaft einer Kapitalgesellschaft tatsächlich öfters mal //persönlich// drangenommen. Im Sozialversicherungsrecht hat das bei Konzernen zur sogenannten //Freiberuflerpanik// geführt, und im Datenschutzrecht kam die im Mai inkraftgetretene DSGVO mit ihren potentiellen Auswirkungen für viele //sehr// überraschend. Jedenfalls, als ihnen klar wurde, dass ein Verstoß tatsächlich schmerzen könnte.

Nun ist es so, dass die IT-Anbieter sich auf die Nachfrage eingestellt haben. So gibt es etwa eine deutsche Azure-Cloud, die von der Telekom als Treuhänder betrieben wird - und wo Microsoft nur indirekt und streng reglementiert zugreifen darf. Dieses Cloud-Angebot soll sicherstellen, dass deutsche Unternehmen ihren Verpflichtungen im Umgang mit Kundendaten nachkommen können -- auch wenn sie für deren Verarbeitung ein eigentlich amerikanisches Cloud-Produkt verwenden. Amerikanische Unternehmen - wie Microsoft - unterliegen nämlich anderen gesetzlichen Vorgaben. Diese sind aus einem unlängst im [https://de.wikipedia.org/wiki/CLOUDAct CLOUD-Act] kodifizierten Rechtsverständnis geboren, das für sich völlig selbstverständlich eine //globale// Datenzugriffsmöglichkeit durch die US-amerikanischen (Geheim-)Behörden beansprucht. Dass das [https://de.wikipedia.org/wiki/SafeHarbor Safe-Harbor-Abkommen] im [https://de.wikipedia.org/wiki/EU-USPrivacyShield Privacy Shield] nur unzureichend fortgeführt wurde, bleibt aus europäischer Sicht in vielen Fällen nur die Wahl zwischen Pest und Cholera: Auf US-amerikanisch betriebene Plattformen beinahe blind zu vertrauen oder ganz auf deren Einsatz zu verzichten. Treuhänder-Angebote bieten sich da als ein vernünftiger Mittelweg jenseits von diesen Extremen an.

IT-Leiter, die das Thema Cloud für ihren Anwendungsfall kritisch bewerteten, haben daher dankbar das Angebot der Telekom angenommen: Ein sinnvolles Offering mit einem deutschen Betreiber und daher ohne die potentiell problematischen Nebenwirkungen, ISO 27k- und DSGVO-konform.

Leider ist das wohl nicht so. Es leaken auch aus der von der Telekom betriebenen Azure-Cloud Telemetriedaten an außereuropäische Gegenstellen. [https://www.heise.de/ix/heft/Glauben-statt-wissen-4140402.html Ein Artikel aus der aktuellen iX schließt folgendermaßen:]

Fazit: Auch unter der Obhut des „Treuhänders“ T-System sind die Daten der Azure-Instanzen nicht nachprüfbar sicher, nicht einmal vor US-Zugriff. Warum dieser Dienst trotzdem mit etlichen Zertifizierungen aufwarten kann, wissen wohl nur die Zertifizierer selbst. Tatsächlich die Systeme untersucht hat da offenbar niemand.

CIOs tun daher gut daran, sich nicht alleine auf die Versprechen von Cloud-Anbietern zu verlassen. Spätestens durch Artikel wie dem aus der aktuellen iX sind sie auf die Thematik von -- hier vermutlich gut gemeinten -- Quasi-Hintertüren aufmerksam gemacht worden: Aus der abstrakten Möglichkeit eines solchen Abflusses ist ein bestätigter Vorfall geworden.

IT-Verantwortliche sollten daher gemeinsam mit der hauseigenen Technik und den IT-Sicherheitsmenschen (etwa internen ISMS-Auditoren nach ISO 19011) //jeden// Einsatz eines Cloud-Angebots prüfen und risikomanagen. Natürlich gehört zum möglichen Umgang mit Risiko auch Risiko-Akzeptanz. Diese muss dann aber //bewusst// und nachvollziehbar geschehen.

Denkt man an "Computerstimme", fallen einem vielleicht der Supercomputer WOPR aus dem 80er-Jahre-Streifen //Wargames// und die Sprachsynthese von Stephen Hawking ein: Gleichförmig, künstlich, robotisch.

Dass die Technologie in der Praxis deutlich weiter ist, hat Google/Deepmind 2016 mit [https://www.heise.de/newsticker/meldung/Google-DeepMind-Sprachsynthese-soll-menschlicher-klingen-3317810.html WaveNet] dargestellt. Die ziemlich beeindruckende Technologie auf Basis neuronaler Netze war in den [https://cloud.google.com/text-to-speech/docs/wavenet englischsprachigen Beispielen] kaum noch von tatsächlich gesprochenen Sätzen zu unterscheiden.

Im Frühjahr 2018 hat Google dann eine [https://www.golem.de/news/google-deepmind-cloud-text-to-speech-liest-texte-mit-fast-natuerlichem-klang-1803-133567.html Vorlese-API vorgestellt], die man als Entwickler recht einfach in seine Anwendungen einbauen kann. //Text-to-Speech// bot in der damaligen Beta virtuelle Stimmen für doch einige Sprachen an. Leider war eine WaveNet-basierte Synthese eigentlich nur für Englisch möglich, alle anderen Sprachen wurden "nur" mit den klassischen Ansätzen bereitgestellt - so auch Deutsch.

Nun, das Warten hat ein Ende: Ich bin vorgestern mal wieder auf die [https://cloud.google.com/text-to-speech/docs/voices entsprechende Doku-Seite der API] vorbeigesurft. WaveNet ist seit 21. August für Deutsch verfügbar, und das gleich in verschiedenen Stimmausprägungen! Auch andere Sprachen wie etwa Koreanisch oder Italienisch wurden berücksichtigt.

Im Vergleich zu den englischen Varianten klingen die deutschen Stimmen für mich allerdings noch merklich künstlicher. Das wird aber mit der Zeit sicher noch besser werden. Falls noch nicht geschehen, wäre ein offensichtlicher Pfad dahin der Einsatz des Tacotron-2-Systems, das Google [https://ai.googleblog.com/2017/12/tacotron-2-generating-human-like-speech.html Ende 2017 vorstellte.]

Es gibt valide ethische Bedenken für den allzu sorglosen Einsatz täuschend natürlich wirkender Sprachsynthese. Und die Technik wird sicherlich auch für Gaunereien eingesetzt werden. Als verhaltener Optimist freue ich mich trotzdem über die absehbaren Einsatzgebiete in der Computer-Mensch-Kommunikation: "Smarte" Assistenten, Reha, Ambient Assisted Living (AAL) sowie Unterricht und Lehre.

Wie die Stimmen denn nun klingen, kann man direkt auf der [https://cloud.google.com/text-to-speech/ Einstiegsseite des API-Angebots] herausfinden.

Letztes Jahr im April schrieb ich noch über den [http://klumpp.net/blog/archives/422-ISO-27001-Der-Weg-bis-zum-Auditor.html dreigeteilten ISO 27001-Zertifizierungsweg] für Personen. Damals hatte ich gerade meine ISO 27001-Foundation-Zertifizierung erhalten. Eineinhalb Jahre später habe ich nun die Zeit aufgebracht, den zweiten Schritt zu gehen: Ich bin jetzt //ISO 27001 Professional,// oder wahlweise auch //Information Security Officer nach ISO 27001// (ISO). Damit ist ein Kompetenzniveau bestätigt, auf dem man **Informationssicherheit-Managementsysteme** (Information Security Management Systems, ISMS) **planen, aufbauen, betreiben und verbessern** kann. 

Wer sich ein bisschen reinhängt und mit iterativ-inkrementellen Ansätzen vertraut ist - Stichwort: //Plan-Do-Check-Act// - wäre prinzipiell auch ohne diese Ausbildung dazu in der Lage. Natürlich. Der Trick mit der Zertifizierung besteht darin, dass man eben besonders für ein ISMS //nach ISO 27001// ausgebildet wurde. Hält man sich als Unternehmen an die besagte Normenfamilie, braucht man einerseits an vielen Stellen das Rad nicht neu zu erfinden. Andererseits sorgt man damit auch für eine Vergleichbarkeit der ISMS untereinander, immerhin sind sie quasi Arbeitsergebnisse. Nicht zuletzt freut sich das Management, dass sie nachweislich "die richtigen Leute" an das Thema gelassen haben. Wobei — vielleicht verfliegt die Freude, sobald die Kollegen hören, dass auch sie bei ISO 27001 kräftig mitziehen müssen... immerhin ist es ja ein //Management//-System!

Zwischenzeitlich hat sich der TÜV übrigens als Personen-Zertifizierungsstelle aus dem Geschäft zurückgezogen. Die [https://ico-cert.org/ ICO-CERT] übernimmt bei den meisten Schulungsanbietern nun die Zertifizierung. Es werden Euch daher in der Praxis Leute unterkommen, die unterschiedliche Aussteller für ihre beiden Zertifizierungen haben. 

Mir hat der Zertifizierungskurs in München Spaß gemacht: //Gute// Leute getroffen, und //gute// Referenten abbekommen. Der Stoff war nicht ohne Anspruch, aber wichtiger als der war mir der praxisnahe Austausch mit den Kollegen. Die Woche war sehr intensiv.

Das Thema insgesamt macht mir jedenfalls Spaß, und vielleicht setze ich ja noch meine Auditor-Ausbildung oben drauf. Das wäre der letzte und anspruchsvollste Zertifizierungsschritt. Als Auditor bewertet man die Wirksamkeit eines ISMS und dessen Maßnahmen. Für einen freiberuflichen Berater ist diese Zertifizierung daher vielleicht garnicht so verkehrt. Immerhin kann man seinen Kunden damit bei der Vorbereitung zu einem Zertifizierungsaudit helfen.

**PS: [http://klumpp.de/nick/ Ihr könnt mich natürlich schon jetzt für Eure ISO 27001-Projekte anheuern.] :-)**

Manche Sachen bleiben einfach ein wenig länger liegen. Mitte 2015 habe ich meine ersten Schritte auf Patreon getan, und es hat nach [https://arstechnica.com/information-technology/2015/10/gigabytes-of-user-data-from-hack-of-patreon-donations-site-dumped-online/ einem kleinen "Datenreichtum"] tatsächlich gute //zwei Jahre// gedauert, bis ich meinen Account dieses Jahr wieder hervorgekramt habe.

Flattr ist nämlich nach längerem Siechtum [https://www.heise.de/meldung/Adblock-Anbieter-Eyeo-uebernimmt-Online-Bezahldienst-Flattr-3675942.html im April doch irgendwie offiziell gescheitert] - [http://klumpp.net/blog/archives/148-Ein-neues-Design-fuer-klumpp.net.html für uns persönlich jedoch bereits 2012.] Versteht mich nicht falsch: (Mikro-)Payments, um Angebote im Web zu belohnen, sind grundsätzlich eine gute Idee. Bei allem Mut hat Flattr aber etwas daraus gemacht, das nie so richtig Fuß fassen konnte. Vielleicht lag's an der Technik. Vielleicht lag es daran, weil das ganze so wenig zu durchschauen war: Wieviel denn nun ein "Flattr" wert war, hat sich einfach nicht erschlossen. Vielleicht aber war auch der Markt für das eingeschlagene Prepaid-Modell einfach nicht zu begeistern.

Patreon geht hier einen geradlinigeren Weg, weg von //Miko-//Transaktionen hin zu //Mini-//Transaktionen: Anbieter können sich monatlich oder per veröffentlichtem Werk unterstützen lassen. Der Begriff "Werk" ist dabei weitgefasst: Es kann sich etwa um Musik, Video, Comic, oder eine Geschichte handeln. [https://www.reddit.com/r/HFY/wiki/series/homo_mechanicus Letzteres hat mich 2015 zu Patreon gebracht.]

Heute wie damals gefällt mir an Patreon, das es zumindest für die Unterstützer ("Patrons") //einfach// zu handhaben ist. Unterstützt man mehrere Schaffende, werden die einzelnen Beträge monatlich zusammengefasst und abgebucht. Wegen der Umsatzsteuer werden aus einem Dollar dabei in Deutschland 1,19 Dollar - aber das ist in der Rechnung gut nachzuvollziehen. Die Schaffenden wiederum zahlen auf jeden Dollar, den sie über Patreon erhalten, etwa 10% Transaktionskosten. Das liegt, zumindest in meiner Erinnerung, unter dem Anteil, den sich Flattr von den Beteiligten genommen hat.

Anbieter können über Patreon für ihre Unterstützer auch besondere Goodies bereithalten, oder mit ihnen kommunizieren. Das geht in der Regel über den Social-Media-Teil der Plattform, insbesondere mittels der tumblelog-artigen Einträgen und dem Messagingsystem - möglicherweise sogar abgestuft nach Unterstützungshöhe. Für all das interessiere ich mich allerdings nur milde: Ich unterstütze nämlich die Schaffenden, weil ich möchte, dass sie das, was ich eh schon über YouTube, ihr Blog oder sonstwo mitbekomme, schlicht weitermachen. Ich bin ein einfacher Mann..

Mal sehen, wohin sich Patreon als Plattform hinbewegt. Nach den zwei Jahren Pause habe ich dieses Mal vor, länger dabeizubleiben.

Sicherlich eines der besten Bücher zum Lernen von modernem //vanilla// JavaScript ist **[https://eloquentjavascript.net/ Eloquent JavaScript]** von Marijn Haverbeke. Das Buch kann man sich kostenlos auf der Website herunterladen oder auch klassisch im Buchhandel besorgen. 
Beinahe nebenbei ist es eine prima Einführung in das Programmieren im Allgemeinen. Damit steht es für mich in einer Reihe mit Werken wie [https://www.manning.com/books/groovy-in-action-second-edition Groovy in Action], [http://modernperlbooks.com/books/modern_perl_2016/index.html Modern Perl] und [https://poignant.guide/ Why's (Poignant) Guide to Ruby].

Die zweite Auflage ist nun schon ein paar Jahre alt, und natürlich hat sich seit damals die JavaScript-Welt deutlich weitergedreht. Marijn arbeitet daher an einer dritten Auflage, die neu entstandene //Best Practices// berücksichtigt. Wer mag, kann sich noch an den Produktionskosten beteiligen. Kommen 10.000 Euro zusammen, heuert der Autor einen Illustrator an. Es fehlen derzeit nur noch ein paar Euro, bis dieses Ziel erreicht ist.  

Ich habe also diese Woche das Vorhaben mit ein paar Euro unterstützt. Wenn Ihr es gerade auch könnt, [https://eloquentjavascript.net/3rd_edition/ tut doch ein paar Euro dazu.] Es ist sicher gut angelegt. 

//Gut, da ich in letzter Zeit öfter entsprechende Gespräche geführt habe, hier meine persönliche und, zugegeben, etwas verkürzt-polemische FAQ zur Blockchain in der Energiewirtschaft. Schauen Sie sicherheitshalber auch aufs Datum dieses Beitrags, vielleicht hat sich ja inzwischen die Welt weitergedreht.. Siehe auch.//

Q: Ich bin Stadtwerk, Gemeindewerk bzw. Regionalversorger - brauche ich Blockchain? A: Nein.

Q: Aber.. A: Nein!

Q: Warum denn nicht? A: Im Grundsatz ist Blockchain eine Technologie zur Lösung von Problemen, die wir in der //europäischen Energiewirtschaft// so nicht haben. Sie kann dort sinnvoll sein, wo unter den Teilnehmern kein Vertrauen herrscht, und es auch keine zentale vertrauenswürdige Instanz gibt. Wir in Europa haben eine strenge Regulierung, in der das Verhalten aller Marktteilnehmer eng beaufsichtigt und eine relevante Abweichung empfindlich geahndet werden kann. Per Definition können und müssen die Marktteilnehmer einander also vertrauen. Die Regulierung schreibt in wichtigen Teilbereichen außerdem vor, was zwischen Unternehmen bzw. auf dem Markt erlaubt bzw. zu tun ist oder nicht. Blockchain ist in den regulierten (Kommunikations-)Bereichen nicht zugelassen und dort ohne sinnvollen Anwendungsfall, in den unregulierten Bereichen ohne echte breithin akzeptierte Anwendung.

Q: Geht's auch ein bisschen technischer? A: Sicher. Immer, wenn Sie "Blockchain" hören, setzen Sie im Geiste mal "Replizierende Spezialdatenbank"/"Ewiges Logfile" mit schwankender, nicht-garantierter Transaktionsgeschwindigkeit und tendentiell immer schlechter werdender Energieeffizienz. Es muss 50,1%-Konsens herrschen, damit ein Neueintrag gültig wird. Wollen Sie Ihrer IT ohne Not NOCH ein System aufs Auge drücken, NOCH eine Indirektion?

Was ist denn, wenn sich ein 50,1%-Kartell bildet und Ihre Einträge ablehnt? Wenn Sie von //Smart Contracts// hören, die auf einer Blockchain ausgeführt werden, fragen sie bei den Technikern mal nach, ob der betreffende Code beweisbar ohne Seiteneffekte ist. Stellen Sie Ihrem Hausjuristen die Frage, ob und wie ein derartiger Smart Contract wirklich unmittelbar ein Vertrag sein kann. Fragen Sie sich, ob sie so etwas beispielsweise im automatisierten Energiehandel haben wollen - wo Sie sich doch in einer Umgebung ohne Vertrauen wähnen? Wenn Sie niemandem vertrauen, warum würden sie in Code gegossene geldwerte Entscheidungslogik in eine öffentliche Blockchain gießen? Sind Sie clever genug, Ihren Code wirklich Exploit-sicher zu gestalten? Und wollen Sie mit Hilfe einer Blockchain einander "einfach nur" Transaktionen bestätigen, denken Sie daran, dass eine De-Pseudonymisierung/Anonymisierung unter Umständen relativ einfach möglich ist.

Q: Aber jeder macht doch was mit Blockchain. A: Ja. Auch Sie sollten sich tatsächlich mit dem Thema beschäftigen. Setzen Sie beispielsweise ein paar pfiffige Azubis/Duale Studenten auf das Thema an. Führen Sie regelmäßig Fachgespräche und beteiligen Sie sich in einer Art "Smart Follower"-Strategie gerne an Forschungsprojekten, um ein Gefühl für die Sache zu entwickeln. Das ist außerdem gut für die Außenwirkung. Und insbesondere: Engagieren Sie sich im Umfeld der neuen Blockchain-Initiative, die gerade aus der [https://www.edna-energy.de/blog/blockchain-in-der-energiewirtschaft-neue-aufgaben-bei-edna/ EDNA heraus entsteht.] Da sind gute Leute mit Sachverstand und Bodenhaftung unterwegs. Mit denen werden Sie sicher herausfinden, ob, wie und wann Blockchain wirklich in Ihren Werkzeugkasten passt. [https://www.gartner.com/smarterwithgartner/top-trends-in-the-gartner-hype-cycle-for-emerging-technologies-2017/ Noch ist das Thema aber ziemlich weit links im Hype-Cycle.]

Gute Nachrichten für alle Unternehmen der Energiewirtschaft, deren IT-Dienstleister den 1. Juni reißen könnte. Zu diesem Datum soll nämlich marktweit auf verbesserte Verschlüsselungsverfahren im Datenaustausch umgestellt werden. IT-seitig bedeutet das unter Umständen einen deutlichen Aufwand. So manche Beauftragung dafür dürfte wohl auch etwas zu spät erfolgt sein. Es ist ja "nur wieder mal" eine Anpassung beim Kommunikationsweg..

//Rüdiger Winkler,// Geschäftsführer der EDNA, hat nun heute folgende Information weitergeleitet. Sie stammt von Herrn //Kay Tidten.// Er ist seit 2015 Fachgebietsleiter //IT-Sicherheit und Kritische Infrastrukturen// beim BDEW.

Ich zitiere aus Herrn Winklers Mail:

1. Sämtliche Zertifikate für den Einsatz in der elektronischen Marktkommunikation, die bis zum 31. Dezember 2017 ausgestellt wurden, müssen mit den gängigen Signaturalgorithmen sha-256RSA oder sha-512RSA signiert worden sein. Dies entspricht dem Signaturverfahren RSASSA-PKCS1-v1_5. Diese Zertifikate können im Rahmen ihrer maximal dreijährigen Gültigkeit im Interimsmodell der Marktkommunikation eingesetzt werden. 2. Alle Zertifikate, die ab dem 1. Januar 2018 neu ausgestellt werden, müssen mit dem Signaturverfahren RSASSA-PSS signiert werden. Das vorgenannte Datum kann in Abstimmung mit den Behörden verschoben werden, wenn bis Jahresende 2017 keine ausreichende Anzahl an vertrauenswürdigen öffentlichen Zertifizierungsstellen Zertifikate anbieten, die mit dem Verfahren RSASSA-PSS signiert sind. Der BDEW wird hierzu im September Gespräche mit den zuständigen Behörden aufnehmen und den Markt zeitnah informieren. 3. Für die S/MIME Signaturerzeugung bei AS2 und E-Mail gelten entsprechend befristet vom 01. Juni 2017 bis zum 31. Dezember 2017 die weitverbreiteten Signaturalgorithmen sha-256RSA und sha-512RSA als verpflichtende Mindestanforderung. Spätestens ab 1. Januar 2018 muss jedoch ausschließlich das neue Signaturverfahren RSASSA-PSS eingesetzt werden. Der BDEW empfiehlt daher dringend rechtzeitige Gespräche mit Softwareherstellern und Dienstleistern aufzunehmen, um eine rechtzeitige Migration zu gewährleisten. 4. Für das Verfahren der Key Encryption gilt befristet vom 01. Juni 2017 bis zum 31. Dezember 2017 das weitverbreitete Verfahren RSAES-PKCS1-v1_5 als verpflichtende Mindestanforderung. Spätestens ab 1. Januar 2018 muss jedoch ausschließlich das neue Verfahren zur Key Encryption RSAES-OAEP eingesetzt werden. Der BDEW empfiehlt daher dringend rechtzeitige Gespräche mit Softwareherstellern und Dienstleistern aufzunehmen, um eine rechtzeitige Migration zu gewährleisten.

Zitat Ende. [https://www.bundesnetzagentur.de/DE/Service-Funktionen/Beschlusskammern/Beschlusskammer7/BK773MesswesenEnergie/MitteilungenzuBK616200BK716142/MitteilungNr3/MitteilungNr3.html?nn=269626 Vermutliche Quelle.]

Nun denn, 31. Dezember 2017 also! Die Erleichterungen sind vernünftig und als Übergangsregelung keineswegs übertrieben. Gute Krypto ist nicht einfach, und als Handlungsfeld für das (IT-)Management noch allzu oft unterbeleuchtet.

Die skizzierten Anpassungen finden sich auch in der [http://www.edi-energy.de/files2/EDI@Energy-Regelungen-zum-%C3%9Cbertragungswegv1.1Lesefassung.pdf aktuellen Lesefassung der Regelungen zum Übertragungsweg] wieder.

NACHTRAG am 22. Mai: Siehe dazu auch die Fachtagung //Messwesen und Datenkommunikation in der Energiewirtschaft// am 23. Juni in Berlin. Sie wird ausgerichtet von der EDNA und EWeRK, dem Institut für Energie- und Wettbewerbsrecht in der kommunalen Wirtschaft e.V. - [http://edna-bundesverband.de/49/-/news/show/188401 Presseerklärung]

Nach Wochen der Hintergrundgesprächen ist es soweit: Die Projektgruppe //ECR// des //EDNA Bundesverband Energiemarkt & Kommunikation e.V.// hat sich diese Woche zu ihrer ersten Telefonkonferenz zusammengetan. Mit den Schwerpunktthemen //Energiehandel, Compliance und Regulatorisches Reporting// ergänzt die Arbeitsgruppe nun an einer wichtigen Stelle die Arbeit des Branchenverbands.

Ganz nebenbei hat damit auch die umsetzungsnahe, herstellerübergreifende Betrachtung der Themen EMIR und REMIT in der Energiewirtschaft einen Platz gefunden. Die EDNA vermag nun dort ein klein wenig softwarepraktische Orientierung zu geben, wo die üblichen Verdächtigen - BDEW, VKU, bne & Co. - es naturgemäß nicht konnten oder wollten. Wenn wir sowas damals[tm] bei EMIR schon gehabt hätten!

Folgende Unternehmen haben Mitarbeiter in die Arbeitsgruppe entsandt:

DACHS, 
KISTERS, 
Robotron, 
SEEBURGER, 
Seven2One,
SOPTIM.

Besonders erfreulich: Die drei wichtigsten RRM-Betreiber des deutschen Markts sind von Anfang an mit dabei.

Als einer der Treiber für das Thema ist mir die Ehrenaufgabe zuteil geworden, die Gruppe zu koordinieren; unser erstes persönliches Treffen wird schon auf der E-world stattfinden. Ich freu mich.

Paul und ich waren schon immer dem verbunden, was man heute "Spieleindustrie" nennt - noch bevor es annähernd die Ausmaße hatte, die das Wort //Industrie// überhaupt erst rechtfertigen. Wir haben früh Computerspiele gespielt, natürlich, aber auch Spiele gebaut - als Entwickler, Autoren, Gametester. Das war alles schon im letzten Jahrtausend. Gemeinsam mit guten Leuten haben wir in unseren jüngeren Jahren so einiges auf die Beine gestellt. Vieles davon bleibt der Geschichtsschreibung verborgen - vielleicht ist das bei dem einen oder anderen Werk auch ganz gut so. ;-) Zwischenzeitlich hat sich die Branche unglaublich professionalisiert. Weltweit. Die Teams wurden größer, die Spiele aufwendiger und die Budgets erreichen zum Teil schwindelerregende Höhen. Dennoch, dank mächtiger Werkzeuge und Ökosysteme gibt es heute mehr Chancen als jemals zuvor. Man muss sich nicht mehr um die x-te Neuerfindung des Rads kümmern. So haben Einzelkämpfer und Indie-Teams mehr Möglichkeiten denn je, etwas auf die Beine zu stellen und es anschließend auch unter die Leute zu bringen. Zu den interessantesten Vertretern unter diesen Werkzeugen dafür gehört das freie [http://haxeflixel.com HaxeFlixel.] Im Kern ist //Haxe// eine mit //JavaScript// bzw. //ActionScript// verwandte Programmiersprache, während //Flixel// das eigentliche Framework zur 2D-Spieleentwicklung ist. Zusammen sind sie also sowas wie ein modernes //TCL::TK// für die Spieleentwicklung. Wie fast jedes quelloffene und unentgeltliche Projekt leidet auch HaxeFlixel ein klein wenig darunter, dass ja ein wenig //schneller// gehen könnte. Immerhin gibt es da tagsüber noch den anderen Job der Entwickler, nämlich den, mit dem sie //eigentlich// ihre Brötchen verdienen. HaxeFlixel hat inmitten dieser Situation jedoch das Glück des Kaufkraftunterschieds: Alexander Hohlov, der Hauptentwickler für das Mashup HaxeFlixel, lebt in der Russischen Föderation. Deswegen hat Lars A. Doucet, der Entwickler einer meiner liebsten [http://www.defendersquest.com Zeitsenken], eine erfolgreiche [https://www.indiegogo.com/projects/haxeflixel-games-software Indiegogo-Kampagne] aufgesetzt. So kam auf diese Weise mindestens ein Jahr Vollzeitgehalt für Alexander zustande. Nicht schlecht, oder? Ich habe die Kampagne auch unterstützt. HaxeFlixel ist super, und es ist wichtig, dass es derartige Werkzeuge weiterhin gibt. Und weil's mir ja Spaß macht, möchte ich zukünftig auch wieder ein wenig mehr mit Spielen tun haben.

//[https://www.indiegogo.com/projects/haxeflixel-games-software/ Die Kampagne geht übrigens als InDemand weiter - Ihr könnt Euch also noch beteiligen.]//

Yours truly ist seit kurzem TÜV-geprüft. Als Folge dessen habe ich jetzt auch eine Plakette. Genauer: Ein Zertifikat nach ISO/IEC 27001:2013 Foundation. Nicht ganz unpraktisch in der Energiewirtschaft.

ISO 27001 hört man immer wieder, wenn es um die Sicherheit von Rechenzentren geht. Tatsächlich aber können sich sowohl beliebige Organisationen als auch Personen mit ISO 27001 beschäftigen bzw. zertifizieren lassen.

Die ISO-27000-Normenreihe beschäftigt sich mit dem sicheren Aufbau und Betrieb von Information Security Management Systems (ISMS), also um nachhaltige Datenschutz und Datensicherheit.

ISO/IEC 27000 – Information security management systems – Overview and vocabular ISO/IEC 27001 – Information security management systems – Requirements ISO/IEC 27002 – Code of practice for information security management ISO/IEC 27003 – Information security management systems – Implementation Guidelines ISO/IEC 27004 – Information security management measurements ISO/IEC 27005 – Information security risk management

Als Norm steht ISO 27001 also nicht alleine.

Da sich die Welt insbesondere in der IT immer schneller dreht, können die in der Norm dargestellten Requirements und Guidelines nicht vollständig oder erschöpfend sein. Das wollen sie auch nicht. Im Prinzip werden Strukturen und Vorgehensmodelle skizziert, von denen Organisationen die für sie passenden herausgreifen können. Ein iterativer-inkrementeller Ansatz ist hierbei ausdrücklich vorgesehen (Plan-Do-Check-Act, Demingkreis/Shewhart-Zyklus).

Was Personen angeht, dient die Zertifizierung zur Bestätigung einer gewissen Handlungskompetenz. Da es für unterschiedliche Bedürfnisse unterschiedliche Anforderungen gibt, ist der Zertifizierungspfad entsprechend aufgegliedert. Die folgenden drei zertifizierbaren Wissens- und Fertigkeitskompetenten bauen aufeinander auf:

ISO 27001 Foundation - bestätigt als Grundlagenausbildung, dass die notwendige Sensibilität und fachlichen Grundlagen für den Umgang mit einem ISMS vorhanden sind. Zielgruppe sind etwa Sicherheitsbeauftragte oder Unternehmensberater (Ha!).
ISO 27001 Information Security Officer (ISO) - diese Zertifizierung weist ein praxis- und umsetzungsorientiertes Wissen für betriebsverantwortliche Mitarbeiter nach. Es geht schwerpunktmäßig also um Planung, Betrieb und Verbesserung eines ISMS in einer Organisation.
ISO 27001 Auditor - Derart zertifizierte Personen können den Aufbau und die Ablauforganisation eines ISMS nach ISO 19011 auditieren bzw. qualifiziert bewerten.

Es gibt eine Reihe von Anbietern auf dem Markt, die die entsprechenden Schulungen anbieten. Die anschließende Personenzertifizierung übernimmt ein unabhängiges Unternehmen, also etwa die entsprechende TÜV-Stelle. Diese stellt durch ihre Vorgaben auch sicher, dass alle Schulungshäuser den selben Stoffkreis vermitteln.

Über alle Anbieter hinweg haben sich folgende Schulungsdauern eingespielt:

ISO 27001 Foundation: 2 Tage. ISO 27001 Information Security Officer: 5 Tage ISO 27001 Auditor: 3 Tage Insgesamt: 10 Tage

Wer vertieften Spaß dran hat, kann sich übrigens die ISO 27001 als Text im Shop der Standardorganisation runterladen: [http://www.iso.org/iso/iso27001 Für schmale 118 Schweizer Franken..]

Nun habe ich also die Foundation-Zertifizierung. Gebe ich mir den Inf//ormation Security Officer//? Ich denke schon, sofern die Zeit passt. Ich beschäftige mich ja auch ohne eine ISO-Zertifizierung mit Sicherheitsfragen (Stichwort: Smart Grid / Smart Metering). Es ist zudem immer gut, sich sicher in einem vielfach bewehrten Rahmenwerk bewegen zu können, und so dessen Blickwinkel und Denkweise in eine Organisation zu tragen. In der Energiewirtschaft ist Sicherheitsorganisation schon von jeher wichtig, und es wird noch wichtiger. Insbesondere Netzbetreiber und Smart Meter Gateway Administrators müssen sich verschärft mit dem sicheren Rechenzentrumsbetrieb beschäftigen.

Übrigens - weil ich als frischgebackener Freiberufler grundsätzlich käuflich bin, kann man mich auch für [http://klumpp.de/nick/ ISMS/ISO 27001-Beratung] buchen. :-)

//Seit meiner Ausbildung beim [https://de.wikipedia.org/wiki/Badenwerk Badenwerk] bin ich der Energiebranche eng verbunden. Später habe ich studiert und konnte so den dazugehörigen theoretischen Unterbau pflegen:// Netzwerkeffekte, Natürliche Monopole, Monopolverträge, Gebietsmonopole, Essential Facilities Doctrine, Liberalisierung, Verbändevereinbarungen // - all das ist nicht nur historisch interessant. Wenn man mit ihnen nicht alltäglich zu tun hat, verblassen die ganzen Begriffe dann doch recht schnell. Insofern ist es dann immer sehr nett, wenn man "da draußen" im Internet auf Beiträge stößt, die diese Konzepte aufnehmen und womöglich auch neu beleuchten.

Auf Reddit hat es ein Kommentar nach //[https://www.reddit.com/r/bestof/comments/3t1m9h/formerutilityeconomistexplainswhy_telecom/ /r/bestof]// geschafft, den ich hier teilen möchte. Anhand des in der Community wenig geliebten Unternehmens //Comcast// diskutiert er die Telekommunikationsregulierung in den USA, und zieht dabei Parallelen zur Energiewirtschaft - beides sogenannte Netzsektoren. Der Text zeigt ein angelsächsisch geprägtes Theorie-Verständnis und bezieht sich besonders auf Kalifornien. [http://klumpp.net/blog/archives/223-Der-kalifornische-Sommer-2000-Auswirkungen-zu-kurz-gegriffener-Regulierungsansaetze.html Dessen Energiemarkt nimmt man in Europa gerne für vergleichende Studien heran.] Das liegt auch daran, dass Kalifornien für sich alleine gesehen locker unter den Top 10 der leistungsfähigsten Industrienationen wäre.

Danke an /u/twenafeesh für die freundliche Erlaubnis, [https://np.reddit.com/r/technology/comments/3sonfk/iscomcastmarkingupitsinternetservice_by/cwz7xs2 seinen Beitrag] übersetzt wiederzugeben.//

Is Comcast marking up its internet service by nearly 2000%?!, "ISPs claim our data usage is going up and they must react. In reality, their costs are falling and this is a dodge, an effort to get us to pay more for services that were overpriced from day one.”

/u/Ultima_RatioRegum Daher das Problem mit dem Shareholder-Value-Ansatz als dem einzig akzeptierten Weg, ein Unternehmen zu führen.

/u/twenafeesh Und das ist der Grund, warum Comcast wie jeder andere Versorger reguliert werden sollte. Das Potential für ein [https://de.wikipedia.org/wiki/Politische_Rente Rent-Seeking-Verhalten] ist in dieser Art von monopolistisch gepräger Umgebung einfach zu hoch.

Edit: Ich kopiere dies von einem anderen meiner Kommentare zu einem ähnlichen Thema, um zu erklären, warum das Comcast einen unfairen Vorteil gibt.

Der Markt ist so aufgebaut, um ihnen (den Telekommunikationsunternehmen) einen unfairen Vorteil zu geben.

Lass mich das klar ausdrücken. Es gibt definitiv ökonomische Vorteile, wenn man einem Unternehmen mit unglaublich hohen Infrastrukturkosten ein Monopol über ein Dienstgebiet erlaubt. In der Ökonomie nennt man das die Theorie vom natürlichen Monopol. Dies verhindert eine Dopplung der Anstrengungen, nutzt die Ressourcen effizienter und verhindert Probleme wie <a href="https://i.kinja-img.com/gawker-media/image/upload/s--2_HclPN8--/c_fill,fl_progressive,g_north,h_358,q_80,w_636/lgpoxpq2odq4bdbqaf3x.jpg">dieses</a> und <a href="http://www.uh.edu/engines/nycandwires.jpg">dieses</a> (New York, frühes 20. Jahrhundert), bei denen unzählige Firmen sich überschneidende, mehrfach ausgeführte Infrastruktur besitzen.

Aufgrund der Marktmacht, die dadurch solchen Unternehmen verliehen wird, müssen sie auch strikt reguliert werden. Damit verhindert man, dass sie ihre Kunden übervorteilen. Die Alternative ist, Regierungen diese Funktion selbst übernehmen zu lassen.

Die Sache ist, dass alle Wasser-, Gas- und Stromversorger strikt von Landes- und Bundesbehörden reguliert werden - nicht unbedingt so wie die Telekommunikationsanbieter. Die drei sogenannten "öffentlichen" Versorger werden als lebensnotwendig gesehen, während erst vor kurzem begonnen wurde, Telekommunikation so einzuordnen. Im Ergebnis können öffentliche Versorger keine übermäßige Gebühren für ihren Dienst berechnen, während wir ihnen im Gegenzug nahezu ein Monopol über ihr Dienstgebiet geben.

Zum Beispiel erlauben die regulatorischen Vorgaben in Kalifornien den Gas- und Stromversorgern dort das Geldverdienen lediglich auf Kapitelinvestitionen. Das gibt Versorgern einen direkten Anreiz, in neue Infrastruktur zu investieren - weil das eben die Art ist, wie sie Geld verdienen. Zugleich entfernt das jedweden Anreiz, für die Kilowattstunde zuviel zu berechnen oder Kunden zum Mehrverbrauch anzuregen - auch wenn sie das täten, kalifornische Versorger würden davon kein zusätzliches Geld verdienen.

Stattdessen gestattet die //California Public Utilities Commission (CPUC)// eine gewisse Rendite - üblicherweise ein Aufschlag von 5-10% auf den Basis-Strompreis. Diese Verzinsung bezieht sich auf Kapitalinvestitionen und wie gut der Versorger sein Geschäft betreibt. (Ein wenig ist das jetzt zu sehr vereinfacht dargestellt. Man nennt es "Decoupling", wenn Du nach weiteren Details sehen möchtest.)

Wenn wir einen solchen Ansatz für Telekommunikationsunternehmen hätten, könntest Du wetten, dass deren Preise niedriger und Bandbreite höher wäre.

Darüber hinaus schränken die meisten Bundesstaaten die Rechte einer Stadt nicht ein, selbst einen Versorger für Wasser, Gas oder Strom einzurichten. Warum machen wir das also für Telekommunikation?

Unterdessen werden in den meisten Bundesstaaten Telekommunikationsunternehmen den selben bevorzugten Zugang zu einem Dienstgebiet gegeben - ohne dass sie aber den selben Preiskontrollen unterliegen. Die Unternehmen nutzen diesen Vorteil aus, in dem sie unverschämte Preise verlangen, gleichzeitig im Infrastrukturaufbau und der Versorgung mit höherer Bandbreite hinterherhinken und Datenobergrenzen einrichten, die, wie Comcast selbst zugibt, einzig dazu da sind, den Profit abzusichern (siehe [https://www.techdirt.com/articles/20151001/05131832403/as-comcast-broadband-usage-caps-expand-company-still-refuses-to-admit-they-even-have-caps.shtml hier], [https://www.techdirt.com/articles/20130118/17425221736/cable-industry-finally-admits-that-data-caps-have-nothing-to-do-with-congestion.shtml hier] und [https://www.techdirt.com/articles/20150814/12144431948/comcast-admits-broadband-usage-caps-are-cash-grab-not-engineering-necessity.shtml hier] für Details).

Wenn wir einem Unternehmen eine monopolistische Kontrolle über ein Dienstgebiet überlassen, können wir ihnen nicht zugleich einen Blankoscheck für ihre Preisstruktur ausstellen. Die grundlegende Ökonomie sagt, dass sie dieses Privileg ausnutzen werden - und genau das haben sie getan.

Dies ist eines von vielen Beispielen, das wir Ökonomen //Marktversagen// nennen. Teil des Problems ist, wie die Regulierungsbehörden Telekommunikation sehen. Sie muss als Grundbedarf gesehen werden, und in der selben Art und Weise reguliert werden wie ein Versorger. Aktuelle Änderungen bei der FCC deuten in die richtige Richtung, aber da muss sich noch einiges tun.

Quellen: Ich habe einen <a href="http://i.imgur.com/vdJAsWQ.jpg?1">M.S. in Landwirtschafts- und Rohstoff-Ökonomie</a> und habe für Pacific Gas & Electric gearbeitet.

TL;DR: Zugang zu Telekommunikation ist ein Grundbedarf, wie auch Strom, Wasser, und Gas, und sollte auch als solcher reguliert werden. Wenn man einem Unternehmen erlaubt, unbeschränkte Kontrolle über ein Dienstgebiet auszuüben, ohne zugleich dessen Geschäftsgebaren und Kostenstruktur zu regulieren, werden die Kunden (sprich: jeder) verlieren.

//Anmerkung Nick: Dazu ergänzend auch [http://klumpp.net/blog/archives/278-Bis-zur-ersten-Richtlinie-fuer-den-europaeischen-Elektrizitaetsbinnenmarkt.html diese Artikelreihe] hier im Blog.//

//Es ist vollbracht// - die RRM-Zulassung ist da!

Frei nach dem Titel eines erfolgreichen deutsches Boulevard-Blatts:

Wir sind RRM!

Pünktlich zum Start der ersten Reporting-Phase haben wir bei [http://www.seeburger.de/ SEEBURGER] die Zulassung als RRM erhalten. Am Freitag hatten wir noch bis zum Feierabend bei der [https://de.wikipedia.org/wiki/Agenturf%C3%BCrdieZusammenarbeitder_Energieregulierungsbeh%C3%B6rden ACER] gehofft, dass deren Testsystem uns das FERTIG! überreichen würde. Nun war es also heute morgen soweit.

Die Registered Reporting Mechanisms (RRMs) sind - vereinfacht ausgedrückt - die Postboten unter REMIT. Sie tragen gemeinsam mit Marktteilnehmern und Marktplätzen die Verantwortung für das Meldewesen.

Wenn ich so auf die Liste sehe: Mir scheint, wir sind damit jetzt Europas größtes unabhängiges RRM. Nicht schlecht!

Die Zusammenarbeit mit der ACER verläuft übrigens entgegen aller Behördenklischees recht prima. Alles engagierte und freundliche Kollegen dort. Kann gerne so weitergehen.

Auch interessant: [http://klumpp.net/blog/index.php?serendipity[action]=search&serendipity[searchTerm]=EMIR Einträge zu EMIR]

Wer diese Tage zufällig einen Blick auf unser [https://gitlab.netdome.biz/explore/projects GitLab] geworfen hat, dem wird ein neues Projekt aufgefallen sein:

LoveTron!

Das ist das Ergebnis eines spontanen Abends voller Kinder-Riegel, fehlender Vorkenntnis und entspannten Programmierens. Vielleicht findet ja der eine oder andere von Euch den (etwas kruden) Code als Fallstudie zum Einstieg interessant.

Denn [http://love2d.org LÖVE] - jawohl, mit Metal-Umlaut! - ist ein Framework für [http://lua.org Lua]. Gemeinsam mit dieser pragmatischen Programmiersprache wird so die Spieleentwicklung denkbar einfach. Die Bibliothek nimmt nämlich viel von dem ab, was man sonst zu Fuß machen müsste. Und damit wird auch einiges möglich, was zu anderen Zeiten kaum praktikabel gewesen wäre.

Tja, die [http://www.mobygames.com/developer/paul-klumpp/credits/developerId,62192/ anderen] [http://www.mobygames.com/developer/nick-klumpp/credits/developerId,62191/ Zeiten].. tatsächlich müsste LoveTron als Fingerübung unser erstes Spiel in diesem Jahrzehnt gewesen sein. Oder gar in //diesem Jahrtausend//? Wer weiß - wir werden ja alt!

Kaum sind wir bei Folge sechs, werden wir auch schon ganz schön //meta//. Wir überlegen uns, warum es denn eigentlich "Podcast" heißt. Am Ende hätte uns ein einfacher Blick auf die Shownotes geholfen. Prinzipbedingt hatten wir die allerdings erst //nach// der Aufnahme. Tja. (1' 29'')

//Shownotes//: Wikipedia zu [https://de.wikipedia.org/wiki/Podcasting Podcasting] - [https://de.wikipedia.org/wiki/RSS RSS] - [https://de.wikipedia.org/wiki/ResourceDescriptionFramework RDF]

Die drei Väter des Podcastings: * [https://de.wikipedia.org/wiki/TristanLouis Tristan Louis] * [https://de.wikipedia.org/wiki/DaveWiner Dave Winer] * [https://de.wikipedia.org/wiki/Adam_Curry Adam Curry] (der genannte "DJ")

http://klumpp.net/blog/uploads/podcast/2014-11-22006Warum_Podcast.mp3

Hire character. Train skill. (Persönlichkeit einstellen. Qualifikation vermitteln.)

//- Peter Werner Schutz (geb. 1930), Vorstandsvorsitzender von Porsche 1981 - 1987.//

Unter Schutz' Ägide kletterte der Porsche-Jahresumsatz von ursprünglich 850 Mio. DM auf satte 3,7 Mrd. DM. Gleich zu Beginn seiner Amtszeit rettete er das 911er-Modell vor der Einstellung und gab den Ingenieuren im Konzern ihr //Mojo// zurück.

Verwandt zum genannten Leitsatz: Die jüngere [https://en.wikipedia.org/wiki/TheNoAsshole_Rule Keine-Arschlöcher-Regel] des Organisationspsychologen //Robert I. Sutton.//

//Es geht die Legende, dass //auch ich// mal jung war.// Ja, sowas! Wenn das stimmt, war das wohl irgendwann gegen Ende des letzten Jahrtausends. Zu der Zeit hatte ich auch meinen ersten //richtigen// Job in der Softwareentwicklung. Was ich dabei lernen konnte, prägt mich bis heute.

Mein Mentor etwa brachte mir die //[http://threevirtues.com/ drei Tugenden]// eines guten Entwicklers nahe:

• //Faulheit//
• //Ungeduld//
• //Stolz//

Insbesondere an der //Faulheit// lag ihm viel. Faulheit als gute Eigenschaft..

Faulheit ist die Tugend, langfristig möglichst wenig Energie aufzuwenden. Das bedeutet, Dinge nicht öfter oder aufwendiger zu tun als unbedingt notwendig - deswegen möglichst ordentlichen Code und ordentliche Dokumentation abzuliefern. Ein fauler Entwickler mag nicht ständig erklären, //was// sein Code //warum// //wie// tut - weder anderen noch irgendwann seinem zukünftigen Ich. Weil er faul ist, schreibt er zugänglichen, wartbaren, sinnvollen Code, der tut, was er tun soll. Ungeduld ist die Tugend, Software abzuliefern, die keinen Anlass zur Ungeduld gibt - d.h. Lösungen, die in sich möglichst schlüssig sind und den Benutzer dabei unterstützen, schnurstracks das zu tun, was er eigentlich tun möchte. Stolz ist die Tugend, seine Beiträge so zu gestalten, dass andere beim besten Willen nichts Schlechtes über sie zu sagen haben.

Wie viele andere //Bonmots// der Softwareentwicklung entstammt auch dieser Dreiklang von [http://wiki.c2.com/?LazinessImpatienceHubris Laziness, Impatience und Hubris] aus dem Umfeld von [https://de.wikipedia.org/wiki/Larry_Wall Larry Wall.] Larry ist Linguist - und Schöpfer der //Perl-//Programmiersprachen. Seine Arbeit und die seiner Mitstreiter beeinflusst einen Großteil der modernen pragmatischen Programmiersprachen. Selbst, wenn man Perl nicht mag, die Vorträge, Artikel und Insights von Larry sind immer unterhaltsam und lehrreich.

Wer SWIFT oder SEPA sagt, der muss auch BIC sagen. Vielen ist der BIC von der SEPA-Umstellung ein Begriff, schließlich ersetzt er die liebgewonnene Bankleitzahl. Aus der Ecke kommmt auch der ursprüngliche Name: Bank Identifier Code.

Während uns SEPA (//Single Euro Payments Area//) allerdings erst seit 2014 so richtig beglückt, ist SWIFT - und damit der BIC - schon deutlich älter. SWIFT wurde nämlich bereits 1973 gegründet, um den Zahlungsverkehr zwischen Banken zu erleichtern. Der Name ist hierbei Programm: //Society for Worldwide Interbank Financial Telecommunication.// Das von der Genossenschaft mit Sitz in Belgien betriebene System gleichen Namens ist quasi ein Nachrichtendienst, der über ein gesondertes Netzwerk betrieben wird. Weltweit sind mehrere tausend Unternehmen der Finanzbranche angebunden. Zugestellt werden Nachrichten innerhalb dieses Netzes mit Hilfe des BICs. Und da mit der Zeit die Teilnehmer nicht nur Banken waren, wurde um 2010 aus dem //Bank Identifier Code// schließlich ein //Business Identifier Code.// SWIFT als Organisation verwaltet die BICs selbst und an zentraler Stelle. BICs stehen grundsätzlich auch Nicht-Banken offen. In einem solchen Fall heißt die BIC dann //Business Entity Identifier// (BEI), aber wahrscheinlich nennt sie kaum einer so.

Eine BIC bietet sich also in der Theorie - genau wie die LEI - zur eineindeutigen Identifikation von regulatorisch Meldepflichtigen an, zumal EMIR ja vor allem die Finanzbranche betreffen soll. Der Code ist acht oder elf Stellen lang. Eingeleitet wird er mit der vierstelligen Unternehmensidentifikation.

Der Aufbau nach ISO 9362 ist wie folgt:

BIC := <Ländercode>[]

Die ID ist vierstellig und frei wählbar, also etwa GENO für den Genossenschaftsverband.
Der Ländercode ist zweistellig, also etwa DE für Deutschland und AT für Österreich. Der Ort ist zweistellig (z.B. FF für Frankfurt/Main oder SS für Stuttgart). Der Zusatz ist dreistellig und optional. Er wird dann verwendet, wenn etwa mehrere Filialen an einem Ort zu unterscheiden sind.

Wenn ein achtstelliger Code auf elf Stellen gebracht werden soll, wird der Zusatz auf "XXX" gesetzt.

Zur genaueren Prüfung empfiehlt sich wie immer ein Vergleich mit einer Liste bekannter Codes.

Beispiele: MARKDEFF - Deutsche Bundesbank, Frankfurt/Main. RHAGDEDD - Rheinmetall AG, Düsseldorf.

Die Swift stellt ein etwas eingeschränktes Werkzeug zur Abfrage von BICs zur Verfügung: https://www2.swift.com/bsl/

Es ist damit zu rechnen, das für Reportinganforderungen die LEI sich gegenüber der BIC durchsetzen wird, zumindest unter EMIR. Ein(e) LEI ist nämlich schon für wenige hundert Euro zu erhalten, netzwerkunabhängig, branchenübergreifend und dezentral aufgestellt. Wer also BIC sagt, muss neben SWIFT und SEPA keineswegs noch EMIR sagen.