Business Analytics mit SAS

Business Analytics mit SAS

Posts 1-10 of 13
  • Wolfgang Seidler
    Wolfgang Seidler    Premium Member
    The company name is only visible to registered members.
    16 Jan 2012, 11:07 am
    SAS in agilen Entwicklungumgebungen
    Agile Entwicklung ist in aller Munde. So standen auch wir vor der Herausforderung, SAS für diesen Ansatz zu nutzen. Schnell sind wir auf Grenzen gestossen, die uns tägliche Builds unmöglich gemacht haben. Insbesondere die mangelnde Automatisierung des Deployments stellt dabei einen Showstopper dar.

    Wir haben inzwischen dazu eine Lösung geschaffen und sind nun in der Lage die CRMS Lösung mit einem grossen ETL Teil (1.200 Meta Daten Jobs) innerhalb von 3h vollautomatisch zu deployen.

    Hat noch jemand Lösungen in dieser Richtung gefunden?

    Ich freue mich auf reghaften Austausch!
  • Post visible to registered members
  • Wolfgang Seidler
    Wolfgang Seidler    Premium Member
    The company name is only visible to registered members.
    Klingt interessant; da habe ich gleich eine Reihe von weiteren Fragen :-)

    Welche Tools (DB, Framework, Marktlösungen wie SAP, SAS, OFSA ...) wurden in diesen agilen Lösungen verwendet - oder waren dies eigengestrickte Lösungen? Wurde SAS in diesen Lösungen verwendet und wenn ja, in welcher Version?

    Gibt's es Ihr Paper "The Impact of Agility Requirements on Business Intelligence Architectures" irgendwo zum Download - sprich: darf ich Ihr Paper lesen? Was ist ein "frameworkbasiertes ETL-Konzept" - wie kann ich mir so etwas konkret vorstellen?

    Aus meiner Sicht verdienen BI Lösungen, die nicht rasch den Bedürfnissen des Business nachkommen können den Namen "Intelligence" nicht. Ich selbst kenne noch kein Unternehmen, deren IT-Abteilungen gleichzeitige Änderungen aus verschiedenen Business Bereichen "rasch" umsetzen können (z.B. Controlling, Risiko und Accounting sind über ein zentrales DWH verbunden; eine Änderung aus dem Controlling muss ins Risiko Eingang finden, die resultierende Änderung im Risiko muss im Accounting seinen Niederschlag finden). Für jedes grosse Unternehmen ist die Umstellung auf eine agile BI Landschaft ein langwieriger Prozess (alle BI Anwendungen müssen agil gemacht werden!). Aus meiner Sicht verdient die BI Diskussion einen eigenen thread (hier sind wir in einem SAS Forum - könnten also die agile Tauglichkeit der SAS BI Plattform untersuchen/diskutieren ...).
  • Post visible to registered members
  • Wolfgang Seidler
    Wolfgang Seidler    Premium Member
    The company name is only visible to registered members.
    Vielen Dank - Google findet das paper leider nicht.
  • Post visible to registered members
  • Post visible to registered members
  • Wolfgang Seidler
    Wolfgang Seidler    Premium Member
    The company name is only visible to registered members.
    Super, vielen Dank! Werd' ich mir gleich mal zu Gemüte führen.
  • Lothar Nottekämper
    Lothar Nottekämper    Premium Member
    The company name is only visible to registered members.
    Wir sind seit einiger Zeit mit dem Aufbau von agilen Plattform mit SAS bei Finanzdienstleistern unterwegs und erleben eine sehr kontroverse Diskussion zwischen den Fach- und IT-Abteilungen. Wir können im Betrieb ein automatisiertes Change-Managementverfahren sicherstellen. Dabei gehen wir von einer Trennung des Betriebs der SAS BI Plattform und den Sandboxen der Fachabteilungen aus und sind in der Lage Einsätze innerhalb eines Tages abzuwickeln.

    Ich glaube, dass es keine wirklich technischen Restriktionen gibt, ein schnelles Einsatzverfahren zu etablieren. Zumal SAS Funktionen bietet, auch Änderungen an ETL-Prozessen revisionssicher zu machen. Die Aktzeptanz agiler Methoden hängt häufig vom Selbstverständis der betreibenden Abteilungen ab.

    Die Diskussion ist in vollem Gang und ich sehe meine Rolle als Berater darin, die Rollen, Verfahren und Methoden bereitzustellen, die für die Sicherheit des Betriebs und die Flexibiltät des Fachbereichs sorgen.

    Grüße
    Lothar Nottekämper
  • Andreas Mangold
    Andreas Mangold    Premium Member
    The company name is only visible to registered members.
    Agile Entwicklung heißt ja, schnell von neuen oder geänderten Anforderungen zur lauffähigen IT-Anwendung im Geschäftsprozess zu kommen. Dazu sind, wie ja in dieser Diskussion schon erwähnt, entsprechende Werkzeuge, aber auch entsprechende organisatorische Strukturen und Prozesse notwendig. Auf der technischen Seite heißt „agile“ natürlich unter anderem, dass man ETL-Prozesse schnell in Produktion einsetzen können muss, aber was nutzt das schnelle Deployment, wenn die Programme nicht gut getestet sind oder nicht die Daten erstellen, die der Anwender braucht?

    Um speziell auf das Deployment einzugehen: Hier stellt SAS uns BI- und DWH-Spezialisten gute Werkzeuge zur Verfügung: Die Verfahren zur Hochstufung von Metadaten aus einer Umgebung in die nächste und das Generieren der lauffähigen Sourcen (letzteres ab Version 4.3 von DI-Studio) sind batchfähig und konfigurierbar. Damit das reibungslos funktioniert, müssen die DI-Prozesse natürlich sauber entwickelt sein und dürfen keine hart codierten Verweise (Pfade, Credentials etc.) auf Ressourcen einer Umgebung enthalten. User Written Codes sollten in die Metadaten eingebettet sein.

    Weitere Techniken, die zu einer agilen Vorgehensweise gehören, sind Versionsverwaltung, automatisches Dokumentieren und Testen sowie das Überwachen von Buildprozessen. Wir haben hier eine Reihe von selbstentwickelten (SASUnit) und auch Non-SAS-Werkzeugen (Subversion, Doxygen, Jenkins) im Einsatz. Dies führt jedoch eher weg vom DWH und mehr in den Bereich der Datenanalyse und der BI im engeren Sinne.

    Wer sich für agiles Projektmanagement für Data-Warehouse-Projekte interessiert, dem empfehle ich die Aufsätze und Seminare von Larissa Moss (http://www.methodfocus.com). Beachtenswert finde ich insbesondere ihren eindringlichen Hinweis, dass es im DWH mehr auf die Daten ankomme als auf die Programme und dass man deswegen Methoden wie Scrum nicht direkt übertragen kann („It’s the data, stupid!“). Auch finde ich ihren Ansatz richtig, dass ein DWH kein Projekt ist, sondern eine organisatorisch-technische Plattform, die ständige Änderungen von vornherein unterstützen muss.
 
Sign up for free: