Chapter 4Communication of Enterpris

Chapter 4
Communication of Enterprise Architectures
This chapter presents a communication perspective of enterprise architectures. We
provide both a theoretical and a practical perspective of the issues involved in the
communication of enterprise architectures. The general idea is that the chapter
helps the reader see how architecture development and modelling can be optimally
supported by discussing why certain forms of modelling are used in some situation
and how this fits the goals in the process. The theoretical perspective will focus on
communication during system development in general, where the word system
should be interpreted as any open and active system, consisting of both human
and computerised actors, that is purposely designed. The practical perspective will
take shape as a set of practical guidelines that should aid architects in the selection
and definition of architecture description approaches that are apt for a specific
(communication) context.
4.1 Introduction
Describing architectures is all about communication. If some architecture description
is not used as a means of communication in some shape or form, then this
description should not have been created in the first place. Whatever the role of
an architecture description is, it always involves some communicative aspect.
Consider, as an illustration, the potential uses of architecture descriptions as
identified in the IEEE 1471 standard (IEEE Computer Society 2000):
– Expression of the system and its (potential) evolution.
– Analysis of alternative architectures.
– Business planning for transition from a legacy architecture to a new architecture.
– Communications among organisations involved in the development, production,
fielding, operation, and maintenance of a system.
– Communications between acquirers and developers as a part of contract
negotiations.
M. Lankhorst et al., Enterprise Architecture at Work, The Enterprise
Engineering Series, DOI 10.1007/978-3-642-29651-2_4,
# Springer-Verlag Berlin Heidelberg 2013
61
– Criteria for certifying conformance of implementations to the architecture.
– Development and maintenance documentation, including material for reuse
repositories and training material.
– Input to subsequent system design and development activities.
– Input to system generation and analysis tools.
– Operational and infrastructure support; configuration management and repair;
redesign and maintenance of systems, subsystems, and components.
– Planning and budget support.
– Preparation of acquisition documents (e.g., requests for proposal and statements
of work).
– Review, analysis, and evaluation of the system across the life cycle.
– Specification for a group of systems sharing a common set of features, (e.g.,
product lines).
Each of these uses of architecture involves forms of communication. In this vein,
in this chapter we present a ‘communication-aware’ perspective of enterprise
architectures. In doing so, we provide both a theoretical and a practical perspective
of the issues involved in the communication of enterprise architectures. The
theoretical perspective will focus on communication during system development
in general, where the word system should be interpreted as any open and active
system, consisting of both human and computerised actors, that is purposely
designed. The practical perspective will take shape as a set of practical guidelines
that should aid architects in the selection (and definition) of architecture description
languages and approaches that are apt for a specific (communication) situation.
Architecture descriptions are used to communicate the architecture of a planned
or pre-existing system. This could be a system that is part of an enterprise, an
organisation, a business, an information system, a software system, or the hardware
infrastructure. The communication about the system and its architecture is likely to
take place between different stakeholders of that system.
In this book, the primary focus is on architectural models of a graphical (as
opposed to textual or verbal) nature. One may refer to these as architectural models
‘in the narrow sense’. In this chapter, however, we are concerned with architecture
descriptions in ‘the broader sense’. In other words, textual, verbal, or any other
types of architecture descriptions are included.
At present, many description languages are already available to architects, while
many more are being created by both academia and industry. Why all these
languages? How does one select the language that is most apt in a given situation?
Such questions beg for a well-conceived answer. In line with the old adage ‘practice
what you preach’, we argue that just as proper requirements engineering is needed
for the development of systems, proper requirements should also be formulated for
languages and approaches that are to used as vehicles for communication during
system development. In formulating these requirements, several factors should be
taken into account, such as the development goals, the communication goals, the
concerns, personal goals, abilities, and attitudes of the actors involved, etc.
62 4 Communication of Enterprise Architectures
We set out to provide a theoretical underpinning of the issues involved, as well
as practical guidelines that will aid architects in selecting the best approach for their
architectural communicative needs. We will therefore start out with a theoretical
exploration of the issues involved in communication during system development
(Sects. 4.2 and 4.3), followed by the application of this exploration to the field of
enterprise architecture (Sect. 4.4).
4.2 System Development as a Knowledge Transformation
Process
In essence, we regard system development as a knowledge transformation process
whereby conversations are used to share and create knowledge pertaining to both
the system being developed, as well as the development process itself. The notion
of ‘conversation’ should be interpreted here in the broadest sense, ranging from a
single person producing an (architectural) description, via a one-on-one design or
elicitation session, to a workshop with several stakeholders, and even the widespread
dissemination of definitive architectures. This way of thinking provides a
frame of thought with which one can better understand the (communicative)
requirements posed on architecture description languages.
4.2.1 System Development Community
Given our focus on communication, it is important to identify the actors that can
play a role in the communication that takes place during the system development
process. These actors are likely to have some stake with regards to the system being
developed. Examples of such actors are problem owners, prospective actors in the
future system (such as the future ‘users’ of the system), domain experts, sponsors,
architects, engineers, business analysts, etc.
These actors, however, are not the only ‘objects’ playing an important role in
system development. Another important class of objects are the many different
documents, models, forms, etc., that represent bits and pieces of knowledge
pertaining to the system that is being developed. This entire group of objects, and
the different roles they can play, is what we shall refer to as a system development
community.
System development community:
a group of objects, such as actors and representations, which are involved in
the development of a system.
4.2 System Development as a Knowledge Transformation Process 63
(We will clarify below why we regard documents as being part of the
community.)
The actors in a system development community will (typically as a consequence
of their stakes) have some specific interests with regards to the system being
developed. This interest implies a subinterest with regards to (the contents of) the
system descriptions that are communicated within the community. This interest, in
line with IEEE 1471 (IEEE Computer Society 2000), is referred to as the concern of
stakeholders
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.
Some example of concerns are:
– The current situation with regards to the computerised support of a business
process.
– The requirements of a specific stakeholder with regards to the desired situation.
– The improvements, which a new system may bring, to a pre-existing situation in
relation to the costs of acquiring the system.
– The potential impact of a new system on the activities of a prospective user.
– The potential impact of a new system on the work of the system administrators
that are to maintain the new system.
4.2.2 System Development Knowledge
The system development community harbours knowledge about the system being
developed. The communication occurring within a system development community
essentially is aimed at creating, furthering, and disseminating this knowledge.
Depending on their concerns, stakeholders will be interested in different knowledge
topics pertaining to the system being developed.
We will now briefly explore the kinds of knowledge that are relevant to a system
and its development; in other words, the knowledge topics that can be distinguished.
In the next subsections, we will discuss in more detail in what ways this
knowledge can be made (more) explicit.
During system development, members of the system development community
will create and exchange knowledge pertaining to different topics. We can make a
first distinction between the target domain pertaining to the system being developed
and the project domain, about the development process itself. We have borrowed
these terms from the Information Services Procurement Library (ISPL) (Franckson
64 4 Communication of Enterprise Architectures
and Verhoef 1999). For both of these knowledge domains, further refinements c

ผลลัพธ์ (ไทย) 1:

บทที่ 4สื่อสารขององค์กรสถาปัตยกรรมบทนี้นำเสนอสื่อสารมุมมองของสถาปัตยกรรมองค์กร เรามีทั้งเป็นทฤษฎีและมุมมองของปัญหาที่เกี่ยวข้องในปฏิบัติการการสื่อสารขององค์กรสถาปัตยกรรม ความคิดทั่วไปว่าบทช่วยให้ผู้อ่านดูวิธีพัฒนาสถาปัตยกรรมและแบบจำลองได้อย่างเหมาะสมโดยคุยทำไมบางรูปแบบของแบบจำลองที่ใช้ในบางสถานการณ์และวิธีนี้เหมาะสมกับเป้าหมายในการ มุมมองทฤษฎีจะเน้นสื่อสารในระหว่างการพัฒนาระบบในทั่วไป ระบบคำควรตีความเป็นการเปิด และใช้งานระบบ ประกอบด้วยบุคคลทั้งสองและนัก แสดงที่คอมพิวเตอร์ ที่ถูกจงใจออกแบบ มุมมองการปฏิบัติจะมีรูปร่างเป็นชุดของแนวทางปฏิบัติที่ควรช่วยสถาปนิกในการเลือกและคำนิยามของวิธีการอธิบายสถาปัตยกรรมที่สำหรับการพักผ่อนบริบท (สื่อสาร)4.1 บทนำอธิบายสถาปัตยกรรมคือการสื่อสาร ถ้าบางคำอธิบายสถาปัตยกรรมไม่ได้ใช้เป็นวิธีการสื่อสารในรูปร่างหรือรูปแบบ แล้วนี้คำอธิบายควรไม่มีการสร้างในสถานที่แรก บทบาทสิ่งของคำอธิบายสถาปัตยกรรมได้ มักจะเกี่ยวข้องกับด้านการสื่อสารบางพิจารณา เป็นภาพ ใช้เป็นคำอธิบายสถาปัตยกรรมเป็นระบุในแบบ IEEE ค.ศ. 1471 มาตรฐาน (IEEE คอมพิวเตอร์สังคม 2000):-ค่าของระบบและวิวัฒนาการของมัน (อาจ)– วิเคราะห์สถาปัตยกรรมอื่น-ธุรกิจการวางแผนสำหรับการเปลี่ยนจากสถาปัตยกรรมแบบดั้งเดิมกับสถาปัตยกรรมใหม่-ติดต่อสื่อสารระหว่างองค์กรที่เกี่ยวข้องกับการพัฒนา การผลิตfielding ดำเนินการ และบำรุงรักษาของระบบ-ติดต่อสื่อสารระหว่าง acquirers และพัฒนาเป็นส่วนหนึ่งของสัญญาเจรจาม. Lankhorst et al. สถาปัตยกรรมองค์กรที่ทำงาน องค์กรชุดวิศวกรรม ดอย 10.1007/978-3-642-29651-2_4# springer Verlag เบอร์ลินไฮเดลเบิร์ก 201361-เงื่อนไขสำหรับการรับรองความสอดคล้องกันของการใช้งานกับสถาปัตยกรรม-พัฒนาและบำรุงรักษาเอกสารประกอบ รวมถึงวัสดุสำหรับใช้ใหม่repositories และวัสดุฝึกอบรม– ป้อนเข้าระบบภายหลังการออกแบบและพัฒนากิจกรรมการ– ป้อนเข้าระบบการสร้างและวิเคราะห์เครื่องมือ-ดำเนินงาน และโครงสร้างพื้นฐานที่สนับสนุน จัดการการตั้งค่าคอนฟิกและการซ่อมแซมออกแบบและบำรุงรักษาระบบ ย่อย และส่วนประกอบ-วางแผน และงบประมาณสนับสนุน-เตรียมเอกสารการซื้อ (เช่น คำขอข้อเสนอและรายงานของงาน)-ตรวจสอบ วิเคราะห์ และการประเมินระบบในวงจรชีวิต-ข้อมูลจำเพาะสำหรับกลุ่มของระบบที่ใช้ร่วมกันคุณลักษณะ, (เช่น ชุดทั่วไปสายผลิตภัณฑ์)แต่ละเหล่านี้ใช้สถาปัตยกรรมเกี่ยวข้องกับรูปแบบของการสื่อสาร ในหลอดเลือดดำนี้ในบทนี้ เราแสดงมุมมอง 'สื่อสารตาม' ขององค์กรสถาปัตยกรรม ในการทำเช่นนั้น เรามีทั้งเป็นทฤษฎีและปฏิบัติมุมมองของปัญหาที่เกี่ยวข้องในการสื่อสารขององค์กรสถาปัตยกรรม ที่มุมมองทฤษฎีจะเน้นการสื่อสารในระหว่างการพัฒนาระบบทั่วไป ซึ่งระบบคำควรจะตีความ เป็นการเปิด และใช้งานอยู่ระบบ ประกอบด้วยนักแสดงทั้งมนุษย์ และคอมพิวเตอร์ ที่จงใจออกแบบมา มุมมองการปฏิบัติจะก่อตัวเป็นชุดของแนวทางปฏิบัติที่ควรช่วยสถาปนิกเลือก (และคำนิยาม) ของลักษณะสถาปัตยกรรมภาษาและแนวทางที่ฉลาดสำหรับสถานการณ์เฉพาะ (สื่อสาร)ใช้คำอธิบายสถาปัตยกรรมสถาปัตยกรรมวางแผนการสื่อสารหรือระบบที่มีอยู่ก่อน อาจเป็นระบบที่เป็นส่วนหนึ่งขององค์กร การองค์กร ธุรกิจ การระบบข้อมูล ระบบซอฟต์แวร์ หรือฮาร์ดแวร์โครงสร้างพื้นฐาน การสื่อสารเกี่ยวกับระบบและสถาปัตยกรรมของมีแนวโน้มที่จะเกิดระหว่างเสียแตกต่างกันที่ระบบในหนังสือเล่มนี้ โฟกัสหลักอยู่ในรูปแบบสถาปัตยกรรมของตัวแบบกราฟิกเป็นธรรมชาติตรงข้ามกับข้อความ หรือด้วยวาจา) หนึ่งอาจหมายถึงเป็นรูปแบบสถาปัตยกรรม'ในแคบความรู้สึก' ในบทนี้ อย่างไรก็ตาม เรามีความกังวลกับสถาปัตยกรรมคำอธิบายใน 'ความกว้าง' ในคำอื่น ๆ ข้อความ วาจา หรืออื่น ๆชนิดของคำอธิบายสถาปัตยกรรมได้ในปัจจุบัน คำอธิบายหลายภาษามีแล้วสถาปนิก ขณะที่มากจะถูกสร้างขึ้น โดย academia และอุตสาหกรรม เหตุทั้งหมดนี้ภาษา วิธีหนึ่งเลือกภาษาที่ฉลาดที่สุดในสถานการณ์ที่กำหนดหรือไม่คำถามดังกล่าวขอให้คำตอบดี conceived โดยดิฉันเก่า ' ฝึกคุณประกาศ ', เราโต้แย้งว่า เป็นความต้องการเหมาะสมเพียง วิศวกรรมจำเป็นต้องใช้สำหรับการพัฒนาของระบบ ความต้องการเหมาะสมควรยังจะถูกกำหนดสำหรับภาษาและวิธีที่จะใช้เป็นยานพาหนะสำหรับการสื่อสารระหว่างการพัฒนาระบบ ควรมีปัจจัยหลายอย่างใน formulating ข้อกำหนดเหล่านี้พิจารณา เช่นเป้าหมายของการพัฒนา การสื่อสารเป้าหมาย การข้อสงสัย เป้าหมายส่วนบุคคล ความสามารถ และทัศนคติของตัวแสดงที่เกี่ยวข้อง ฯลฯ62 การสื่อสาร 4 ของสถาปัตยกรรมองค์กรเรากำหนดให้ underpinning ทฤษฎีของประเด็นเกี่ยวข้อง เช่นเป็นแนวทางปฏิบัติที่จะช่วยสถาปนิกในการเลือกวิธีดีที่สุดสำหรับ พวกเขาสถาปัตยกรรมสื่อสารความต้องการ เราจะดังนั้นเริ่มต้น ด้วยตัวทฤษฎีการสำรวจปัญหาที่เกี่ยวข้องในการสื่อสารในระหว่างการพัฒนาระบบ(Sects. 4.2 และ 4.3), ตาม ด้วยการสำรวจนี้ประยุกต์ใช้กับฟิลด์ของสถาปัตยกรรมองค์กร (Sect. 4.4)4.2 พัฒนาระบบเป็นการแปลงความรู้กระบวนการในสาระสำคัญ จุติพัฒนาระบบเป็นกระบวนการเปลี่ยนแปลงความรู้โดยใช้บทสนทนาเพื่อแบ่งปัน และสร้างองค์ความรู้ที่เกี่ยวข้องทั้งการพัฒนาระบบ ตลอดจนกระบวนการพัฒนาตัวเอง แนวคิดของ 'การสนทนา' ควรจะตีความนี่ในการรับความรู้สึก ตั้งแต่การคนเดียวที่ผลิตมีคำอธิบาย (สถาปัตยกรรม) ผ่านการออกแบบแพ็คเกจ หรือเซสชัน elicitation ไปอบรมเสียหลาย และแม้แต่แพร่หลายการเผยแพร่สถาปัตยกรรมทั่วไป วิธีนี้ความคิดให้เป็นกรอบของความคิดด้วยที่สามารถเข้าใจการ (สื่อสาร)ความต้องเกิดในภาษาอธิบายสถาปัตยกรรม4.2.1 ระบบพัฒนาชุมชนให้มุ่งเน้นในการสื่อสาร จะต้องระบุนักแสดงที่สามารถมีบทบาทในการสื่อสารที่เกิดขึ้นในระหว่างการพัฒนาระบบกระบวนการ นักแสดงเหล่านี้มักจะมีเดิมพันบางอย่างเกี่ยวกับระบบการพัฒนา ตัวอย่างของนักแสดงดังกล่าวเป็นปัญหา นักแสดงที่มีแนวโน้มในการระบบในอนาคต (เช่นอนาคต 'ผู้ใช้' ระบบ), โดเมนผู้เชี่ยวชาญ ผู้ สนับสนุนสถาปนิก วิศวกร นักวิเคราะห์ธุรกิจ ฯลฯนักแสดงเหล่านี้ อย่างไรก็ตาม ไม่เพียง 'วัตถุ' เล่นมีบทบาทสำคัญในการพัฒนาระบบ คลาสที่สำคัญอื่นของวัตถุมีความแตกต่างกันเอกสาร รูปแบบ ฟอร์ม ฯลฯ ที่แสดงบิตของความรู้เกี่ยวข้องกับระบบที่ได้ถูกพัฒนาขึ้น ทั้งนี้กลุ่มของวัตถุ และบทบาทต่าง ๆ ที่พวกเขาสามารถเล่น คือ อะไรเราจะหมายถึงเป็นการพัฒนาระบบชุมชนระบบการพัฒนาชุมชน:กลุ่มของวัตถุ นักแสดงและนำเสนอ ซึ่งเกี่ยวข้องกับการพัฒนาระบบ4.2 ระบบพัฒนาเป็นกระบวนการของการแปลงความรู้ 63(เราจะชี้แจงด้านล่างทำไมเราถือเอกสารเป็นส่วนหนึ่งของการชุมชน)จะแสดงในชุมชนพัฒนาระบบ (โดยทั่วไปจะเป็นส่งผลต่อของเงินเดิมพันของพวกเขา) ได้ประโยชน์บางอย่างเฉพาะเกี่ยวกับระบบการพัฒนา Subinterest เกี่ยวกับ (ราย) หมายถึงดอกเบี้ยนี้จะคำอธิบายระบบที่สื่อสารภายในชุมชน นี้สนใจ ในบรรทัด มี IEEE ค.ศ. 1471 (IEEE คอมพิวเตอร์สังคม 2000), เรียกว่าความกังวลของมีส่วนได้เสียความกังวล:ความสนใจของทรรศนะเกี่ยวกับคำอธิบายสถาปัตยกรรมของระบบบางอย่าง ซึ่งเป็นผลมาจาก เป้าหมายของมาตรการ และปัจจุบัน หรืออนาคตบทบาทที่เล่น โดยระบบเกี่ยวกับเป้าหมายเหล่านี้ตัวอย่างของความกังวลคือ:-สถานการณ์ปัจจุบันเกี่ยวกับการสนับสนุนคอมพิวเตอร์ของธุรกิจกระบวนการ– ความต้องการของมาตรการเฉพาะเกี่ยวกับสถานการณ์ที่ต้องการ-ปรับปรุง ซึ่งระบบใหม่อาจนำ สถานการณ์ที่มีอยู่ก่อนในความสัมพันธ์กับต้นทุนของระบบได้-ผลกระทบของระบบใหม่ในกิจกรรมของผู้มุ่งหวัง-ผลกระทบของระบบใหม่ในการทำงานของผู้ดูแลระบบที่จะรักษาระบบใหม่4.2.2 ระบบพัฒนาความรู้ชุมชนพัฒนาระบบท่าเรือเชิงความรู้เกี่ยวกับระบบการพัฒนา การสื่อสารที่เกิดขึ้นภายในชุมชนพัฒนาระบบหลักมีวัตถุประสงค์ที่สร้าง furthering และเผยแพร่ความรู้นี้ความกังวลของพวกเขา เสียจะมีความสนใจในความรู้ที่แตกต่างกันหัวข้อที่เกี่ยวข้องกับระบบที่กำลังพัฒนาเราจะตอนนี้สั้น ๆ สำรวจชนิดของความรู้ที่เกี่ยวข้องกับระบบและการ พัฒนา ในคำอื่น ๆ ความรู้หัวข้อที่สามารถแตกต่างกันในส่วนย่อยถัดไป เราจะหารือในรายละเอียดว่าวิธีนี้รู้ได้อย่างชัดเจน (เพิ่มเติม)ในระหว่างการพัฒนาระบบ สมาชิกของชุมชนพัฒนาระบบจะสร้าง และแลกเปลี่ยนความรู้เกี่ยวกับหัวข้อต่าง ๆ เราสามารถทำการแรกความแตกต่างระหว่างโดเมนเป้าหมายที่เกี่ยวข้องกับระบบที่กำลังพัฒนาและโด เมนโครงการ เกี่ยวกับกระบวนการพัฒนาตัวเอง เรายืมเงื่อนไขเหล่านี้จากข้อมูลบริการจัดซื้อไลบรารี (ISPL) (Franckson64 การสื่อสาร 4 ของสถาปัตยกรรมองค์กรก Verhoef 1999) ในทั้งสองโดเมนเหล่านี้ความรู้ เพิ่มเติม refinements c

