Technische Architektur

Die technische Architektur bezieht sich auf das Design der Anwendung selbst. Einer der Hauptvorteile bei der Arbeit mit der Pega-Plattform ist, dass Sie bei der Anwendungsentwicklung Schlüsselkomponenten über mehrere Microjourneys, Channels und Anwendungen hinweg wiederverwenden können. Dank dieser Flexibilität müssen Sie eventuell nötige Änderungen später nur einmal vornehmen. Machen Sie sich dazu die Funktionen der Pega-Plattform im technischen Design Ihrer Anwendung zunutze.

Der technische Entwurf beginnt in der Prepare-Phase und wird in der Build-Phase verfeinert. Der Lead System Architect (LSA) steuert den technischen Designprozess und sorgt dafür, dass die von Ihnen erstellte Anwendung die Standardfunktionen optimal nutzt und die Wiederverwendbarkeit gegeben ist. Der LSA konzentriert sich auf die Erstellung eines allgemeinen technischen Designs und die Implementierung der Basiskomponenten für die Lösung.   

Zu den Basiskomponenten zählen die anfängliche Definition der Case-Typen, Personas und Datenobjekte für jede Microjourney, die innerhalb der Version priorisiert wird.

Der LSA arbeitet mit dem Product Owner, dem Business Architect, dem UX-Designer und den technischen Architekten des Kunden zusammen, um sich auf ein allgemeines Design zu einigen, das die (aktuellen und zukünftigen) Geschäftsziele erfüllt und mit der bestehenden technischen Infrastruktur des Kunden in Einklang steht. 

Im Rahmen des Anwendungsdesigns sorgt der LSA für Best Practices in folgenden Bereichen:      

• Anwendungsstruktur 
• Datenmodell
• Case-Design
• Benutzerzugriff und Sicherheit 
• Integration
• Implementierung und DevOps
• Berichterstattung
• User Experience/Benutzeroberfläche

Der LSA ist auch für die technische Qualität der Anwendung verantwortlich. Mit Pega Express^™ hat es sich bewährt, die Komponenten- und Szenariotests zu automatisieren, um die Qualität des Builds sicherzustellen, und DevOps-Pipelines einzurichten, um die Integration von Änderungen in Ihre Anwendung zu optimieren. Der LSA ist dafür verantwortlich, dass die Anwendungsstruktur automatisierte Tests unterstützt. Weitere Informationen zum Testen finden Sie im Thema Wichtige Testansätze der Pega Academy.   

Bevor die Anwendung erstellt wird (in unserer Mission „Senior System Architect“ erhalten Sie weitere Informationen dazu), erarbeitet sich der LSA gemeinsam mit dem Product Owner und den Business Architects ein Verständnis der Reichweite der Anwendung innerhalb der Organisation. Auf der Grundlage dieser Informationen stellt der LSA sicher, dass die Anwendung so konzipiert ist, dass sie sowohl unmittelbare als auch längerfristige Geschäftsziele unterstützt.

Hinweise des Businessteams sind unerlässlich, denn die Pega-Plattform ermöglicht es Ihnen, Ihre Anwendung anhand derselben Dimensionen wie das geschäftliche Umfeld zu organisieren. Sie können gemeinsame Richtlinien und Verfahren wiederverwenden und gleichzeitig die Unterschiede zwischen Produkten, Regionen, Channels und Kundensegmenten berücksichtigen.

Diese Flexibilität wird durch das Übereinanderschichten von Anwendungen erreicht. Auf diese Weise entsteht ein sogenannter „Situational Layer Cake“ (quasi eine Schichttorte im übertragenen Sinne) aus vier Schichten:

• Organisation
• Framework
• Division
• Implementation 

Eine weitere Darlegung der Bedeutung des Situational Layer Cake finden Sie in diesem Partner Spotlight Talk in der Pega Community.  

Klicken Sie in der folgenden Abbildung auf die Pluszeichen (+), um Details zu den vier Schichten im Situational Layer Cake anzuzeigen.

