Sie sind auf Seite 1von 18

Opinion Paper

Entwicklung ganzheitlicher Portalarchitekturen

2011/03

Opinion Paper Entwicklung ganzheitlicher Portalarchitekturen 2011/03 We make ICT strategies work
Opinion Paper Entwicklung ganzheitlicher Portalarchitekturen 2011/03 We make ICT strategies work

Entwicklung ganzheitlicher Portalarchitekturen

Inhaltsverzeichnis

3

2 Portale zwischen Agilität und Governance 4

1 Executive Summary

3 Referenzmodell für Komponenten der Portalarchitektur

7

3.1

Core Services

7

3.1.1

Plattform

8

3.1.2

Hochverfügbarkeit

8

3.1.3

Performance

8

3.1.4

Datenspeicherung

9

3.1.5

Mandantenfähigkeit

9

3.1.6

Security 9

3.1.7

SSO

10

3.1.8

Monitoring 10

3.1.9

Caching

10

3.1.10

Metadata 10

3.1.11

Service-Repository

10

3.1.12

Entwicklungsunterstützung 11

3.2

Interaction & Communication

11

3.2.1

Presentation

11

3.2.2

Accessibility

12

3.2.3

Personalization

12

3.2.4

Aggregation

12

3.2.5

Search Engine Optimization

12

3.2.6

User Engagement 13

3.2.7

Collaboration & Feedback

13

3.3

Administration & Integration

14

3.3.1

Integration 14

3.3.2

Administration 14

3.3.3

Transaction 15

4 Die Portalarchitektur als Investition in die Zukunft 16

5 Der Autor

17

6 Das Unternehmen

18

1 Executive Summary

Entwicklung ganzheitlicher Portalarchitekturen

Der fortschreitende Erfolg der Internettechnologie hat das Konsumverhalten von Kunden, die Kollaboration mit Geschäftspartnern und die Formen sozialer Interaktion innerhalb der Un- ternehmen stark beeinflusst und verändert. Durch das Internet sind Unternehmen heute zunehmend Vergleichs- und Bewertungsmöglichkeiten ausgesetzt. Kunden möchten um- fangreiche Online-Funktionen im Bereich von Sales und Services nutzen. Mitarbeiter erwar- ten die Adaption von privaten Erfahrungen mit Social Media auf die Alltags- und Kollaborati- onswirklichkeit innerhalb der Unternehmen.

Bestehende Interaktionswege mit Kunden, Geschäftspartnern und Mitarbeitern müssen auf die Anforderungen des Konsums von Webinhalten und webbasierten Medien angepasst werden: neue Wege sind zu gehen. Anforderungen an die Geschäftsmodelle und die Unter- nehmenskultur in den Bereichen Informationsverteilung, Sales und Service bzw. im Kontext der Kollaboration mit Kollegen, Partnern und Kunden aus dem Bereich Web 2.0/Enterprise 2.0 verändern sich permanent. Unternehmen müssen agil auf diese Marktherausforderungen reagieren. Unternehmensführung und Fachabteilungen formulieren kontinuierlich neue An- forderungen an ihre Portale.

Die Agilität des Unternehmens soll sich in entsprechender Agilität im Außen- und Innenauf- tritt ausdrücken. Die Optik soll aktuell sein, die erfolgreichen Konzepte der Consumer Sites und Social Networks sollen schnell und flexibel für Portale adaptiert werden. Der Druck auf die IT-Bereiche wächst, den Status quo zu ändern und neue Web-Applikationen und webba- sierte Services zeitnah und flexibel umzusetzen. Dabei ist die IT mit klaren Anforderungen aus Sicht der Governance an jegliche Interaktion mit Kunden, Partnern und Mitarbeitern sowie der zugrunde liegenden Informationstechnologie konfrontiert. Nachhaltig und investiti- onssicher soll die Informationstechnologie entwickelt werden.

Beide Anforderungspole (Agilität für Web 2.0/Enterprise 2.0 und Governance) nachhaltig zu bedienen, ist die zentrale Herausforderung in der Entwicklung einer Anwendungsarchitektur für Web-Applikationen. Eine ganzheitliche Portalarchitektur muss die Geschäftsanforderun- gen aus Intranet-, Extranet- und Internetszenarien vereinen und auf die zugrunde liegenden Portalkomponenten abbilden. Sie dient als zentrale und erweiterbare Bibliothek an Definitio- nen von Portalfunktionen und eingesetzten Lösungen innerhalb der IT-Landschaft und fun- giert als Baukasten für Implementierungsprojekte. Die Portalarchitektur beschreibt die Por- talkomponenten als Services und Funktionen und gibt damit z.B. Auskunft, welche Enterpri- se 2.0/Social Media-Ansätze innerhalb des Unternehmens unterstützt werden oder wie Customer Self Services umsetzbar sind.

Ein Referenzmodell für den Aufbau von Portalarchitekturen visualisiert und ordnet die ver- schiedenen Komponenten der Portalarchitekturentwicklung und bildet die Basis und den Ausgangspunkt für die erfolgreiche Entwicklung und Einführung ganzheitlicher Portalarchi- tekturen.

Entwicklung ganzheitlicher Portalarchitekturen

2 Portale zwischen Agilität und Governance

Webtechnologie hat in den letzten 20 Jahren einen grandiosen Siegeszug in fast alle Berei- che der Gesellschaft und des Geschäftslebens angetreten. Als universitärer Support von Dokumentation und Kollaboration konzipiert, ist das World Wide Web inzwischen omniprä- sent. Menschen interagieren im Web, vernetzen sich, tauschen Informationen aus, verglei- chen Produkte und konsumieren online.

Entsprechend dieser Entwicklung sind Unternehmen herausgefordert, ihre bestehenden Interaktionswege mit Kunden, Geschäftspartnern und Mitarbeitern an die Anforderungen dieser Entwicklung anzupassen bzw. neue Wege zu gehen. Stetig werden neue Anforderun- gen an die Geschäftsmodelle und die Unternehmenskultur in den Bereichen Informationsver- teilung, Sales und Service bzw. im Kontext der Kollaboration mit Kollegen, Partnern und Kunden aus dem Bereich Enterprise 2.0 definiert und kontinuierlich an neue Entwicklungen angepasst.