ผลลัพธ์ (ไทย) 2:

บทที่ 4
การสื่อสารขององค์กรสถาปัตยกรรมในบทนี้จะนำเสนอมุมมองของการสื่อสารของสถาปัตยกรรมองค์กร
เราให้ทั้งทางทฤษฎีและมุมมองในทางปฏิบัติของปัญหาที่เกี่ยวข้องในการสื่อสารของสถาปัตยกรรมองค์กร ความคิดทั่วไปคือบทที่จะช่วยให้ผู้อ่านดูวิธีการพัฒนาและการสร้างแบบจำลองสถาปัตยกรรมที่สามารถได้อย่างดีที่สุดได้รับการสนับสนุนโดยการอภิปรายว่าทำไมบางรูปแบบของการสร้างแบบจำลองที่ใช้ในบางสถานการณ์และวิธีการนี้เหมาะกับเป้าหมายในกระบวนการ มุมมองทางทฤษฎีจะมุ่งเน้นไปที่การสื่อสารในระหว่างการพัฒนาระบบโดยทั่วไประบบที่คำว่าควรจะตีความใดๆ ที่เป็นระบบเปิดและการใช้งานประกอบด้วยทั้งมนุษย์นักแสดงและคอมพิวเตอร์ที่ถูกออกแบบมาโดยมีจุดมุ่งหมาย มุมมองในทางปฏิบัติจะเป็นรูปเป็นร่างเป็นชุดของแนวทางปฏิบัติที่ควรช่วยสถาปนิกในการเลือกและความหมายของคำอธิบายวิธีการที่มีสถาปัตยกรรมที่เหมาะสำหรับการที่เฉพาะเจาะจง(การสื่อสาร) บริบท. 4.1 บทนำอธิบายสถาปัตยกรรมคือทั้งหมดที่เกี่ยวกับการสื่อสาร หากคำอธิบายสถาปัตยกรรมบางส่วนที่ไม่ได้ใช้เป็นวิธีการสื่อสารในรูปร่างหรือรูปแบบบางอย่างแล้วนี้คำอธิบายไม่ควรได้รับการสร้างขึ้นในสถานที่แรก ไม่ว่าบทบาทของคำอธิบายสถาปัตยกรรมเป็นก็มักจะเกี่ยวข้องกับบางแง่มุมการสื่อสาร. พิจารณาเป็นภาพประกอบการใช้ศักยภาพของรายละเอียดสถาปัตยกรรมที่ระบุไว้ในมาตรฐาน IEEE 1471 มาตรฐาน (IEEE สมาคมคอมพิวเตอร์ 2000): - การแสดงออกของระบบและมัน ( ที่อาจเกิดขึ้น) วิวัฒนาการ. - การวิเคราะห์ของสถาปัตยกรรมทางเลือก. - การวางแผนธุรกิจสำหรับการเปลี่ยนแปลงจากสถาปัตยกรรมมรดกให้กับสถาปัตยกรรมใหม่. - การสื่อสารระหว่างองค์กรที่เกี่ยวข้องในการพัฒนา, การผลิต, ฝ่ายการดำเนินงานและการบำรุงรักษาระบบ. - การสื่อสารระหว่าง acquirers และ นักพัฒนาเป็นส่วนหนึ่งของสัญญาการเจรจา. เอ็ม . Lankhorst, et al, สถาปัตยกรรมองค์กรที่ทำงานองค์กรวิศวกรรมซีรี่ส์ดอย10.1007 / 978-3-642-29651-2_4, # Springer-Verlag เบอร์ลินไฮเดลเบิร์ก 2013 61 - หลักเกณฑ์การได้รับการรับรองความสอดคล้องของการใช้งานสถาปัตยกรรม. - การพัฒนาและ เอกสารการบำรุงรักษารวมทั้งวัสดุที่นำมาใช้สำหรับเก็บและวัสดุการฝึกอบรม. - ป้อนข้อมูลเพื่อการออกแบบระบบที่ตามมาและกิจกรรมการพัฒนา. - ป้อนข้อมูลสู่รุ่นของระบบและเครื่องมือในการวิเคราะห์. - การสนับสนุนการดำเนินงานและโครงสร้างพื้นฐาน จัดการการตั้งค่าและการซ่อมแซม;. ออกแบบและการบำรุงรักษาระบบระบบย่อยและส่วนประกอบ - การวางแผนและการสนับสนุนงบประมาณ. - จัดทำเอกสารการเข้าซื้อกิจการ (เช่นการร้องขอสำหรับข้อเสนอและงบของการทำงาน). - รีวิวการวิเคราะห์และการประเมินผลของระบบทั่ว วงจรชีวิต. - สเปคสำหรับกลุ่มของระบบร่วมกันตั้งค่าทั่วไปของคุณสมบัติ (เช่น. สายผลิตภัณฑ์) แต่ละของการใช้งานเหล่านี้ของสถาปัตยกรรมที่เกี่ยวข้องกับรูปแบบของการสื่อสาร ในหลอดเลือดดำนี้ในบทนี้เรานำเสนอ 'การสื่อสารตระหนักถึง' มุมมองขององค์กรสถาปัตยกรรม ในการทำเช่นที่เรามีให้ทั้งทางทฤษฎีและมุมมองในทางปฏิบัติของปัญหาที่เกี่ยวข้องกับการสื่อสารของสถาปัตยกรรมองค์กร มุมมองทางทฤษฎีจะมุ่งเน้นไปที่การสื่อสารในระหว่างการพัฒนาระบบโดยทั่วไประบบที่คำว่าควรจะตีความใด ๆ ที่เปิดและการใช้งานของระบบที่ประกอบด้วยนักแสดงทั้งมนุษย์และคอมพิวเตอร์ที่จงใจออกแบบ มุมมองในทางปฏิบัติจะเป็นรูปเป็นร่างเป็นชุดของแนวทางปฏิบัติที่ควรช่วยสถาปนิกในการเลือก (และความหมาย) ของรายละเอียดสถาปัตยกรรมภาษาและวิธีการที่เหมาะสำหรับการที่เฉพาะเจาะจง(การสื่อสาร) สถานการณ์. รายละเอียดสถาปัตยกรรมที่ใช้ในการสื่อสารสถาปัตยกรรมของที่ การวางแผนหรือระบบที่มีอยู่ก่อน ซึ่งอาจเป็นระบบที่เป็นส่วนหนึ่งขององค์กรให้ที่องค์กรธุรกิจระบบสารสนเทศระบบซอฟแวร์หรือฮาร์ดแวร์โครงสร้างพื้นฐาน การสื่อสารเกี่ยวกับระบบและสถาปัตยกรรมที่มีแนวโน้มที่จะเกิดขึ้นระหว่างผู้มีส่วนได้เสียที่แตกต่างกันของระบบที่. ในหนังสือเล่มนี้เป็นเป้าหมายหลักอยู่ในรูปแบบของสถาปัตยกรรมแบบกราฟิก (ในขณะที่เมื่อเทียบกับต้นฉบับเดิมหรือวาจา) ธรรมชาติ หนึ่งอาจจะหมายถึงรูปแบบสถาปัตยกรรมเหล่านี้เป็น'ในความหมายที่แคบ' ในบทนี้ แต่เรามีความกังวลกับสถาปัตยกรรมคำอธิบายใน'ความหมายที่กว้างขึ้น' ในคำอื่น ๆ ที่เกี่ยวกับใจวาจาหรืออื่น ๆชนิดของคำอธิบายสถาปัตยกรรมที่จะถูกรวม. ในปัจจุบันภาษาคำอธิบายหลายมีอยู่แล้วให้กับสถาปนิกในขณะที่อื่น ๆ อีกมากมายที่ถูกสร้างขึ้นโดยทั้งสองสถาบันการศึกษาและอุตสาหกรรม ทำไมสิ่งเหล่านี้ภาษา? วิธีการหนึ่งเลือกภาษาที่เป็น apt มากที่สุดในสถานการณ์ที่กำหนดหรือไม่คำถามดังกล่าวขอคำตอบที่รู้สึกดี สอดคล้องกับสุภาษิตโบราณที่ว่า 'การปฏิบัติสิ่งที่คุณสั่งสอน' เรายืนยันว่าเช่นเดียวกับวิศวกรรมความต้องการที่เหมาะสมเป็นสิ่งจำเป็นสำหรับการพัฒนาของระบบความต้องการที่เหมาะสมควรเป็นสูตรสำหรับภาษาและวิธีการที่จะใช้เป็นยานพาหนะสำหรับการสื่อสารระหว่างการพัฒนาระบบ. ในการกำหนดความต้องการเหล่านี้ปัจจัยหลายประการที่ควรจะนำมาพิจารณาเช่นเป้าหมายการพัฒนาเป้าหมายการสื่อสารที่กังวลเป้าหมายส่วนบุคคลความสามารถและทัศนคติของนักแสดงที่เกี่ยวข้องและอื่นๆ62 4 การสื่อสารของสถาปัตยกรรมองค์กรเราออกไปให้หนุนทางทฤษฎีของประเด็นที่เกี่ยวข้องรวมทั้งเป็นแนวทางในการปฏิบัติที่จะช่วยสถาปนิกในการเลือกวิธีที่ดีที่สุดสำหรับพวกเขาตอบสนองความต้องการการสื่อสารทางสถาปัตยกรรม ดังนั้นเราจึงจะเริ่มต้นด้วยทฤษฎีการตรวจสอบข้อเท็จจริงของปัญหาที่เกี่ยวข้องกับการสื่อสารในระหว่างการพัฒนาระบบ(นิกาย. 4.2 และ 4.3) ตามด้วยการประยุกต์ใช้การสำรวจนี้ไปที่สนามของสถาปัตยกรรมองค์กร(นิกาย. 4.4). 4.2 การพัฒนาระบบเป็น การเปลี่ยนแปลงความรู้กระบวนการในสาระสำคัญที่เราพิจารณาการพัฒนาระบบเป็นกระบวนการการเปลี่ยนแปลงความรู้โดยการสนทนาที่ถูกนำมาใช้ในการแบ่งปันและสร้างองค์ความรู้ที่เกี่ยวข้องกับทั้งระบบที่มีการพัฒนาเช่นเดียวกับการพัฒนาตัวเอง ความคิดของการสนทนา'ควรจะตีความที่นี่ในความหมายกว้างตั้งแต่คนเดียวผลิต(สถาปัตยกรรม) คำอธิบายผ่านการออกแบบที่หนึ่งในหนึ่งหรือเซสชั่นการสอบถามไปยังการประชุมเชิงปฏิบัติการกับหลายผู้มีส่วนได้เสียและแม้แต่อย่างกว้างขวางเผยแพร่สถาปัตยกรรมที่ชัดเจน วิธีคิดนี้จะมีกรอบของความคิดที่ดีกว่าสามารถเข้าใจ (การสื่อสาร) ต้องการโพสต์ในภาษาคำอธิบายสถาปัตยกรรม. 4.2.1 ระบบการพัฒนาชุมชนได้รับเรามุ่งเน้นที่การสื่อสารเป็นสิ่งสำคัญที่จะระบุนักแสดงที่สามารถมีบทบาทในการสื่อสารที่เกิดขึ้นในระหว่างการพัฒนาระบบกระบวนการ นักแสดงเหล่านี้มีแนวโน้มที่จะมีสัดส่วนการถือหุ้นบางส่วนที่เกี่ยวกับระบบที่มีการพัฒนา ตัวอย่างของนักแสดงดังกล่าวเป็นเจ้าของปัญหานักแสดงที่คาดหวังในระบบในอนาคต (เช่นอนาคตของผู้ใช้ระบบ) ผู้เชี่ยวชาญโดเมนสปอนเซอร์, สถาปนิก, วิศวกร, นักวิเคราะห์ธุรกิจ ฯลฯนักแสดงเหล่านี้ แต่ไม่ได้เท่านั้น 'วัตถุ' เล่นบทบาทสำคัญในการพัฒนาระบบ อีกชั้นที่สำคัญของวัตถุที่แตกต่างกันเป็นจำนวนมากเอกสารรูปแบบรูปแบบอื่น ๆ ที่เป็นตัวแทนของบิตและชิ้นส่วนของความรู้ที่เกี่ยวข้องกับระบบที่มีการพัฒนา กลุ่มนี้ทั้งหมดของวัตถุและบทบาทที่แตกต่างกันพวกเขาสามารถเล่นเป็นสิ่งที่เราจะพูดถึงการพัฒนาระบบชุมชน. การพัฒนาชุมชนของระบบ: กลุ่มของวัตถุเช่นนักแสดงและการแสดงซึ่งมีส่วนร่วมในการพัฒนาระบบ. 4.2 การพัฒนาระบบเป็นแปลงความรู้กระบวนการ 63 (เราจะชี้แจงดังต่อไปนี้เหตุผลที่เราเชื่อว่าเอกสารที่เป็นส่วนหนึ่งของชุมชน.) นักแสดงในชุมชนพัฒนาระบบการให้จะ (มักจะเป็นผลของการเดิมพันของพวกเขา) มีความสนใจบางอย่างเกี่ยวกับ กับระบบที่มีการพัฒนา สนใจเรื่องนี้หมายถึง subinterest ที่เกี่ยวกับ (เนื้อหาของ) คำรายละเอียดระบบที่มีการสื่อสารภายในชุมชน สนใจเรื่องนี้ในสอดคล้องกับมาตรฐาน IEEE 1471 (IEEE สมาคมคอมพิวเตอร์ 2000) จะเรียกว่าเป็นความกังวลของผู้มีส่วนได้เสียกังวล: ความสนใจของผู้มีส่วนได้เสียกับการไปถึงคำอธิบายสถาปัตยกรรมของระบบบางอย่างที่เกิดจากเป้าหมายของผู้มีส่วนได้เสียและปัจจุบันหรือในอนาคต. บทบาท (s) รับบทโดยระบบที่เกี่ยวข้องกับเป้าหมายเหล่านี้เป็นตัวอย่างของความกังวลบางส่วน: - สถานการณ์ปัจจุบันที่เกี่ยวกับการสนับสนุนคอมพิวเตอร์ธุรกิจกระบวนการ. - ความต้องการของผู้มีส่วนได้เสียที่เฉพาะเจาะจงเกี่ยวกับการสถานการณ์ที่ต้องการ- การปรับปรุงซึ่งระบบใหม่อาจนำไปสู่สถานการณ์ที่มีอยู่ก่อนในความสัมพันธ์กับค่าใช้จ่ายในการซื้อระบบ. - ผลกระทบที่อาจเกิดขึ้นของระบบใหม่ในกิจกรรมของผู้ใช้ในอนาคต. - ผลกระทบที่อาจเกิดขึ้นใหม่ ระบบในการทำงานของผู้บริหารระบบที่มีการรักษาระบบใหม่. 4.2.2 ความรู้การพัฒนาระบบท่าเรือชุมชนพัฒนาระบบความรู้เกี่ยวกับระบบที่มีการพัฒนา การสื่อสารที่เกิดขึ้นภายในชุมชนการพัฒนาระบบหลักมีวัตถุประสงค์ที่จะสร้างเพิ่มขึ้นและเผยแพร่ความรู้นี้. ทั้งนี้ขึ้นอยู่กับความกังวลของพวกเขามีส่วนได้เสียจะมีความสนใจในความรู้ที่แตกต่างกันในหัวข้อที่เกี่ยวข้องกับระบบการพัฒนา. ตอนนี้เราจะสั้น ๆ สำรวจชนิดของความรู้ ที่เกี่ยวข้องกับระบบและการพัฒนาของตน ในคำอื่น ๆ หัวข้อความรู้ที่จะประสบความสำเร็จ. ในส่วนย่อยต่อไปเราจะหารือในรายละเอียดในสิ่งที่วิธีนี้ความรู้ที่สามารถทำ (เพิ่มเติม) อย่างชัดเจน. ในระหว่างการพัฒนาระบบสมาชิกของชุมชนในการพัฒนาระบบจะสร้างและการแลกเปลี่ยนความรู้ที่เกี่ยวข้องกับหัวข้อที่แตกต่าง เราสามารถสร้างความแตกต่างครั้งแรกระหว่างโดเมนเป้าหมายที่เกี่ยวข้องกับระบบการพัฒนาและโดเมนของโครงการที่เกี่ยวกับการพัฒนาตัวเอง เราได้ยืมคำเหล่านี้จากบริการข้อมูลจัดซื้อจัดจ้างห้องสมุด (ISPL) (Franckson 64 4 ของสถาปัตยกรรมการสื่อสารองค์กรและVerhoef 1999) สำหรับทั้งสองของโดเมนความรู้เหล่านี้การปรับแต่งเพิ่มเติมค