Ein Einzelhandelsunternehmen in der Bekleidungsbranche besteht aus zwei Geschäftsmarken. Die eine Marke konzentriert sich auf den gehobenen Bekleidungsmarkt, während die andere Marke eine wertorientierte Ladenkette betreibt. Jede Marke muss zurückgegebene Artikel verwalten. Der Einzelhändler kann eine allgemeine Anwendung entwickeln, die Kleidungsrückgaben auf der Framework-Schicht verwaltet. Jede Marke kann dann eine Implementation-Schicht erstellen, um den Retourenprozess individuell anzupassen. Jede angepasste Anwendung enthält markenspezifische Ressourcen, wie z. B. Styling und Richtlinien.

Die in der Prepare-Phase getroffenen technischen Designentscheidungen können eine Anwendungsstruktur auf den folgenden Schichten widerspiegeln:

Die Schichten sind folgendermaßen von oben nach unten aufgebaut:

• Die höchsten Schichten sind die Implementation-Schichten (eine für jeden Laden), die nebeneinander oberhalb der Framework-Schicht liegen. Jede Implementation-Schicht ist für jeden Laden spezifisch und enthält Upscale Brand- und Returns-Spezialisierungen.
• Unter den Implementation-Schichten liegt die Framework-Schicht, die häufig genutzte technische Komponenten für den Returns-Prozess enthält. Die Framework-Schicht liegt über der Organization-Schicht.
• Die Organization-Schicht liegt über der Pega-Plattform-Schicht und enthält die üblichen technischen Assets für alle Geschäftsbereiche. Sie liegt weit unten in der geschichteten Anwendung, damit sie von jedem Prozess oder Laden genutzt werden kann, der sie benötigt.
• Als letztes befindet sich die Pega-Plattform-Schicht ganz unten. So können alle restlichen Funktionen von den darüber liegenden Schichten verwendet werden.

Anwendungen benötigen Daten, die entweder aus dem Unternehmen oder von außerhalb des Unternehmens stammen.

• Datenquellen innerhalb des Unternehmens – identifizieren Daten, die in Pega-Plattform-Anwendungen und anderen Altsystemen innerhalb des Unternehmens gespeichert sind.
• Datenquellen außerhalb des Unternehmens – identifizieren Daten, die in Softwaresystemen oder Anwendungen von Drittanbietern gespeichert sind.

Um Ihr Datenmodell zu erstellen, ermitteln Sie zunächst, welche Datenelemente in den vorhandenen Systemen gespeichert sind. Insgesamt berücksichtigen Sie Daten aus drei Quellen: Pega, Unternehmen und externe Anbieter.

Bei den Designentscheidungen bezüglich der Daten sind drei Aspekte zu beachten:

• Modell der Unternehmensdaten – Daten, die auf Unternehmensebene anwendbar und für alle im Unternehmen entwickelten oder konfigurierten Anwendungen verfügbar sind
• Modell der Anwendungsdaten – Daten, die innerhalb der Anwendung verwaltet werden
• Modell der ständigen Daten – Daten, die eine Nachschlage- oder Referenzdatenquelle benötigen

Das Unternehmen MyDebt unterstützt Personen in finanziellen Schwierigkeiten mit der Bewältigung ihrer Schulden. MyDebt verfügt über eine Pega-Plattform-Anwendung namens DebtSol, die es den Sachbearbeitern mit Kundenkontakt ermöglicht, Anrufe von Einzelpersonen entgegenzunehmen und Schuldenlösungen für deren aktuelle Schwierigkeiten anzubieten.  Die Anwendung ist darauf ausgelegt, Details über die Person und ihre aktuelle finanzielle Situation zu erfassen, z. B. Schuldenhöhe, Einkommen, Ausgaben und Vermögen, und dann anhand von Geschäftsregeln eine Lösung für die Schulden anzubieten.

Das Datenmodell für die Anwendung macht sich ein wiederverwendbares unternehmensweites Datenmodell zunutze, um die persönlichen Daten der Person zu erfassen, und hat ein für die DebtSol-Anwendung spezifisches Datenmodell identifiziert.

Klicken Sie in der Abbildung auf die Pluszeichen (+), um Details zum Beispieldatenmodell anzuzeigen.

