Difference between revisions of "IEEE 1471"
Jump to navigation
Jump to search
Liana Linden (talk | contribs) m (AWG wiki restructuring edit) |
(Fixed link that was broken by acm.org) |
||
| (One intermediate revision by one other user not shown) | |||
| 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:// | :* [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'''. | ||
| Line 11: | Line 10: | ||
[[Category: | [[Category: AW Groupies]] | ||
Latest revision as of 01: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.)