ผลลัพธ์ (ไทย) 3:

การสื่อสารบทที่ 4

บทนี้ของสถาปัตยกรรมองค์กรนำเสนอการสื่อสารมุมมองของสถาปัตยกรรมองค์กร เรา
ให้ทั้งเชิงทฤษฎีและมุมมองที่เป็นประโยชน์ในประเด็นที่เกี่ยวข้องใน
การสื่อสารของสถาปัตยกรรมองค์กร ความคิดทั่วไปคือบท
ช่วยให้ผู้อ่านเห็นว่าการพัฒนาสถาปัตยกรรมและแบบจำลองสามารถดีที่สุด
สนับสนุนโดยการอภิปรายถึงรูปแบบบางอย่างของแบบจำลองที่ใช้ในบางสถานการณ์
และวิธีนี้เหมาะกับเป้าหมายในกระบวนการ มุมมองทางทฤษฎีจะเน้น
การสื่อสารระหว่างการพัฒนาระบบในทั่วไปที่คำระบบ
ควรจะตีความว่าเป็นระบบเปิด และปราดเปรียว ประกอบด้วยทั้งมนุษย์
และ คอมพิวเตอร์ นักแสดง ที่จงใจออกแบบให้มุมมองในทางปฏิบัติจะ
ใช้รูปทรงที่เป็นชุดของแนวทางปฏิบัติที่ควรช่วยสถาปนิกในการ
และความหมายของสถาปัตยกรรมอธิบายวิธีที่เหมาะสำหรับเฉพาะ
( การสื่อสาร )