Die Pega-Plattform-Authentifizierung stellt sicher, dass nur Benutzer und Systeme mit verifizierten Identitäten auf Ressourcen wie Webseiten, APIs und Daten zugreifen können.

Beispiele für die Authentifizierung:

• Benutzer-Login
• Plattformanfragen an externe Dienste
• Anfragen externer Dienste an die Plattform

Erwägen und wählen Sie einen geeigneten Authentifizierungsmechanismus und eine geeignete Konfiguration für die Operatordatensätze, um die Organisationshierarchie, Arbeitsgruppen und Postkörbe zu berücksichtigen. Sie können Autorisierungs- oder Zugriffskontrollfunktionen der Pega-Plattform verwenden, um Benutzeraktionen einzuschränken. 

Gehen Sie die drei grundlegenden Autorisierungsmodelle im Vorfeld mit Ihrem Team durch, um zu entscheiden, welches für Ihr Projekt geeignet ist.

• Rollenbasierte Zugriffskontrolle (RBAC)
• Attributbasierte Zugriffskontrolle (ABAC)
• Clientbasierte Zugriffskontrolle (CBAC)

Sicherheit

Es ist auch wichtig, während der Prepare-Phase zu überprüfen und zu bestimmen, welche Punkte der Sicherheits-Checkliste auf den Projektkontext zutreffen.

Achten Sie insbesondere auf Folgendes: 

• Authentifizierungsschema
• Zugriffsgruppen/Rollen
• Organisationsstruktur
• Timeout-Konfiguration
• Auditing
• Sicherheit von Datei-Uploads   

Wenden Sie für alle sensiblen oder personenbezogenen Datenelemente angemessene Sicherheitsmaßnahmen an, um die Konfiguration und den Zugriff des Benutzers zu schützen, z. B. Verschlüsselung, Verschleierung oder kontrollierter Zugriff.

Weitere Informationen zur Anwendungssicherheit finden Sie im Thema Sicherheits-Checkliste der Pega Academy.

Die Pega-Plattform unterstützt verschiedene Integrationsstandards und Kommunikationsprotokolle, damit Sie sich nicht um Konnektivitätsprobleme kümmern müssen, sondern sich auf die geschäftsrelevanten Anforderungen Ihrer Anwendung konzentrieren können. Überprüfen und bestätigen Sie, dass Sie für jede Integrationskomponente über geeignete Details zur Konfiguration und Bereitstellung verfügen.  

Stellen Sie zum Beispiel sicher, dass Sie die folgenden Aspekte in Bezug auf jede Integrationskomponente sehen, verstehen und klar erkennen können:

• URLs pro Umgebung
• Protokolle
• Authentifizierung
• Cloud- oder On-Premise-Repository oder Drittanbieter (Content-Management)
• SSL/TLS – Versionen
• Zertifikate
• Ports

Die Implementierung der Anwendung erstreckt sich über den gesamten Lebenszyklus des Projekts, um die Anwendung durch die verschiedenen Umgebungen zu migrieren – von der Entwicklung über das Staging bis hin zur Produktion. Die IT-Abteilung des Kunden und Ihr technisches Team müssen sich auf einen Ansatz für die Verwaltung der Aufgaben innerhalb der Entwicklungsumgebung einigen und entscheiden, wie die Anwendung am besten implementiert werden kann. Beziehen Sie DevOps von Anfang an in das Projekt ein.

Der LSA leitet die DevOps-Gespräche während der Prepare-Phase, um die Einhaltung der Best Practices von Pega Express zu gewährleisten und damit die technische Qualität und eine schnelle Bereitstellung sicherzustellen.  In diesen Gesprächen legt der LSA die Anwendungsstruktur und DevOps-Best-Practices für das technische Team der Pega-Anwendung fest.    

Im Rahmen des Bereitstellungsansatzes von Pega Express bedeutet die Nutzung einer DevOps-Umgebung für die Anwendungsentwicklung, dass die Entwickler in Verzweigungen arbeiten, um ihre Updates für die Anwendung zu konfigurieren und Implementierungspipelines für die Migration der Anwendung von einer Umgebung in eine andere zu definieren. Vollständige Implementierungen sollten von Anfang an konfiguriert werden. Das bedeutet, dass die Anwendung als Ganzes von einer Umgebung in eine andere migriert wird – also nicht in Form inkrementeller Pakete. 