Vodcasting Vodcasting Podcasting Podcasting Corporate Blogging Corporate Blogging Wiki Wiki Blog Blog Social
Vodcasting
Vodcasting
Podcasting
Podcasting
Corporate Blogging
Corporate Blogging
Wiki
Wiki
Blog
Blog
Social Networks
Social Networks
Tagging
Tagging
Social Software
Social Software
Rich Internet Applications
Rich Internet Applications
Folksonomy
Folksonomy
Read/Write Web
Read/Write Web
Design
Design
Ajax
Ajax
Focus on Simplicity
Focus on Simplicity
Participation
Participation
User Experience
User Experience
User Centered
User Centered
Joy of Use
Joy of Use
Recommendation
Recommendation
Data-Driven
Data-Driven
Long Tail Economy
Long Tail Economy
lightweight
lightweight
Enterprise 2.0
Enterprise 2.0
Decentralization
Decentralization
Remixability
Remixability
Distributed Content
Distributed Content
Semantic Web
Semantic Web
Audio
Audio
Video
Video
Mobile
Mobile
Hackability
Hackability
RSS
RSS
Syndication
Syndication
Microformats
Microformats
Convergence
Convergence
Mashup
Mashup
OpenAPI
OpenAPI
Openness
Openness
Standards
Standards
Agility
Agility

Bild 1: Fachliche Anforderungen an Portale im Kontext Web2.0/Enterprise 2.0

Unternehmensführung und Fachabteilungen formulieren ihre Anforderungen an die „neue“ Agilität schnell. So verlangt z.B. die Unternehmensführung an jedem Ort auf die aktuellsten Kennzahlen zuzugreifen, der Vertrieb soll mobil angebunden werden, das Marketing möchte die Kundenbindung durch eine Anwender-Community erhöhen und der technische Service entlastet sein Call Center durch vorgelagerte Online Self Services. Daraus resultieren Anfor- derungen an die User Interfaces von IT-Anwendungen. Diese soll aktuell und modern sein, den Anwender jederzeit schnell bedienen. Erfolgreiche Konzepte von Consumer Sites und Social Networks bzw. neueste Trends aus dem Internet werden oftmals als pauschale An- forderungssets für neue Firmenportale formuliert. Durch die Vielfalt und den schnellen Wechsel der Anforderungen wächst der Druck auf die IT-Bereiche, neue Web-Applikationen und webbasierte Services zeitnah und flexibel umzusetzen, Änderungen vorzunehmen und neue Services online zu stellen.

Entwicklung ganzheitlicher Portalarchitekturen

Auf der anderen Seite sind klare Anforderungen aus Sicht der Governance an jegliche Inter- aktion mit Kunden, Partnern und Mitarbeitern sowie der zugrunde liegenden Informations- technologien formuliert. Die IT muss fachliche Anforderungen an die kohärente Bereitstel- lung und Governance der kommunikativen Inhalte, Produktinformationen, Preise, Prozesse etc. erfüllen. Die Archivierung der Inhalte und Transaktionsdaten soll sichergestellt sein. Unterschiedlichste Business- und Legacy-Applikationen sind zu integrieren. Datensicherheit sowie Datenschutz sind zu gewährleisten und die IT muss Augenmaß und Nachhaltigkeit im Umgang mit Investitionen beweisen. Und dies angesichts stets wechselnder und sich neu entwickelnder fachlicher Anforderungen an Userinterfaces, Microsites, Rich Internet Applica- tions, Unterstützung mobiler Clients und des immensen Schubs von Consumer und User Driven Computing innerhalb der Unternehmen.

Penalties Quality Rules Regulation & Sustainability Treatments Control Documentation Reporting Processes
Penalties
Quality
Rules
Regulation &
Sustainability
Treatments
Control
Documentation
Reporting
Processes
Consolidation
Templates
Governance
Standards
Centralization
Integration
Security
Coherence
Patterns
Rollout
Roles & Responsibilities

Bild 2: Anforderungen an Portale im Kontext von Governance

Die Auflösung der Spannung zwischen der extremen Agilität der Fachanforderungen und der relativen Trägheit der IT ist die zentrale Herausforderung in der Entwicklung von Webappli- kationen für Unternehmen.

Auf der einen Seite müssen Portale (sowohl Content- als auch Applikationsportale) grund- sätzlich als eine Infrastrukturkomponente im Rahmen der Applikationslandschaft begriffen und entwickelt werden. Die einzelnen Architekturkomponenten müssen nachhaltig in der zentralen Anwendungsarchitektur gepflegt werden. Auf der anderen Seite bedarf es hoher Flexibilität bei der Entwicklung neuer Webapplikationen und Sites.

Nur ein ganzheitlicher Ansatz in der Entwicklung der Anwendungsarchitektur für eine Portal- infrastruktur mit klarer Definition der Aufgaben der eigentlichen Portalapplikation sowie der Abgrenzung zu spezialisierten Support-Systemen und den Backend- und Legacysystemen sowie definierten Regeln für die Weiterentwicklung auf unterschiedlichen Ebenen kann hier auf Dauer helfen.

Entwicklung ganzheitlicher Portalarchitekturen

Eine ganzheitliche Portalarchitektur muss die Geschäftsanforderungen aus Intranet-, Extra- net- und Internetszenarien vereinen und auf die zugrundeliegenden Portalkomponenten abbilden. Sie dient als zentrale und erweiterbare Bibliothek an Definitionen von Portalfunkti- onen und eingesetzten Lösungen innerhalb der IT-Landschaft und fungiert als Baukasten für Implementierungsprojekte (Verringerung Time to Web/Erhöhung Synergien und Wiederver- wendung von Anwendungen (getätigte Investitionen)). Zusätzlich lassen sich über die Por- talarchitektur Whitespots in der Applikationslandschaft visualisieren und Schnittstellen zu anderen Anwendungsbereichen identifizieren.

Die Portalarchitektur beschreibt die Portalkomponenten als Services und Funktionen und gibt damit z.B. Auskunft und Übersicht, welche Enterprise 2.0/Social Media-Ansätze inner- halb des Unternehmens unterstützt werden oder mit welchen Services und Funktionen Customer Self Services umsetzbar sind.

Entwicklung ganzheitlicher Portalarchitekturen

3 Referenzmodell für Komponenten der Portalarchitektur

Das folgende Referenzmodell basiert auf den oben beschriebenen Rahmenparametern für eine Portalinfrastruktur. Es ermöglicht Unternehmen die Entwicklung und Ableitung eigener Referenzmodelle und definiert eine erste Ebene von Fragestellungen und Anforderungen an eine aktuelle Portalinfrastruktur. Bei der Entwicklung des Referenzmodells wurde darauf geachtet, die Portalinfrastruktur funktional zu halten und nicht in ihrer Aufgabenstellung zu überdehnen. So werden spezielle Servicefunktionen (z.B. Identity Management, Enterprise Search) in über Schnittstellen anzubindende zentrale Enterprise Dienste ausgelagert sowie Business-Logik in den Legacyanwendungen belassen. Über Schnittstellen angebundene Systeme sind blau und kursiv markiert.

