Enterprise Information Architecture (EIA) - Roadmap

Seit einem Jahr beschäftigt mich, im Rahmen der Anforderungs-Analyse für unsere Solution/Digitales Produkt, auch immer stärker das Thema Enterprise IA.

Die Gründe dafür sind vielschichtig wie z.B. Workflow-Optimierungen, Abbau von Content Silos, Sozial Aspekte, Innovation Management und natürlich (z.T. indirekt) auch Produkt-Verbesserungen. Denn wer kennt das nicht, dass man erst einmal intern Verbesserungen bei den Informationsflüssen herbeiführen muss, um in weiteren Schritten die optimalen Grundlagen für eine innovative Produkt-Entwicklung (Requiremants Analyse/Management, Konzeption) zu ermöglichen. Das ist ein allgemeines Muster in vielen Unternehmen.

Wer sich auf diesem Gebiet einen großen Namen gemacht hat, quasi der "EIA-Erfinder" ist natürlich Lou (Louis Rosenfeld). Erst kürzlich fand ich auf seiner site ein Update seiner "Enterprise IA Roadmap".
Darüber würde ich gerne demnächst einmal eine Präsentation halten oder einen Workshop durchführen.

Projektnotizen - Enterprise Search, Beratung & Spezifikation (D)

Die Enterprise Search ist ein spannendes Tätigkeitsfeld für uns Informationsarchitekten. Ich merke, dass dieses Thema (Stichwort: SEO) im Rahmen meiner Projekte einen nun immer wichtigeren Stellenwert bekommt. Und ich freue mich sehr auf genau diese Herausforderungen.
Vor einiger Zeit war ich an einem klassischen "Search & Findability"-Projekt beteiligt, aus dem ich mir auch einige wichtigen Erkenntnisse für zukünftige Projekte mitnehmen konnte.

Zum Projektverlauf
Die Auffindbarkeit von Informationen im System war Kern dieses umfangreichen Projektes, in dem eine Spezifikation als Zwischenergebnis vor der Umsetzung zu erstellen war. Ich unterstützte das Projekt in der Beratung, über die Kundenpräsentation mit Workshops, hin zur Spezifikation.

Beratung, Spezifikation
Bereits während der ersten Kunden-Beratungen wurde mir klar, dass die Suche eine Herausforderung an die Vermittlung zwischen dem Business Scope, den User Requirements und dem späteren System-Anforderungen stellen würde. Diese Komplexität möglichst früh zu kommunizieren war ausschlaggebend für den Projekt-Erfolg.
(1.) Der Kunde wünscht sich eine Suche à la Google (die "Spitze des Eisbergs" also), (2.) die Anwender benötigen eine intuitive Führung durch ihren gesamten Such-Prozess und nicht zuletzt sind (3.) die Anforderungen an das jeweilige System ausschlaggebend dafür, was letztlich umgesetzt werden kann, im Rahmen des Projekt(-Budgets).
Ein abstraktes Concept Model half uns, das Konzept der Suche kommunizierbar und greifbar zu machen. Wichtig war dabei zum Beispiel, den Stellenwert der Contribution transparent darzustellen. Denn genau in diesem Teil des Konzeptes müssen die wichtigen Funktionalitäten integriert sein, welche später zur Auffindbarkeit von Informationsobjekten (Findability) beitragen.
Nachdem wir es erfolgreich unterstützten, dass sich darauf alle Stakeholder commiten können, konnten wir nun mit gutem Gefühl auf detaillierterer Ebene spezifizieren.

Wir spezifizierten die Anforderungen für die Suche im Anschluss mit folgenden Methoden/Deliverables in einem Pflichtenheft:

• Concept Model
• Wireframes (start search, search results, contribution, ...)
• Use Cases
  
• Taxonomie
• Meta Schema
• Datenmodell
  

Learnings
- Die Wahl der richtigen Kommunikation ist sehr ausschlaggebend für den Projekt-Erfolg: Da wir es hier mit dem klassischen "Eisberg"-Prinzip zu tun hatten (d.h. Kunde wünscht sich: "Implementierung eines Suchfeldes mit allen erdenklichen Suchqualitäten"), war es von höchster Wichtigkeit, dass wir dem Kunden auch alle dahinterliegenden, ausschlaggebenden Faktoren für den späteren Projekterfolg aufweisen konnten. Ich entschied mich zur Erstellung eines Concept Modells, welches auf einfache, abstrakte und narrative Weise kommuniziert. Dies muss jedoch nicht in jedem Projekt die geeignete Kommunikations-Methode sein.

- User Requirements: Die tendieren dazu, den Projektrahmen zu sprengen, wenn sie in vollem Umfang im Rahmen eines einzigen Projekts berücksichtigt werden. Es ist daher ratsam, diese in functional und future requirements zu trennen.