Durch diese Best Practice wird sichergestellt, dass das Implementierungspaket eine kumulative Sammlung aller Regeln in der Anwendung und der Daten enthält, gleichzeitig aber die Flexibilität gewahrt bleibt, da nur das implementiert wird, was sich seit der letzten Implementierung geändert hat.

DevOps-Pipelines sollten mit allen empfohlenen gegenseitigen Kontrollen konfiguriert werden, einschließlich:

• Sicherheits-Checkliste
• Einhaltung von Guardrails
• Ausführung von Komponenten- und Szenariotests
• Sicherstellung der Qualität der Anwendung bei der Migration von einer Umgebung in eine andere   

Definieren Sie von Beginn an eine klare Strategie für die Berichterstattung, damit die Pega-Plattform-Anwendung so konzipiert wird, dass sie Berichte sowohl über das operative Geschäft als auch über das Management erwartungsgemäß unterstützt. Häufig möchten Unternehmen mit Pega-Plattform-Anwendungen ihre bestehenden Data-Warehouse-Lösungen mit Daten versorgen.

Zu diesem Zweck empfiehlt es sich, Daten mit dem Extrahierungstool Business Intelligence Exchange (BIX) aus Ihrer Pega-Plattform-Anwendung zu extrahieren. Die Identifizierung dieser Anforderung im Vorfeld beeinflusst die Konfiguration der Datenobjekte in der Pega-Plattform-Anwendung und die Schnittstellenlösung, die für die Integration mit dem Data Warehouse verwendet wird. 

Die folgenden wichtigsten Designfragen sind vorab zu klären, wenn es um die Extrahierung von Daten geht:

• Häufigkeit der Extrahierung (z. B. täglich/wöchentlich)
• Art der Transaktionsextrahierung (jede Transaktion oder kumulierte EOD-Transaktion)
• Extrahierungsverlauf
• Alle Eigenschaften oder bestimmte Eigenschaften
• Extrahierungsformat (CSV, XML oder DB)

Die Architektur der Benutzeroberfläche (UI) ist Teil des technischen Designs der Anwendung. 

Die UI deckt Folgendes ab:

• Best Practices, die während des Projekts anzuwenden sind
• Arbeitsmethoden für das Team  

Zu Beginn des Projekts leitet der UI-Lösungsentwickler in Zusammenarbeit mit dem Product Owner, dem Lead Business Architect, dem Lead Systems Architect und den Testern mehrere Sitzungen zur Definition der UI-Architektur.  Diese frühen Entscheidungen stellen sicher, dass die Benutzeroberfläche einfach zu pflegen ist, in der gesamten Anwendung konsistent ist und den Best Practices für UIs entspricht.  

Der UI-Lösungsentwickler berücksichtigt Folgendes:

• Designsysteme
• Skin-Wiederverwendung (z. B. Branding und Styling)
• Nichtfunktionale Anforderungen
• Web-Self-Service-Architektur
• Governance-Prozesse

Ab Pega-Plattform Version 8.3 können Sie Ihre Benutzeroberfläche nahtlos mit Cosmos beschleunigen.  Weitere Informationen zur Gestaltung einer erstklassigen User Experience mit Cosmos finden Sie im TechTalk in der Pega Community mit dem Titel Accelerate your workflow with Cosmos UI (Beschleunigen Ihres Workflows mit der Cosmos-Benutzeroberfläche). 

Ab der Pega-Plattform-Version 8.7 können Sie mit dem Constellation-Designsystem Anwendungen mittels vorgegebenen Designs und einer visuellen Architektur entwickeln. Weitere Informationen zur Anwendungsentwicklung mit Constellation finden Sie unter Constellation-Anwendungen konfigurieren.

Klicken Sie in der folgenden Abbildung auf die Pluszeichen (+), um Details zur Benutzeroberfläche anzuzeigen.