อธิบายบริบท 4.1 แนะนำสถาปัตยกรรมคือทั้งหมดที่เกี่ยวกับการสื่อสาร ถ้าบางสถาปัตยกรรมรายละเอียด
ไม่ได้ใช้เป็นวิธีการสื่อสารในรูปร่างหรือรูปแบบแล้วรายละเอียด
ไม่ควรถูกสร้างขึ้นในสถานที่แรก สิ่งที่บทบาทของ
สถาปัตยกรรมคำอธิบาย มันมักจะเกี่ยวข้องกับบางเพื่อการสื่อสารด้าน
พิจารณา , ภาพประกอบ , ศักยภาพการใช้คำอธิบายเป็นสถาปัตยกรรม
ระบุไว้ใน IEEE เป็นมาตรฐาน IEEE สมาคมคอมพิวเตอร์ 2000 ) :
) การแสดงออกของระบบและวิวัฒนาการของ ( ศักยภาพ )
.การวิเคราะห์–ของสถาปัตยกรรมทางเลือก
–การวางแผนธุรกิจสำหรับการเปลี่ยนจากมรดกสถาปัตยกรรมสถาปัตยกรรมใหม่ – การสื่อสารระหว่างองค์กร
มีส่วนร่วมในการพัฒนา , การผลิต ,
Fielding , การดำเนินงาน , และการบำรุงรักษาระบบ
–การสื่อสารระหว่างถึงและพัฒนาเป็นส่วนหนึ่งของการเจรจาสัญญา
.
lankhorst et al . , สถาปัตยกรรมองค์กรที่ทำงานองค์กร
วิศวกรรมชุดดอย 10.1007 / 978-3-642-29651-2_4 # Springer Verlag ไฮเดลเบิร์ก , เบอร์ลิน