- Search Strategie: Da Suche generell im Rahmen einer langfristigen Such-Optimierung laufen sollte, macht es viel Sinn, dafür ein Strategie-Modell zu entwickeln und dieses in den Projekt-Versionen oder iterativen Projekt-Prozesse zu berücksichtigen.

Mich beschäftigt gerade ein noch tieferes SEO-Thema und werde daher bald schon wieder an genau dieser Stelle anknüpfen...

Mich interessiert: Was verbindest Du mit dem Thema Enterprise Search?

IA Methode - Flowchart/Process Flow (D)

(Bild-Quelle: Wolf H. Nöding Spirit Link, Mezzoblue)

Was ist ein Flowchart/Process Flow?

Darstellung eines abstrakten Ablaufdiagramms (Flow Chart) für ein Informationssystem. Die Grundelemente der Beschreibung sind die Operation(Process), Entscheidung, Dokument, Data, Start/Stop, Unterprogramm. Vier unterschiedliche Arten von Flow Charts haben sich im Rahmen der Prozess Analyse etabliert:

• Top-Down Flow Chart
• Detaillierter Flow Chart
• Workflow Diagramm
• Development Chart
  

Informationsarchitekten nutzen Flow Charts in der frühen Entwicklung für Prozessfluss Analyse, Conceptual Models und Screen Flows.

Welchen Nutzen hat es?

Es unterstützt die Kommunikation, speziell das gemeinsame Verständnis, über ein Projekt oder ein Prozess zwischen allen Stakeholdern. Sie eignen sich sehr gut zur Dokumentation von Prozessen und oft nützlich beim Verständnis, wie unterschiedliche Schritte eines Prozesses zusammenarbeiten.
Die konzeptionellen Modelle und Screen Flows, auf welche man sich geeinigt hat, sind Grundlage für die Beschreibung der Anwendungsfälle(Use Cases).

IA Solution - Topic Map (D)

(Bild-Quelle: TAO of Topic Maps, Omnigator, NetworkedPlanet, )

>> Are Halland erwähnt u.a. Topic Maps in seinem Interview bei IA Voice.

Was ist eine Topic Map?
Ein abstraktes Modell zur Entwicklung und Darstellung von Wissensstrukturen (speziell auch z. Formulierung f. Ontologien o. als Semantik Web Agent) im Kontext von Wissensmanagement. Das Topic Map Paradigma (ISO Standart seit 1999) basieren auf den drei Grundelementen Topics, Associations und Occurrences (TAO). Die Hautgegenstände/-Themen in einer Topic Map werden als Topics beschrieben. Associations (Assoziierungen) stellen die relevanten Beziehungen zwischen den Topics dar, und die mit externen Dateien verbundene Dokumente (und Webseiten) als Occurrences.

Welchen Nutzen hat es?
Unterstützung unzähliger Business Anforderungen, nach welchen in großen Informationslandschaften relevante Informationen zur Unterstützung einer besseren Collaboration dienen sollen. Topic Maps liefern folgende Vorteile:
- Die Darstellung und Nutzung von zunehmend komplexen Informationsstrukturen.
- Visualisierungen von Topic Maps mit Hilfe intuitiver Navigationen
- Nach Scope gefilterte Inhalte in semantischen Netzwerken
- Effiziente Suche - Darstellung von Suchergebnissen in relevanten Kategorien.
- Customizing der unterschiedlichen Darstellungen
- Ermöglicht die Indexierung von Dokumenten zur Unterstützung der späteren Findability(Aufindbarkeit).

Links:
- TAO of Topic Maps
- Ontopia
- NetworkedPlanet
- Topic Maps Wikipedia

IA Methode - Use Cases (D)

(Bild-Quelle: IBM Developers, IAI concept Wolf H. Nöding)

Was ist ein Use Case?

Die Definition eines Anwendungsfalls(Use Case Diagramm, Use Case Schablone) zwischen dem Anwender (User) und dem System. Im Hauptteil des Use Case wird in einem "typischen Szenario" die Interaktion beschrieben, welche zwischen dem Akteur und System abläuft, um ein bestimmtes Ziel (User/Business goal) zu erreichen. Ein Use Case wird in folgenden Informationen strukturiert: UC Name, Ziel, Akteur(e), Systemkontext, Abstraktions-Level, Auslöser, Vorbedingungen, Ergebnis, Notizen, das typische Interaktions-Szenario (zw. Anwender und System), Ausnahmen.

Welchen Nutzen hat es?

Bestandteil einer System-Spezifikation, mit welcher die Interaktion des Anwenders mit dem System, in unterschiedlicher Granularität, dokumentiert wird. Use Cases unterstützen als
Kommunikations-Grundlage die Abstimmungs-Prozesse zwischen den unterschiedlichen Projekt-Stakeholdern(Kunde, User, Inhouse Team, Entwickler, ...).

