Difference between revisions of "IEEE 1471"

From Second Life Wiki
Jump to navigation Jump to search
(Fixed link that was broken by acm.org)
 
Line 3: Line 3:
:* [http://en.wikipedia.org/wiki/IEEE_1471 Wikipedia:IEEE-1471]
:* [http://en.wikipedia.org/wiki/IEEE_1471 Wikipedia:IEEE-1471]
:* [http://www.enterprise-architecture.info/Images/Documents/IEEE%201471-2000.pdf IEEE-1471 presentation slides]
:* [http://www.enterprise-architecture.info/Images/Documents/IEEE%201471-2000.pdf IEEE-1471 presentation slides]
:* [http://info.acm.org/sigada/conf/sigada2000/private/SIGAda2000-CDROM/SIGAda2000-Proceedings/Emery-Architecture-Presentation.pdf Describing Architectures, D.Emery]
:* [http://www.sigada.org/conf/sigada2000/private/SIGAda2000-CDROM/SIGAda2000-Proceedings/Emery-Architecture-Presentation.pdf?searchterm=Describing+Architectures Describing Architectures, D.Emery]
 


IEEE-1471 looks slightly heavyweight at first glance, but it isn't in practice because it isn't a straightjacket.  Its main benefit is in helping designers of system architecture to embrace the idea that interested parties ('''stakeholders''') each have their own concerns ('''viewpoints''') which need to be described in appropriate architectural '''views'''.
IEEE-1471 looks slightly heavyweight at first glance, but it isn't in practice because it isn't a straightjacket.  Its main benefit is in helping designers of system architecture to embrace the idea that interested parties ('''stakeholders''') each have their own concerns ('''viewpoints''') which need to be described in appropriate architectural '''views'''.

Latest revision as of 02:51, 12 August 2009

Common understanding is achieved by discussing common mental models using a common language. In systems architecture, IEEE-1471 helps us approach that goal:

IEEE-1471 looks slightly heavyweight at first glance, but it isn't in practice because it isn't a straightjacket. Its main benefit is in helping designers of system architecture to embrace the idea that interested parties (stakeholders) each have their own concerns (viewpoints) which need to be described in appropriate architectural views.

An architecture itself is just an abstraction, and it is through the multiple views that this abstraction reveals how it solves the numerous (and frequently orthogonal) requirements. One view definitely doesn't fit all. (See Talk for more.)