– 2013 61 เกณฑ์การรับรองของระบบอัจฉริยะเพื่อสถาปัตยกรรม .
–การพัฒนาและการบำรุงรักษาเอกสาร รวมถึงวัสดุและวัสดุที่เก็บใหม่

) ที่เข้าฝึกอบรม กิจกรรม ออกแบบระบบ และพัฒนา
ตามมา .- นำเข้าเครื่องมือสร้างและวิเคราะห์ระบบงานและสนับสนุนโครงสร้างพื้นฐาน .
) ; การจัดการปรับแต่งและซ่อมแซม ;
ออกแบบ และซ่อมบำรุงระบบ , ส่วนประกอบของระบบและ .
–วางแผนและสนับสนุนงบประมาณ และจัดทำเอกสารการซื้อ
( เช่นการร้องขอสำหรับข้อเสนอและงบ

) งาน ทบทวน วิเคราะห์ และการประเมินผลของระบบทั้งวงจรชีวิต .
รายละเอียด–สำหรับกลุ่มของระบบการตั้งค่าทั่วไปของลักษณะ ( เช่นสายผลิตภัณฑ์

) แต่ละเหล่านี้ใช้สถาปัตยกรรมที่เกี่ยวข้องกับรูปแบบของการสื่อสาร ในหลอดเลือดดำนี้
ในบทนี้เราเสนอ ' การสื่อสาร ' มุมมองของสถาปัตยกรรมองค์กรทราบ