Interaction & Communication

Presentation (e.g. Multichannel, Mobile, Microsites, Widgets), Accessibility, Personalization, Aggregation
Presentation (e.g. Multichannel,
Mobile, Microsites, Widgets),
Accessibility, Personalization,
Aggregation
Collaboration &
(e.g. Mashups),
User
SEO
Feedback
Engagement
(e.g. Blogs, Wikis,
Forum, Mail, User
Generated Content)
Core
(e.g. Web Controlling,
Recommendations,
Experience Management,
Dashboards, Reporting),
Services
(e.g. Platform, Security, SSO,
Monitoring, Caching,
Metadata, API)
Integration
Transaction
(e.g. Connectivity,
(Quotes/Calculators,
Messaging &
Orders, BPM,
Routing)
Commerce, Billing)
Administration
(e.g. WCMS, Profiles,
Cockpits, Toolboxes)
(Identity Management,
Enterprise Search, DMS,
DAM, PIM, CRM, BI)

Quelle: Detecon International GmbH

Administration & Integration

Bild 3: Schematische Darstellung: Referenzmodell der Portalkomponenten

3.1 Core Services

Die Core Services summieren alle zentral genutzten Anforderungen an die Portalinfrastruk- tur. Diese zentralen Services stellen ein Set an technischen Basisfunktionen bereit. Über die Ausgestaltung der Core Services werden zusätzlich zentrale Aussagen zur Plattform und verschiedene nicht-funktionale Anforderungen (vor allen Dingen zu Verfügbarkeit, Perfor- mance usw.) platziert. Die Core Services bilden das die Portalarchitektur determinierende Herzstück. Sie sind nach der Erstimplementierung als relativ stabil zu betrachten. Bei der Definition und Entwicklung der Core Services ist somit besondere Sorgfalt gefragt, jegliche Änderungen können Auswirkungen auf alle peripheren Services und Funktionen haben.

Entwicklung ganzheitlicher Portalarchitekturen

3.1.1 Plattform

Die Basis der Portalarchitektur ist die technologische Plattform. Grundsätzlich stehen neben Plattformen aus der Java-Welt noch Technologien von Microsoft zur Verfügung. Hier sind oftmals bereits innerhalb der Unternehmen strategische Vorgaben gesetzt, die in die eine oder andere Richtung zeigen. Im Rahmen eines Greenfield-Ansatzes für eine neue Portalar- chitektur ist die Plattformauswahl ein zentraler Erfolgsfaktor. Hier muss die Plattform – zu- sätzlich zur kommerziellen Prüfung – den aus einem klaren Zielbild abgeleiteten und gewich- teten Anforderungen genügen. Diese Anforderungen müssen mit dem jeweiligen Portalsoft- warehersteller hinsichtlich der Frage, welche Funktionen im Softwarestandard inbegriffen sind, diskutiert werden. Zusätzlich ist zu prüfen, welche Komponenten über 3rd-Party- Anbieter erworben werden können. Dabei sind eventuelle Folgen für die Systeme mitzube- denken; deren Komplexität sollte möglichst gering gehalten werden. Daneben stellt sich die Frage, wie viel eigene Entwicklungsleistung das Unternehmen eventuell leisten muss bzw. möchte. Außerdem ist für die jeweilige Plattform die Verfügbarkeit geeigneter Entwickler und Berater am Markt bzw. innerhalb des Unternehmens zu prüfen: Zu welchem Preis können externe Leistungen eingekauft werden?

