Communication of Enterprise Architectures
Beispiele in denen Architekturbeschreibungen verwendet werden können: -Analyse von alternativen Architekturen -Kommunikation zwischen Organisationseinheiten -Input für unterlagerte Architekturen -Planung und Budgetierung
Bei all diesen Punkten spielt Kommunikation eine essentielle Rolle. Weiter gedacht ist "system development" ein Wissenstransformationsprozess, wobei die Kommunikation das Mittel zum Zweck darstellt. Defnition System development community: a group of objects, such as actors and representations, which are involved in the development of a system. Defintion Concern: an interest of a stakeholder with regards to the architecture description of some system, resulting from the stakeholder’s goals, and the present or future role(s) played by the system in relation to these goals.
Einige Beispiele für "Concerns" sind: -Die Anforderungen eines Stakeholders -Verbesserungen, welche durch die Einführung eines neuen Systems greifen.
Das Wissen, welches durch eine "system development community" erarbeitet und ausgetauscht wird, lässt sich in folgende Kategorien strukturieren: Perspektive: Systeme können aus verschiedenen Blickwinkeln betrachtet werden. Gleichbedeutend mit Viewpoint. Scope: Reichweite (Bspw. enterprise-wide, department-wide, etc.) Design chain: Besteht aus Purpose, Functionality, Design, Quality, Costs. Weiterhin gibt es noch "Historical perspective" und "abstraction level".
Explicitness of Knowledge
In der Umgebung des "knowledge managements" gibt es eine grundlegende Unterscheidung von Wissen, zum einen in "explicit knowledge" und "tactic knowledge". "Explicit knowledge" kann sehr gut dargestellt werden, bspw. durch eine Architektur. (Schwerpunkt des Buches) "Tactic knowledge" hingegen kann schlecht durch reine Theorie verstanden werden. Bspw. das Fahrradfahren muss praktisch erlernt werden durch try and error.
Aufgrund dieser Klassifizierung können für "explicit knowledge" weitere Faktoren aufgestellt werden: Formality: Formelle oder informelle Sprache Quantifiability: Ausgedrückt durch Kapazität, Aufwand, Ressourcen, etc. Executability: Ausführbarkeit von Wissen durch Simulation, einen Prototypen, Animation, etc. Comprehensibility: Verwendung von Präsentationstechniken zur schrittweisen Verdeutlichung des Wissens. Completeness: Die Repräsentation des Wissens kann "complete", "incomplete" oder "overcomplete" sein.
Transformation of Knowledge
Durch das Lernen, Experimentieren, Weiterentwickeln wird immer neues Wissen aufgebaut und weiterentwickelt. Dieses Wissen wird in einer Gemeinschaft weitergegeben. Hierfür gibt es drei Kategorien: -Aware: Eine Person wird sich der Verfügbarkeit von Wissen gewahr durch die Wissensteilung durch eine andere Person. -Agreed: Nachdem das Wissen geteilt wurde, kann die Person entscheiden, ob sie dieses Wissen annimmt und zustimmt (agree) oder nicht. -Committed: Nach der Zustimmung wird sich auf ein gemeinsames zukünftiges Verhalten geeinigt.
Conversation Strategies
Kommunikation ist unerlässlich für das Entwerfen von Architektur. Basierend auf einem Ziel, einem initialen Wissensstand, sowie der Situation der Kommunikation muss hieraus eine "conversation strategy" abgeleitet werden, um möglichst effizient zu Arbeiten. Eine Gesprächsstrategie deckt im optimal Fall die folgenden Punkte ab: Execution plan: Eine Unterhaltung kann aus mehreren Subunterhaltungen bestehen, welche lediglich ein Subziel behandeln. Das Gesamtziel darf nie außer Acht gelassen werden. Description languages: Welche Sprach genutzt werden soll. Media: Welche Hilfsmittel werden eingesetzt. Cognitive mode: Die Art wie Informationen gesammelt werden sollen (analytisch oder experimentell) Social mode: Die Art, auf welcher mit anderen Gesprächsteilnehmern zusammengearbeitet wird. (Expert-driven, Participatory)
Knowledge Goals
Wie bei der "commuication knowledge" gibt es auch bei den "knowledge goals" eine Kategorisierung: -Introduction of knowledge (Trainings) -Agreement to knowledge (Einigung der Stakeholder) -Commitment to knowledge (Stakeholder arbeiten nach den Zusagen)
Conversation Strategies
Brown-paper session: Typisches Brainstorming mit PostIt's. Gedanken werden strukturiert und kategorisiert.
Elicitation interview: Klassisches Interview. Der Interviewer versucht durch Fragen an Informationen zu gelangen.
Workshop: Klassischer geführter Workshop. Mitarbeit durch Teilnehmer an einem Modell, sodass direkt Feedback eingearbeitet werden kann.
Validation interview: Kleiner als ein "elication interview". Informationen sind bereits bekannt und in einem Modell vorhanden. Diese Informationen werden durch die Interviewpartner gespiegelt und geprüft.
Committing review: Stakeholder entscheiden sich zwischen mehreren Vorschlägen und committen sich darauf.
Presentation: Typische Präsentation (Front-Beschallung).
Mailing: Massenkommunikation um ein Modell vorzustellen oder zu übergeben.
Eine Übersicht bietet das folgende Bild (vgl. Buch:Enterprise Architecture at work).