ในการทำเช่นนั้น เราให้ทั้งเชิงทฤษฎีและปฏิบัติ
มุมมองในประเด็นที่เกี่ยวข้องในการสื่อสารของสถาปัตยกรรมองค์กร
มุมมองทางทฤษฎีจะเน้นการสื่อสารในการพัฒนาระบบโดยทั่วไปที่ระบบคำควรถูกตีความว่าเป็นระบบใด ๆและเปิดใช้งาน
ประกอบด้วยทั้งมนุษย์และคอมพิวเตอร์นักแสดง ที่จงใจ
ออกแบบ มุมมองในทางปฏิบัติจะใช้รูปทรงที่เป็นชุดของแนวทางปฏิบัติ
ที่ควรจะช่วยสถาปนิกในการเลือก ( ความหมาย ) ของสถาปัตยกรรมรายละเอียด
ภาษาและวิธีที่เหมาะสำหรับสถานการณ์ที่เฉพาะเจาะจง ( การสื่อสาร ) .
ลักษณะสถาปัตยกรรมที่ใช้ในการสื่อสารของสถาปัตยกรรมวางแผน
หรือระบบที่มีอยู่แล้ว นี้จะเป็นระบบที่เป็นส่วนหนึ่งขององค์กร ,
องค์กร ธุรกิจ ระบบสารสนเทศ ระบบซอฟต์แวร์