Im Markt für Portalsoftware sind Java-basierte Infrastrukturen stark vertreten. Neben diver- sen Enterprise-Anbietern wie Oracle oder IBM finden sich in der Java-Welt zahlreiche Open Source-Projekte und Anbieter. Die Microsoft-Plattform stellt sich dort technologisch enger und auf den ersten Blick standardisierter dar als Java-Architekturen. Diese müssen sich spätestens im Rahmen einer Integration von Dokumentenmanagement-Diensten hinsichtlich ihrer Integrationsfähigkeit von Microsoft Office, Sharepoint Services und weiterer Microsoft- Technologien vergleichen lassen. Microsofts Portallösung ist im Rahmen einer Plattformprü- fung auf jeden Fall intensiver zu analysieren. Spezifisch ist der Ansatz von SAP Netweaver als „JAVA/ABAP-Hybrid“ (z.B. Herausforderungen im Kontext des Supports aktueller Java Development Kits (JDK’s) zu bewerten, der aber als Portalkomponente gerade für SAP- Shops oft relativ geringe Softwarelizenzkosten nach sich zieht.

3.1.2 Hochverfügbarkeit

Essentiell für den Einsatz einer Portalarchitektur sind Hochverfügbarkeitsszenarien. Eine Portalarchitektur muss hohen Anforderungen an die Verfügbarkeit genügen und solche Sze- narien definitiv abfragen (z.B. Clustering, Lastverteilung, Virtualisierung etc.). Die Verfügbar- keitsanforderungen haben auch explizit Auswirkungen auf das Implementierungsprojekt, die Weiterentwicklung sowie den Betrieb des Portals (z.B. in der Governance, im Management von Anforderungen und der Entwicklung neuer Funktionen).

3.1.3 Performance

Häufige Beschwerden im Kontext von Portalen sind schwache Performance und gefühlte Langsamkeit. Kunden und Mitarbeiter erwarten heute von Webapplikationen adäquate Ant- wortzeiten, die Geduld der Anwender ist dies betreffend gering. Im Rahmen einer Portalent- wicklung müssen hier klare KPIs und Bewertungsgrundlagen geschaffen werden. An die Portalarchitektur ergibt sich daraus die Anforderung, entsprechende Performancemessun- gen von Applikationsseite zu unterstützen, das eigene Lastverhalten sauber zu loggen und Funktionen für konfiguratives Performancetuning zu bieten (z.B. Tuning der Java Virtual Machine). Hier sind die Anbieter von Portalsoftware gefragt, entsprechende Referenzwerte für die Skalierung (Lastszenarien) vorzulegen.

Entwicklung ganzheitlicher Portalarchitekturen

Eine unzureichende Netzwerkinfrastruktur wirkt sich negativ auf die Performance einer Por- talinfrastruktur aus. Dem muss mit Network Audits und Analysen der gesamten Delivery Chain entgegen gewirkt werden, damit etwaige Bottlenecks aufgespürt werden können. Alle Entwicklungen und das Customizing müssen entsprechend auf die Performanceziele der Portalarchitektur einzahlen. Test- und Abnahmeverfahren müssen implementiert werden, damit funktionale Anpassungen nicht das gesamte Portalsystem oder Teile davon lahmle- gen. Die Performance eines Portals muss grundsätzlich holistisch betrachtet und bearbeitet werden. Unzählige Beispiele im Markt zeigen, dass schlechte Performance vielfach auf ein- fache, unzureichende Netzinfrastrukturkonfigurationen, ungenügend getunte Java Virtual Machines oder auch schlecht entwickelte, wenig erprobte Webapplikationen zurückzuführen ist. Meist findet sich im Rahmen einer ganzheitlichen Analyse ein Junktim aus Faktoren auf allen Ebenen der Architektur, deren Bearbeitung zu einer ganzheitlichen Verbesserung der Performance führt.

3.1.4 Datenspeicherung

Im Rahmen der Portalstrategie ist definitiv die Datenbankstrategie des Unternehmens mit in Betracht zu ziehen. Alle relevanten Portalprodukte benötigen zur Datenspeicherung entspre- chende Datenbanksysteme. In die Überlegungen für die Datenhaltung ist einzubeziehen, dass ein nicht zu vernachlässigender Anteil der zu speichernden Daten Userauswertungen und Statistikdaten sind (siehe auch User Engagement). Im Kontext der Datenspeicherung sind ebenfalls Anforderungen hinsichtlich möglicher Revisionssicherheitsvorgaben wie z.B. die Wiederherstellung historischer Versionen, die Bereitstellung von Audit Trails, Reporting und Archivierung zu diskutieren.

3.1.5 Mandantenfähigkeit

Mandantenfähigkeit ist ein oftmals stark unterschätztes Feature, welches von einzelnen Softwareanbietern sehr unterschiedlich gelöst bzw. sehr unterschiedlich definiert wird. Die Angebote gehen von lose getrennten Sites in einem Multisitekontext mit Contentsharing- Funktionen bis zu revisionssicher abgegrenzten Communities. Hier ist im Vorfeld eine klare interne und fachliche Begriffsdefinition auf Basis der Anforderungen wichtig. Erfahrungsge- mäß ist kaum eine nachträgliche Änderung im Scope einer Portalanwendung kostenintensi- ver als die Implementierung der Mandantenfähigkeit. Ein Portal nachträglich mandantenfähig zu machen bzw. die Mandantenfähigkeit zu verändern (z.B. nachträgliche Implementierung von mandantenübergreifendem Content Reuse), kann ähnlich teuer werden wie eine Neu- entwicklung.

3.1.6 Security

Begreift sich ein Portal als Einstiegspunkt für Kunden und/oder Mitarbeiter zum Zugriff auf Unternehmensinformationen, -services und -prozesse, so stellt sich zwangsläufig die Frage nach den Mechanismen der Eingangssicherung und Zugangskontrolle. Neben den gängigen Sicherungs- und Verschlüsselungsmechanismen fällt in diesen Kontext auch die Frage nach dem Datenschutz. Dahingehende Anforderungen sind nicht nur softwareseitig, sondern auch prozessual zu definieren und abzuprüfen (z.B. regelmäßige sowie unabhängige Penetrati- onstests und Security Audits).

3.1.7 SSO

Entwicklung ganzheitlicher Portalarchitekturen

Kernfeature der ersten Portalimplementierungen zum Beginn des Jahrtausends war das Bereitstellen von Single-Sign-on-Funktionalitäten. Im Rahmen einer heutigen Portallösung sollte dieses Feature nicht als portalintrinsische Funktion betrachtet werden, sondern viel- mehr hinsichtlich der Frage, welche Standards vom Portal unterstützt werden. Die Funktion SSO bedient sich in modernen Infrastrukturen zentralen Identity Management Systemen und weiteren vom Unternehmen strategisch gesetzter Mechanismen (z.B. Kerberos, NTLM bis hin zu PKI-Lösungen).

3.1.8 Monitoring

Die oben beschriebenen Anforderungen an die Performance und das Tuning einer Portalar- chitektur sowie an einen reibungslosen Betrieb bedingen Anforderungen an die Unterstüt- zung von Monitoringstrategien. Die Portalarchitektur muss in der Lage sein, sehr genau und spezifisch ihren eigenen Zustand und ihre eigene Reaktion auf geänderte Außenbedingun- gen (z.B. eine vermehrte Last durch erhöhte Zugriffe) auf Service- und Modulebene wider- zuspiegeln und an System- und Servicemanagement-Tools (z.B. Tivoli) weiterzugeben.

3.1.9 Caching

Im Zuge der Erfüllung von Anforderungen hinsichtlich immer dynamischerer Webapplikatio- nen steht eine Portalarchitektur vor der Herausforderung, an der richtigen Stelle Performan- ce und Lastvermeidung durch intelligente Nutzung von Caches als Puffer-Speicher zu er- möglichen. Hier gilt es im Rahmen der Konzeption klar zu definieren, an welchen Stellen Informationen im Cache abgelegt werden können und wo dynamisch ausgeliefert werden muss bzw. an welchen Stellen sogar statischer Content ausgeliefert werden kann.

3.1.10 Metadata

Die übergreifende Nutzung von Metadaten bietet ungeahnte Möglichkeiten, unstrukturiertem Content einen quasistrukturierten Charakter zu verschaffen und diesen in Relation zu den Geschäftsprozessen zu setzen. Außerdem bieten Metadaten eine viel größere Flexibilität in der Erstellung von Taxonomien, alternativen Navigationsbäumen usw. als klassisch hierar- chische Verwaltungsmechanismen. Seine volle Kraft kann Metadata-Management aber nur entfalten, wenn das Metadatenmodell in Korrelation und Abstimmung mit übergreifenden Master-Data-Management-Initiativen entwickelt wird und erweiterbar bleibt.

3.1.11 Service-Repository

Eine Portalarchitektur muss über ein zentrales Repository verfügen, an dem Portalservices angemeldet werden und über welches diese Portalservices zentral verwaltet werden können. Das Services-Repository fungiert quasi als zentrales Telefonbuch für die Portalarchitektur, darf aber nicht mit einem Service-Repository im Sinne einer SOA-Architektur verwechselt werden. Ein Portal-Service-Repository bietet zum Beispiel das PCD (Portal Content Directo- ry) des SAP-Netweaver-Portals.

3.1.12 Entwicklungsunterstützung

Entwicklung ganzheitlicher Portalarchitekturen

Zentrale Voraussetzung für die Investitionssicherheit der Portalarchitektur sind die Möglich- keiten für Entwickler auf standardisierten, stabilen und dokumentierten APIs aufzusetzen. Jegliches Customizing und alle Weiterentwicklungen müssen auf der Basis solcher APIs aufgesetzt werden. Entwickler- und Entwicklungsunterstützung durch Software Development Kits, Entwicklerhandbücher, Schulungen sowie Patterns beschleunigen die Lernkurve und senken Risiken in der Implementierung. Eine gute Dokumentation und die Verwendung von Standardkomponenten machen es deutlich leichter, neue Entwickler in das Team einzufüh- ren und gegebenenfalls die Entwicklung später auszulagern bzw. den Implementierungs- partner zu wechseln. Zusätzlich zur Kapselung der Entwicklung auf der Basis von APIs sollte eine moderne Infrastruktur in der Lage sein, auf der Basis von Templates (z.B. Velocity) die Entwicklung von Applikationen auf dem Presentation Layer leichtgewichtig zur Verfügung zu stellen. Gerade die Benutzeroberflächen betreffende Agilitätsanforderungen von Marketing- abteilungen und Agenturen lassen sich nur erfüllen, wenn Änderungen auf dem Presentation Layer leicht durchgeführt sowie schnell und ohne Ausfallzeiten abgewickelt werden können.

3.2 Interaction & Communication

3.2.1 Presentation

Einer der Faktoren für eine erfolgreiche Portalarchitektur ist eine große Flexibilität des Pre- sentation Layers auf Basis eines relativ stabilen und statischen Cores. Der Presentation Layer muss in der Lage sein, aktuelle UIs umzusetzen (Joy of Use). Neben dem Webkanal müssen diverse Mobile Channels bedient werden, aber auch Multichannel-Szenarien wie Print-to-PDF oder RSS-Feeds müssen einfach umzusetzen sein. Aktuelle fachliche UI- Anforderungen, die miteinander interagierende Widgets, Widget Stores und Enterprise Dashboards betreffen, müssen ebenso zu implementieren sein wie klassische, inhaltsorien- tierte Designs. Wichtig für die Investitionssicherheit der Portalarchitektur ist die Beantwor- tung der Frage, wie flexibel und schnell auf der Oberfläche neue Inhalte, Layouts, Mashups und Microsites entstehen können, ohne tiefgreifende Entwicklungen und Eingriffe in die ei- gentliche Infrastruktur zu benötigen (siehe auch API). So sollte eine Multimedia-Agentur in der Lage sein, lediglich durch Styleänderungen und auf der Basis wieder verwertbarer Por- talservices neue Sites und Portale online zu stellen (z.B. Kampagnensites, Themensites usw.). Ein weiterer Aspekt ist in diesem Zusammenhang der Zusammenschluss verschiede- ner Portalsites (Federated Portals), z.B. wird das Procurement Portal mit Teilen des Finance Portals zusammen im informationsarchitektonisch übergeordneten Intranetportal eingehängt.

Im Kontext der Präsentation der Auftritte bzw. der Portale sind natürlich auch alle Anforde- rungen nach Mehrsprachigkeit zu erfüllen. Hier reicht sicherlich nicht die lediglich technische Unterstützung von Mehrsprachigkeitskonzepten (z.B. UTF8), sondern es sind hier unter an- derem Fragen nach dem Support, den Übersetzungsworkflows und dem grundsätzlichen Konzept der Mehrsprachigkeit von Inhalten zu klären.

3.2.2 Accessibility

Entwicklung ganzheitlicher Portalarchitekturen

Eine spezifische, oft vernachlässigte Anforderung ist der Aspekt der Barrierefreiheit von In- ternetseiten (Accessibility), d.h. die behindertengerechte Aufbereitung elektronischer Inhalte und Informationen. Die Internetangebote der öffentlichen Hand richten sich bereits seit 2005 nach der Barrierefreien Informationstechnik-Verordnung (BITV), die die Anforderungen an barrierefreie Internetauftritte und -angebote festlegt. Der Privatwirtschaft ist die Erfüllung freigestellt. Zwar wird Barrierefreiheit vielfach angefordert, zuletzt aber vor dem Hintergrund von Javascript und Flashanwendungen nicht verwirklicht. Dabei gibt es durchaus Strategien, eine zumindest partielle Barrierefreiheit zu erreichen, z.B. durch die Nutzung spezieller, de- signreduzierter Seitenversionen. Gerade in den immer älter werdenden westlichen Gesell- schaften wird dieser Punkt nach und nach stärker in den Vordergrund treten.

3.2.3 Personalization

Personalisierte Inhalte im Bereich der Webapplikationen werden von Anwendern geradezu als Selbstverständlichkeit betrachtet. Die Frage, die sich hier an die Portalarchitektur stellt, ist, wie die Personalisierung umgesetzt wird. Welche technischen und funktionalen Paradig- men liegen der Personalisierung zugrunde? Wie flexibel können Inhalte und Applikationen auf das Nutzerverhalten hin ausgesteuert werden (gerichtete Personalisierung)? Welche Möglichkeiten gibt es, Personalisierung aufgrund persönlicher Settings und/oder des Nutzer- verhaltens zu steuern? Gibt es die Möglichkeit, Closed User Areas aufzubauen und zu ver- walten? Werden Portalrechte auf angebundene Inhalte aus Drittsystemen übertragen oder sind diese Systeme weiterhin selbst für das Rechtemanagement verantwortlich? Wo werden die Userbezogenen Daten gespeichert (Cookies auf dem Client? Sessioninformationen auf dem Server?). Entsprechend der expliziten Fachanforderungen ist im Rahmen der Entwick- lung einer Portalarchitektur zu klären, ob Personalisierung mit den eigenen Rule Engines des Portals oder einem 3 rd Party Personalization Framework umzusetzen ist. Bei der Spei- cherung von personenbezogenen Daten ist grundsätzlich das Bundesdatenschutzgesetz zu beachten. Im Intranetkontext sind Personalisierungskonzepte grundsätzlich mitbestim- mungspflichtig (sofern sie zur Arbeitskontrolle eingesetzt werden können). Hier ist vorab die Zustimmung des Sozialpartners einzuholen.

3.2.4

Aggregation

Neben der reinen Integration von Drittsystemen ist die Bereitstellung einfacher Funktionen, mit denen die Fachseite in der Lage ist, Inhalte zu aggregieren und miteinander in Bezie- hung zu setzen (z.B. Enterprise Mashups), eine wichtige Anforderung. Hier muss es möglich sein, sowohl aus portalinternem Content/Applikationen als auch aus externen Inhalten ag- gregierte Sichten zu komponieren. Auch in diesem Kontext ist es möglich, neben den Bord- mitteln der Portalanbieter Lösungen von Spezialanbietern am Markt zu nutzen (z.B. Kapow).

3.2.5 Search Engine Optimization

Marketingabteilungen sind oftmals nicht bereit, Einschränkungen im Design bzw. zusätzliche Aufwände in die Bereitstellung von Alternativauslieferungen von Content zur Unterstützung der Barrierefreiheit (z.B. Design reduzierte Seiten, welche von Text Readern blinden Usern vorgelesen werden können) hinzunehmen. Ganz anders sieht dies beim Thema Suchma- schinenoptimierung aus, obwohl hier auch diverse Designeinschränkungen bzw. zusätzliche Aufwände für die alternative Bereitstellung von Crawler kompatiblen Inhalten nötig sind.

Entwicklung ganzheitlicher Portalarchitekturen

Die zentralen Fragen an die Portalsoftware im Kontext von SEO (Search Engine Optimizati- on) sind die Ausgabe von sprechenden URLs (also keine kryptischen IDs), ein einfaches Management von „Metadata“ und „Keywords“, die Erstellung einer automatisierten Sitemap (auch in alternativen Sortierungen) sowie einfache Möglichkeiten des Auslieferns alternativer statischer HTML-Seiten an den Webserver und Microsites/Landingpages. Suchmaschinen- optimierung sollte nicht nur in Bezug auf Internetsuchmaschinen, sondern auch im Hinblick auf interne (Enterprise-)Search Engines betrieben werden. Portal-Inhalte müssen indizierbar und die Suchtreffer im Navigationskontext des Portals darstellbar sein. Gerade in komplexe- ren Szenarien ist eine nachvollziehbare Beeinflussung der Suchergebnisse durch Portalre- dakteure wichtig. (Wie erhöhe ich das Ranking meiner Einträge?)

3.2.6 User Engagement

Ein immer wichtiger werdender Aspekt sind Anforderungen rund um die Auswertung des Nutzerverhaltens sowie die Möglichkeiten, auf dieses „on the fly“, also unmittelbar zu reagie- ren, z.B. in Form von Empfehlungen („Kunden die dieses Produkt gekauft ha- ben…“/„Mitarbeiter, die diesen Artikel gelesen haben…“). Auch Experience Management gewinnt an Bedeutung: Wo hat der Nutzer seine „Trampelpfade“ durch das System gezo- gen? Wo hat er die Webseite verlassen oder auch den Prozess abgebrochen?). Das soge- nannte Web Controlling ist nicht mehr nur Basisdisziplin, sondern inzwischen ein umfang- reich erweitertes Konzept mit so unterschiedlichen Funktionen wie z.B. Heatmaps, Klick- pfadanalysen und Recommendation Engines, die komplexe Warenkorbanalysen durchfüh- ren können. Grundsätzlich muss jede Portalarchitektur Funktionen bereitstellen, die eine Auswertung des Nutzerverhaltens ermöglichen bzw. die für spezialisierte Tools Schnittstel- len anbieten, die diese Funktion übernehmen.