Links:
- Wikipedia
- IBM Developers

IA Institute website concept - Part I (E)

(Image: Method - Global Mental Model, Wolf H. Nöding)

Since the launch party of the new IA Institute website at this years IA Summit in Las Vegas 2007 I was asked quite often from people how the concept deliverables of the new website look like. Well, here we start with describing some main steps of development.

Note: I was told from people of the IAI Community that they used this Global Mental Model as a communication tool with their clients very successfully already. And a while ago I was asked by James Kalbach to write a brief method description of this Global Mental Model for his upcoming book where he mentions this method briefly which I developed during the conceptional phase for the IA Institute website.

The following is a short description of the method:
-----------------------------------------------------------------------------------------------------------

High level Mental Model

Short description of a Diagram that's part of the concept for the IA Institute website.

As one part of a concept for the IA Institute website the diagram shows an abstract(higher level) mental model. With it's molecular like appearance this model presents the main tasks of the website(arranged on middle circle) in it's Top Down and Bottom up stakeholder context.

The goal - create communication base

The general goal here was to deliver a complete(global) scenario with its strongest leverages, relations(active and passive) and POIs (Point of interests). Business goals and requirements as well as user requirements will be able to be discussed, based on this overall scenario.

Method - process of development

The input for the diagram results from surveys and interviews with IA members(US and Europe) and was first clustered in a mindmap. According to the given information the diagram is developed and growing iteratively based on all important relations (visualised as active/passive and less/strong demand arrows ). A variety of keys indicate relations like:

• one way/two way relations
• active/passive
• Top-Down, Bottom-Up
• strong Demand
• regular focus
• strong focus
• sub case

There is an active/passive relation between “Contribute” and “Find IA information” for example. This indicates that the contribution of documents is related to their findability and therefore can actively support the process.
The strong relation between Contribution and Collaboration indicates a higher amount of requirements which address the relation between them.

The complete diagram finally reflects the given input during the information gathering process e.g. interviews and surveys. In the continuing concept workflow the diagram is used as an information source to develop detailed use cases and wireframes. Until the final launch it’s also always useful to support the iteration steps including optimisations and fine tunings as a “consulting” document.

Consolidated findings

• Useful to receive an awareness over the complex relation scenario of the website
• The scenario is global and should therefore be complete.
• As an information visualisation it’s valuable for communication purposes between team participants.
• Using an abstract model like this it’s necessary that all concept team participants have a sense for abstract thinking. This might not always be the case.

Your feedback is very welcome, Wolf

User Centered Design - Workshop at Namahn (E)

(Images UCD Solutions: Namahn)

Related to this article:
Listen to: Podcast at IA Voice with Joannes Vandermeulen (Namahn Founder and head of business development)

I was invited recently to participate in a two days workshop, led by Tom Stevens, at the Namahn agency in Brussels. While I know already quite a bit about User Centered Design, Usability and IA I still learned a lot more about solutions and methods to solve Business Pains in this two days master class.









The following topics were learned to the master class participants:

• User Centered Design as a discipline
  

The UCD process:

• Field Study
• Personas
• User Requirements/Use Cases
• Scenarios of Use
• Conceptual Model
• Conceptual Design
• Mock-up
• Graphic Design
• Usability Test
• Detailed Specification/ Style Guide
  

After the UCD process the class learned even more about the development process and the ROI which was important to know in order to use and implement these methods in the daily project workflows. Alltogether I'd recommend this master class to all people who are interested in the IA and UCD methodology.

What do you think about the UCD process?

IA Methode - Business Requirements Analyse (D)

(Bild-Quelle: Entwurf "Business Analyse Modell" Wolf H. Nöding)

Was ist eine Business Requirements Analyse?
Im Rahmen einer Business Requirements Analyse werden die Anforderungen aus der Geschäftssicht auf eine (IT-)Lösung ermittelt. Die Informationen werden in Interviews(häufig genutzt), in Befragungen, mittels Fragebogen und durch Beobachtungen gesammelt. Bei der Formulierung der Anfo rderungen ist auf die folgenden requirement-typischen Eigenschaften zu achten - sie sollten... :

• vollständig
  
• messbar
• unmissverständlich/eindeutig
• nachweisbar
• priorisiert ...sein.

Im Kontext der Requirements Analyse wird auf eine Differenzierung zwischen Requirements und globalen Zielen, Anwendungsbereich und der Strategie wert gelegt.

Welchen Nutzen hat es?
Eine Dokumentation (in Form eines Requirement Mapping, Requirement Tabelle o.ä.), welches priorisierte Anforderungen an die Lösung aus der Geschäfts-Sicht beschreibt.