3.2.7 Collaboration & Feedback

Im Rahmen der Entwicklungen rund um Web 2.0 haben sich immer stärker Anforderungen etabliert, die Portalkonsumenten (User) stärker auch die Rolle von Content-Produzenten ermöglichen sollen. Klassisch in diesem Bereich sind Bewertungsmöglichkeiten (Ratings) sowie die bereits angesprochenen Empfehlungs- und Kommentarfunktionen. Ohne diese Feedbackmöglichkeiten kann kein modernes Portal bei seinen Nutzern Akzeptanz gewinnen. Darüber hinaus sollten moderne Web-Applikationen vielfältige weitere Funktionen bieten, über die die Nutzer unkompliziert Inhalte generieren können (User Generated Content). Ein weiterer, wichtiger Aspekt im Interesse des Unternehmens ist die Moderation dieser Inhalte durch verantwortliche Redakteure. Die adaptierten Funktionen sind den Anwendern aus Blogs, Wikis, Foren und Social Networks vertraut. Die Frage, die sich mit Blick auf die An- wendungsarchitektur stellt, ist, ob die Out-of-the-Box-Funktionen einer Portalsoftware den Anforderungen an User Generated Content genügen oder ob sich hier eventuell die Integra- tion von spezialisierter Social Media Software lohnt. Die Portalsoftware muss auf jeden Fall in der Lage sein, spezialisierte Softwaretools zu integrieren. Nutzergenerierte Inhalte können ausgezeichnet für User Engagement genutzt werden. So können Artikel mit einer hohen Bewertung in den Suchergebnissen nach oben sortiert werden. Daneben können vieldisku- tierte Inhalte bzw. Inhalte, auf die häufig verlinkt wurde, ebenfalls im Suchranking steigen (siehe auch User Engagement).

3.3 Administration & Integration

3.3.1 Integration

Entwicklung ganzheitlicher Portalarchitekturen

Eine zentrale Anforderung an Portale ist die Bereitstellung von Backendinformationen, Pro- zessen und Funktionen spezialisierter Softwaretools in mehreren konsolidierten Sichten oder auch nur in einer Sicht. Die Enterprise-Portalarchitektur ist entsprechend auf die Möglichkei- ten der Integration von Backendsystemen hin zu untersuchen und zu befragen. Die Integra- tionsmöglichkeiten können hier durchaus stark variieren. So vertritt z.B. der im Jahr 2010 zum ersten Mal auf dem Gartner-Quadranten gelistete Anbieter Backbase einen deutlich leichtgewichtigeren Ansatz, als dies z.B. Anbieter wie SAP oder Oracle tun. Ein Unterneh- men muss sich unter Architekturgesichtspunkten die folgenden Fragen stellen: Wie wollen wir Applikationen in die Portalarchitektur integrieren und wie kann die Portalsoftware dabei unterstützen? Alle weitergehenden Konzepte bezüglich der Konnektivität von Anwendungen, dem Messaging & Routing von Informationen, speisen sich aus der Antwort auf diese Fra- gen. Eine der wichtigsten Prämissen für die Entwicklung der Portalarchitektur muss sein, dass möglichst keine Business-Logik im Portal nachgebaut bzw. parallel implementiert wer- den sollte, sondern dass stets ein Weg zur möglichst abstrakten und einheitlichen Integration von logikführenden Backend- und Legacysystemen gewählt wird.

3.3.2 Administration

Unter dem Stichwort Administration sind verschiedene spezialisierte Funktionen zusammen- gefasst, die es zum einen den Administratoren erlauben, das System von technischer Seite her zu konfigurieren, und zum anderen den verantwortlichen Fachanwendern alle Tools an die Hand zu geben, die Portalarchitektur „mit Leben“, d.h. mit Content zu füllen. Zur Unter- stützung der verschiedenen Anwendergruppen (Administratoren, Publishern, Autoren, spe- ziellen Autoren (z.B. aus der Produkt- und Shopredaktion) sind umfangreiche Cockpits und Toolboxes gefordert. Diese bedürfen oftmals einer recht umfangreichen Oberflächenintegra- tion. Eine moderne Portalarchitektur muss in der Lage sein, das Erstellen und Bereitstellen von spezifischen Cockpits einfach und ohne großen Aufwand (z.B. über standardisierte Pluglets o.ä.) zu unterstützen. Eine grundsätzliche Herausforderung für diese Dashboards ist, Inhalte und Applikationen verschiedenster Liefersysteme zusammenzufügen und zu- sammen auf einer Seite darzustellen. Hier sind unter Umständen Berechtigungsmixturen von unterschiedlichen klassischen Rollen nötig (z.B. zwischen Redakteur und Administrator).

Die Anbindung eines (oder mehrerer) Identity Management Systems, welches das Rechte- und Rollensystem unterstützt, ist für die Ausprägung von Cockpits unerlässlich, ebenso aber auch Grundvoraussetzung für die Umsetzung von AAA-Konzepten (Authentication, Authori- zation, Accounting) als zentraler Voraussetzung für SSO und die Personalisierung.

Außerdem spielt in diesem Kontext eine Suchmaschine eine zentrale Rolle, welche sowohl in der Lage sein muss, die Frontendsuche für die User (Reader) des Portals abzubilden als auch Drittsysteme anzubinden. Ein Großteil der Cockpits für Administratoren und Fachan- wender ist meist Query-gesteuert. In Zukunft werden sicherlich immer mehr Anwendungen in Portalen auf Basis von Enterprise-Search-Abfragen umgesetzt werden (siehe auch Search Engine Optimization (SEO), User Engagement, Collaboration & Feedback). Die Themen Enterprise Search und Identity Management sind mit Portalbordmitteln definitiv nicht seriös zu lösen, sondern bedürfen der Integration und dem Abgleich mit der Search- und IDM- Strategie eines Unternehmens.

Entwicklung ganzheitlicher Portalarchitekturen

Die meisten Portalanbieter bieten WCM (Web Content Management) Usecases und Funkti- onen (Redaktionsprozesse, „What you see is what you get“, WYSIWYG-Editor etc.) out-of- the-box an bzw. integrieren WCMS-Standardkomponenten. Die zentrale Frage muss hier sein, welche Funktionen von der Standardsoftware unterstützt und welche durch die Fachab- teilung erwartet werden? Ist das Delta hier zu groß, muss eine WCMS-Standardlösung in die Portalarchitektur integriert werden. Ähnliches gilt für die Anforderungen an Dokumentmana- gement-Funktionen (DMS), die Verwaltung von Digital Assets (DAM) wie Bildern sowie an Social Media (siehe oben). Hier werden durch die Portalanbieter oft einfache Funktionen angeboten, welche geprüft und anhand der Fachanforderungen abgewogen werden müs- sen. Meist bieten Portalsoftwareanbieter aber auch unterstützte Schnittstellen zu Partner- produkten und Spezialanbietern an.

Die Anbindung eines CRM-Tools (Customer Relationship Management) an die Portalarchi- tektur ist gerade in Internet- und Extranet-Szenarien sehr sinnvoll, um spezifische Inhalte und Produkte für spezifische Kunden- und Kundengruppen bereitzustellen. Schließlich er- möglicht ein CRM-Tool die Auswertung des Nutzerverhaltens. Daneben kann die Verwaltung spezifischer Kundendaten (z.B. Stammdaten wie Rechnungsadresse, Lieferadresse, Famili- enstand etc.) ausgelagert werden: in Form eines Self-Service-Angebots an die Kunden.

Spezifischer gestaltet sich die Anbindung von Product Information Management Tools (PIM). Diese sind oftmals tief in Produktentwicklungs- und -launchprozesse sowie Stammdatenpro- zesse integriert, während das Portal fertige Kataloge und zentral gepflegte Stammdaten konsumiert. Da aber die Struktur der Kataloge und die Stammdaten oftmals eine explizite Auswirkung auf z.B. die Informationsarchitektur in den ausgelieferten Websites haben, sind PIM-Funktionen bzw. das Verbauen von aus PIM generiertem Content gerade in commerce- und produktlastigen Szenarien immanent. Dies gilt ebenfalls für klassische Commerce- Anwendungen, obwohl diese oftmals auch mit Portal- und WCMS-Funktionen angereichert vermarktet werden.

3.3.3

Transaction

Ein weiterer wichtiger Aspekt für eine Portalarchitektur ist die sichere und zuverlässige Un- terstützung von Transaktionen. Commerce-lastige Szenarien z.B. definieren komplexe Pro- dukte nicht nur auf der Basis eines Artikelstammpasses, sondern vielmehr als eine Aneinan- derreihung verschiedener, sich einander bedingender Prozessschritte mit z.B. spezifischen Angebote und Kalkulatoren für Kunden (z.B.: Rahmenverträge für spezifische Produkte), Verfügbarkeitsprüfungen (z.B.: Produkt auf Lager, Produkt regional verfügbar), komplexen Produktabhängigkeiten (z.B. Ersatzteilbestellungen, Service Upgrades) und der Anbindung an die Backendsysteme, in denen Orders dann prozessiert werden (Produktion, Logistik und Rechnungslegung). Klassische Commerce-Systeme bringen für die Erfüllung solcher Anfor- derungen eigene Workflowengines mit. Eine Portalarchitektur kann mit bordeigenen Mitteln unterstützen bzw. eine Integration in eine Business Process Engine anbieten. Die Grundfra- ge, die sich mit Blick auf die Portalarchitektur stellt, ist, in welcher Komplexität und Speziali- sierung Transaktionen mithilfe der Software abgewickelt werden können. Andernfalls muss eine Spezialsoftware angebunden werden.

Entwicklung ganzheitlicher Portalarchitekturen

4 Die Portalarchitektur als Investition in die Zukunft

Portalprojekte und -initiativen entstehen in einem Spannungsfeld zwischen agilen Fachan- forderungen und relativer Statik von IT-Systemen. Der nachhaltige Erfolg von komplexen Portalszenarien ist von unterschiedlichen Faktoren abhängig und aktiv beeinflussbar.

Organisatorisch
Organisatorisch

Content- & Applikations-Verteilung sowie Wiederverwendung

Governance & Guidelines (funktional & technisch) für Content & Applikationen

Fachlicher Support & Betrieb (z.B. SLAs, Verrechnungskonzepte, „Application Store“)

Transparentes Anforderungsmanagement & Roadmap

Funktional
Funktional

Unterstützung lokaler Geschäftsanforderungen (z.B. Applikation mit Relevanz für nur eine anwendende Einheit, “kleine” Sites etc.)

Design wieder verwertbarer Services, Funktionsbausteine und Applikationen

Integrierte Redaktion für Web Content und Applikationen in einem Workflow

Technisch
Technisch

Holistische Betrachtung der technischen Infrastruktur

Support von Agilität durch Modularität & Wiederverwendung

Abstraktion der Frontend- und Layout-Entwicklung vom Backend

Adaption auf dezentrales Look & Feel und Einmischen von lokalem Content

Quelle: Detecon International GmbH

Bild 4: Herausforderungen für die Entwicklung von Portalarchitekturen

Der wichtigste Schlüssel zum Erfolg einer Portalarchitektur sind klare Spielregeln zwischen der IT und den Fachabteilungen sowie ein gemeinsames Verständnis über die benötigten und gewünschten Portalkomponenten und Basisfunktionen und deren Korrelation zu den Fachanforderungen.

Eine Portalreferenzarchitektur ist die Basis für ein solches gemeinsames Verständnis und definiert ein gemeinsames Zielbild von Fachabteilung und IT. Sie fungiert als zentrale Biblio- thek der Portalservices und Referenzbeispiele, welche für Implementierungsprojekte zur Verfügung stehen. Außerdem beschreibt die Portalreferenzarchitektur die spezifischen Whi- tespots in der IT-Bebauung. Anhand der Portalreferenzarchitektur können Anforderungen konkret diskutiert und Abhängigkeiten transparent gemacht werden. Die Portalreferenzarchi- tektur bildet die Basis für die Abstimmung und Kommunikation mit den Fachbereichen und für die Erstellung einer Roadmap zur Entwicklung eines oder mehrerer Portale.

Des Weiteren muss sich die Portalarchitektur möglichst leichtgewichtig darstellen. Entspre- chend der Prämisse der „Seperation of Concerns“ darf keine Businesslogik in die Portale implementiert werden, Business Logik muss eine Portalinfrastruktur aus den Backendsyste- men als Services konsumieren, aggregieren und nach außen repräsentieren. Last but not least bedient die Entkopplung des Presentation Layers von den Entwicklungs- und Deploy- mentprozessen des Portalbackends die Fachabteilungen mit der dringend benötigen Agilität und Flexibilität.

Grundsätzlich ist die Bereitstellung einer sauberen und modularen Portalarchitektur sowohl eine Investition zur Unterstützung aktueller Geschäftsbedürfnisse als auch zur Unterstützung zukünftiger Anforderungen durch schon bestehende Implementierungen. Dadurch erhöht sich die Sicherheit der Investitionen in Software und Customizing deutlich.

5 Der Autor

Entwicklung ganzheitlicher Portalarchitekturen

Steffen Roos ist bei Detecon in der Competence Practice IT Management in Bonn als Ma- naging Consultant tätig. Seit über 10 Jahren ist er im Kontext von komplexen Implementie- rungsprojekten von Portalen aktiv. Zur Detecon kam er im Jahre 2010. Mit seiner prakti- schen Erfahrung aus zahlreichen Portal-Projekten hat er ein breites Wissen sowohl in der Analyse und Konzeption von unterschiedlichen Unternehmensportalsystemen als auch in deren Implementierung und Rollout.

Er ist erreichbar unter: +49 228 700 1905 oder steffen.roos@detecon.com

6 Das Unternehmen

We make ICT strategies work

Entwicklung ganzheitlicher Portalarchitekturen

Detecon ist ein Beratungsunternehmen, das klassische Managementberatung mit einem hohen Technologieverständnis vereint.

Unsere Unternehmensgeschichte beweist dies: Detecon International ging aus der Fusion der 1954 gegründeten Management- und IT-Beratung Diebold und der 1977 gegründeten Telekommunikationsberatung Detecon hervor. Unser Leistungsschwerpunkt besteht dem- nach in Beratungs- und Umsetzungslösungen, die sich aus dem Einsatz von Informations- und Kommunikationstechnologien, engl. Information and Communications Technology (ICT), ergeben. Weltweit profitieren Kunden aus nahezu allen Branchen von unserem ganzheitli- chen Know-how in Fragen der Strategie und Organisationsgestaltung sowie beim Einsatz modernster Technologien.

Das Know-how der Detecon bündelt das Wissen aus erfolgreich abgeschlossenen Manage- ment- und ICT-Beratungsprojekten in über 160 Ländern. Wir sind global durch Tochter- und Beteiligungsgesellschaften sowie Projektbüros vertreten. Detecon ist ein Tochterunterneh- men der T-Systems International, der Geschäftskundenmarke der Deutschen Telekom. Als Berater profitieren wir daher von der weltumspannenden Infrastruktur eines Global Players.

Know-how und Do-how

Die rasante Entwicklung von Informations- und Telekommunikationstechnologien beeinflusst in immer stärkerem Maße sowohl die Strategien von Unternehmen als auch die Abläufe innerhalb einer Organisation. Die daraus folgenden komplexen Anpassungen betreffen dementsprechend nicht nur technologische Anwendungen, sondern auch Geschäftsmodelle und Unternehmensstrukturen.

Unsere Dienstleistungen für das ICT-Management umfassen sowohl die klassische Strate- gie- und Organisationsberatung als auch die Planung und Umsetzung von hochkomplexen, technologischen ICT-Architekturen und -Anwendungen. Dabei agieren wir herstellerunab- hängig und sind allein dem Erfolg des Kunden verpflichtet.

Detecon International GmbH Oberkasselerstr. 2 53227 Bonn Telefon: +49 228 700 0 E-Mail: info@detecon.com Internet: www.detecon.com