820:
segment architecture drives decisions for a business case or group of business cases supporting a core mission area or common or shared service. The primary stakeholders for segment architecture are business owners and managers. Segment architecture is related to EA through three principles: structure, reuse, and alignment. First, segment architecture inherits the framework used by the EA, although it may be extended and specialized to meet the specific needs of a core mission area or common or shared service. Second, segment architecture reuses important assets defined at the enterprise level including: data; common business processes and investments; and applications and technologies. Third, segment architecture aligns with elements defined at the enterprise level, such as business strategies, mandates, standards, and performance measures.
906:
416:
27:
794:
599:
501:
741:
2146:
837:
373:
970:
2136:
1590:
275:, elicit concerns, identify a set of viewpoints to be used, and then apply these viewpoint specifications to develop the set of views relevant to the system of interest. Rather than define a particular set of viewpoints, the standard provides uniform mechanisms and requirements for architects and organizations to define their own viewpoints. In 1996 the ISO Reference Model for Open Distributed Processing (
644:
571:. Because the discipline of Enterprise Architecture and Engineering is so broad, and because enterprises can be large and complex, the models associated with the discipline also tend to be large and complex. To manage this scale and complexity, an Architecture Framework provides tools and methods that can bring the task into focus and allow valuable artifacts to be produced when they are most needed.
1569:
816:
aligned to the agency mission and strategic goals and objectives. From an investment perspective, EA is used to drive decisions about the IT investment portfolio as a whole. Consequently, the primary stakeholders of the EA are the senior managers and executives tasked with ensuring the agency fulfills its mission as effectively and efficiently as possible.
777:, systems and services view, and technical standards view. The three views and their interrelationships driven – by common architecture data elements – provide the basis for deriving measures such as interoperability or performance, and for measuring the impact of the values of these metrics on operational mission and task effectiveness.
381:
the distribution of functions over specific components and component interactions will typically reflect a different partitioning of concerns than that reflected in the original viewpoints. Thus additional viewpoints, addressing the concerns of the individual components and the bottom-up synthesis of the system, may also be useful.
1027:
Technology
Development & Assessment view – Includes description of technology development programs designed to produce algorithms or components that may be included in a system development project. Includes evaluation of properties of selected hardware and software components to determine if they
402:
analyses performed. Products provide a way for visualizing architecture data as graphical, tabular, or textual representations. Views provide the ability to visualize architecture data that stem across products, logically organizing the data for a specific or holistic perspective of the architecture.
819:
By contrast, segment architecture defines a simple roadmap for a core mission area, business service, or enterprise service. Segment architecture is driven by business management and delivers products that improve the delivery of services to citizens and agency staff. From an investment perspective,
659:) specifies a set of viewpoints for partitioning the design of a distributed software/hardware system. Since most integration problems arise in the design of such systems or in very analogous situations, these viewpoints may prove useful in separating integration concerns. The RMODP viewpoints are:
300:
allows a user to examine a portion of a particular interest area. For example, an
Information View may present all functions, organizations, technology, etc. that use a particular piece of information, while the Organizational View may present all functions, technology, and information of concern to
292:
A view of a system is a representation of the system from the perspective of a viewpoint. This viewpoint on a system involves a perspective focusing on specific concerns regarding the system, which suppresses details to provide a simplified model having only those elements related to the concerns of
271:) prescribes the contents of architecture descriptions and describes their creation and use under a number of scenarios, including precedented and unprecedented design, evolutionary design, and capture of design of existing systems. In all of these scenarios the overall process is the same: identify
380:
In the system itself, however, all of the specifications appearing in the various viewpoint models must be addressed in the realized components of the system. And the specifications for any given component may be drawn from many different viewpoints. On the other hand, the specifications induced by
209:
and others published a very important paper on viewpoints. In that work: "A viewpoint can be thought of as a combination of the idea of an “actor”, “knowledge source”, “role” or “agent” in the development process and the idea of a “view” or “perspective” which an actor maintains." An important idea
948:
Navigation view – Describes the motion of the major elements within the system (trajectory, path, orbit), including their interaction with external elements and forces that are outside of the control of the system, but that must be modeled with it to understand system behavior (planets, asteroids,
844:
This "set of views", as described below, is a listing of possible modeling viewpoints. Not all of these views may be used for any one project and other views may be defined as necessary. Note that for some analyses elements from multiple viewpoints may be combined into a new view, possibly using a
305:
views comprise a group of work products whose development requires a particular analytical and technical expertise because they focus on either the “what,” “how,” “who,” “where,” “when,” or “why” of the enterprise. For example, Functional View work products answer the question “how is the mission
987:
Software view - Describes the software engineering aspects of the system, software design and implementation of functionality within software components, select languages and libraries to be used, define APIs, do the engineering of abstract functional objects into tangible software elements. Some
627:
The
Framework is used for organizing architectural "artifacts" in a way that takes into account both who the artifact targets (for example, business owner and builder) and what particular issue (for example, data and functionality) is being addressed. These artifacts may include design documents,
519:
in 1995 for describing the architecture of software-intensive systems, based on the use of multiple, concurrent views. The views are used to describe the system in the viewpoint of different stakeholders, such as end-users, developers and project managers. The four views of the model are logical,
487:
from two distinct views, the "user view" and the "computer view". From the user view, which will be referred to as the “external schema,” the definition of data is in the context of reports and screens designed to aid individuals in doing their specific jobs. The required structure of data from a
368:
A given view is a specification for the system at a particular level of abstraction from a given viewpoint. Different levels of abstraction contain different levels of detail. Higher-level views allow the engineer to fashion and comprehend the whole design and identify and resolve problems in the
364:
In any given viewpoint, it is possible to make a model of the system that contains only the objects that are visible from that viewpoint, but also captures all of the objects, relationships and constraints that are present in the system and relevant to that viewpoint. Such a model is said to be a
149:
executive will ask different questions of a system make-up than would a system implementer. The concept of viewpoints framework, therefore, is to provide separate viewpoints into the specification of a given complex system in order to facilitate communication with the stakeholders. Each viewpoint
815:
By definition, Enterprise
Architecture (EA) is fundamentally concerned with identifying common or shared assets – whether they are strategies, business processes, investments, data, systems, or technologies. EA is driven by strategy; it helps an agency identify whether its resources are properly
1023:
Infrastructure view – Defines the infrastructure elements that are to support the engineering, design, and fabrication process. May include data system elements (design repositories, frameworks, tools, networks) and hardware elements (chip fabrication, thermal vacuum facility, machine shop, RF
789:
enterprise, segment, and solution architecture provide different business perspectives by varying the level of detail and addressing related but distinct concerns. Just as enterprises are themselves hierarchically organized, so are the different views provided by each type of architecture. The
401:
At the data layer are the architecture data elements and their defining attributes and relationships. At the presentation layer are the products and views that support a visual means to communicate and understand the purpose of the architecture, what it describes, and the various architectural
318:
In systems engineering, a viewpoint is a partitioning or restriction of concerns in a system. Adoption of a viewpoint is usable so that issues in those aspects can be addressed separately. A good selection of viewpoints also partitions the design of the system into specific areas of expertise.
198:
and K.E. Schoman in 1977 introduce the constructs context, viewpoint, and vantage point to organize the modeling process in systems requirements definition. According to Ross and
Schoman, a viewpoint "makes clear what aspects are considered relevant to achieving ... the overall purpose " and
960:
Power view – Describes the active and passive power components in the system (solar panels, batteries, RTGs) within the system and their connectors, along with the power properties of other components (data system and propulsion elements as power sinks and structural panels as grounding
393:
is a representation of a system architecture, at any time, in terms of its component parts, how those parts function, the rules and constraints under which those parts function, and how those parts relate to each other and to the environment. In an architecture description the
488:
usage view changes with the business environment and the individual preferences of the user. From the computer view, which will be referred to as the “internal schema,” data is defined in terms of file structures for storage and retrieval. The required structure of data for
356:, the traditional way to divide modeling perspectives is to distinguish the structural, functional and behavioral/processual perspectives. This together with rule, object, communication and actor and role perspectives is one way of classifying modeling approaches
751:
The DoDAF defines a set of products that act as mechanisms for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through graphic, tabular, or textual means. These products are organized under four views:
991:
Hardware views – Describes the hardware engineering aspects of the system, hardware design, selection and implementation of all of the physical components to be assembled into the system. There may be many of these views, each specific to a different engineering
956:
Thermal view – Describes the active and passive thermal components in the system (radiators, coolers, vents) and their connectors (physical and free space radiation) and attributes, along with the thermal properties of other components (i.e. antenna as sun
1005:
Integration and Test view – Looks at the system from the perspective of what must be done to assemble, integrate and test system and sub-systems, and assemblies. Includes verification of proper functionality, driven by scenarios, in satisfaction of
257:. The advantage of multiple views is that hidden requirements and stakeholder disagreements can be discovered more readily. However, studies show that in practice, the added complexity of reconciling multiple views can undermine this advantage.
81:
Since the early 1990s there have been a number of efforts to prescribe approaches for describing and analyzing system architectures. A result of these efforts have been to define a set of views (or viewpoints). They are sometimes referred to as
995:
Communications
Protocol view – Describes the end to end design of the communications protocols and related data transport and data management services, shows the protocol stacks as they are implemented on each of the physical components of the
1032:
In contrast to the previous listed view models, this "nominal set of views" lists a whole range of views, possible to develop powerful and extensible approaches for describing a general class of software intensive system architectures.
136:
Most complex system specifications are so extensive that no single individual can fully comprehend all aspects of the specifications. Furthermore, we all have different interests in a given system and different reasons for examining the
952:
Structural view – Describes the structural components in the system (s/c bus, struts, panels, articulation), their physical attributes and connectors, along with the relevant structural aspects of other components (mass, stiffness,
635:. The Zachman Framework has been recognized by the U.S. Federal Government as having "... received worldwide acceptance as an integrated framework for managing change in enterprises and the systems that support them."
772:
Each view depicts certain perspectives of an architecture as described below. Only a subset of the full DoDAF viewset is usually created for each system development. The figure represents the information that links the
848:
In a latter presentation this nominal set of views was presented as an
Extended RASDS Semantic Information Model Derivation. Hereby RASDS stands for Reference Architecture for Space Data Systems. see second image.
1019:
Standards view – Defines the standards to be adopted during design of the system (e.g. communication protocols, radiation tolerance, soldering). These are essentially constraints on the design and implementation
923:
in the system, their interactions, behavior, provided services, constraints and data flows among them. Defines which functions the system is capable of performing, regardless of how these functions are actually
964:
Propulsion view – Describes the active and passive propulsion components in the system (thrusters, gyros, motors, wheels) within the system and their connectors, along with the propulsive properties of other
941:
Data System view – Describes instruments, computers, and data storage components, their data system attributes and the communications connectors (busses, networks, point to point links) that are used in the
154:
that optimizes the vocabulary and presentation for the audience of that viewpoint. Viewpoint modeling has become an effective approach for dealing with the inherent complexity of large distributed systems.
1009:
IV&V view – independent validation and verification of functionality and proper operation of the system in satisfaction of requirements. Does system as designed and developed meet goals and objectives.
931:
and interactions among functional elements within the system. Includes overall system control interactions, interactions between control elements and sensor / effector elements and management interactions.
983:
Allocation view – Describes the allocation of functional objects to engineered physical and computational components within the system, permits analysis of performance and used to verify satisfaction of
828:
In search of "Framework for
Modeling Space Systems Architectures" Peter Shames and Joseph Skipper (2006) defined a "nominal set of views", Derived from CCSDS RASDS, RM-ODP, ISO 10746 and compliant with
310:
using process and activity modeling. They show the enterprise from the point of view of functions. They also may show organizational and information components, but only as they relate to functions.
293:
the viewpoint. For example, a security viewpoint focuses on security concerns and a security viewpoint model contains those elements that are related to security from a more general model of a system.
483:
Over the years, the skill and interest in building information systems has grown tremendously. However, for the most part, the traditional approach to building systems has only focused on defining
1573:
607:
548:: depicts the system from a system engineer's point of view. It is concerned with the topology of software components on the physical layer, as well as communication between these components.
431:
for data modeling, introduced in 1977, can be considered one of the first view models. It is an approach to building information systems and systems information management, that promotes the
999:
Risk view – Describes the risks associated with the system design, processes, and technologies, assigns additional risk assessment attributes to other elements described in the architecture
1488:
ISO/IEC 10746-1:1998 Information technology – Open
Distributed Processing: Reference Model – Part 1: Overview, International Organization for Standardization, Geneva, Switzerland, 1998.
733:
into complementary and consistent views. It is especially suited to large systems with complex integration and interoperability challenges, and is apparently unique in its use of "
326:) a viewpoint is a specification for an individual view. A view is a representation of a whole system from the perspective of a viewpoint. A view may consist of one or more
1219:
Easterbrook, S.; Yu, E.; Aranda, J.; Yuntian Fan; Horkoff, J.; Leica, M.; Qadir, R.A. (2005). "Do viewpoints lead to better conceptual models? An exploratory case study".
706:
the use of enterprise objects and behaviors in specifying the behaviors of computational components, and use of the information units in defining computational interfaces
901:
as it is realized and manipulated within the system. Data elements are defined by the metamodel view and they are referred to by functional objects in other views.
695:, which is concerned with the explicit choice of technologies for the implementation of the system, and particularly for the communications among the components
1315:
1002:
Control
Engineering view - Analyzes system from the perspective of its controllability, allocation of elements into system under control and control system
542:: deals with the dynamic aspect of the system, explains the system processes and how they communicate, and focuses on the runtime behavior of the system.
330:. Each such architectural model is developed using the methods established by its associated architectural system, as well as for the system as a whole.
225:
Since the early 1990s there have been a number of efforts to codify approaches for describing and analyzing system architectures. These are often termed
681:, which is concerned with the functional decomposition of the system into a set of components that exhibit specific behaviors and interact at interfaces
667:, which is concerned with the purpose and behaviors of the system as it relates to the business objective and the business processes of the organization
624:
at IBM in 1987, is a framework for enterprise architecture, which provides a formal and highly structured way of viewing and defining an enterprise.
1549:
1202:
890:
elements and their structures and relationships. Defines the classes of data that are created and managed by the system and the data architecture.
1622:
674:, which is concerned with the nature of the information handled by the system and constraints on the use and interpretation of that information
238:
722:
97:
is a work product that presents specific architecture data for a given system. However, the same term is sometimes used to refer to a view
1433:
1057:
945:
Telecomm view – Describes the telecomm components (antenna, transceiver), their attributes and their connectors (RF or optical links).
1454:
1505:
1334:
322:
Viewpoints provide the conventions, rules, and languages for constructing, presenting and analysing views. In ISO/IEC 42010:2007 (
162:, utilize multiple views to address several areas of concerns, each one focusing on a specific aspect of the system. Examples of
2139:
2005:
1934:
1246:
862:
elements and their structures and relationships. May include agreements, contracts, policies and organizational interactions.
279:) was published to provide a useful framework for describing the architecture and design of large-scale distributed systems.
369:
large. Lower-level views allow the engineer to concentrate on a part of the design and develop the detailed specifications.
1828:
1731:
1528:
688:, which is concerned with the mechanisms and functions required to support the interactions of the computational components
586:
can be approved. Similarly, they may wish to specify certain views be used in the documentation of procured systems - the
1397:
699:
RMODP further defines a requirement for a design to contain specifications of consistency between viewpoints, including:
587:
234:
1615:
1473:
1283:
1808:
1675:
1660:
1042:
564:
390:
87:
150:
satisfies an audience with interest in a particular set of aspects of the system. Each viewpoint may use a specific
2170:
1382:. New York University Graduate School of Business Administration. Center for Research on Information Systems, 1986.
1311:
1052:
590:
stipulates that specific DoDAF views be provided by equipment suppliers for capital project above a certain value.
130:
797:
786:
1964:
1891:
1881:
1726:
1655:
1072:
988:
functional elements, described using a software language, may actually be implemented as hardware (FPGA, ASIC)
249:) established useful definitions of view, viewpoint, stakeholder and concern and guidelines for documenting a
101:, including the particular viewpoint and the corresponding guidance that defines each concrete view. The term
2175:
2149:
2015:
1944:
1886:
1608:
218:, the statements expressed in the viewpoint's style describing particular domains". Subsequent work, such as
2180:
1954:
1813:
1680:
1594:
327:
655:
The International Organization for Standardization (ISO) Reference Model for Open Distributed Processing (
245:. Among these, the IEEE Recommended Practice for Architectural Description of Software-Intensive Systems (
1876:
1871:
1685:
1047:
20:
1546:
1417:
1199:
2071:
1919:
1914:
1866:
1843:
1823:
651:
view model, which provides five generic and complementary viewpoints on the system and its environment.
712:
the satisfaction of information, computational and engineering requirements in the chosen technologies
631:
The Zachman Framework is often referenced as a standard approach for expressing the basic elements of
492:
depends upon the specific computer technology employed and the need for efficient processing of data.
205:
As examples of viewpoints, the paper offers: Technical, Operational and Economic viewpoints. In 1992,
2076:
2066:
1979:
1778:
1761:
1670:
1229:
1161:
307:
790:
Federal Enterprise Architecture Practice Guidance (2006) has defined three types of architecture:
737:" detailing the external customer's operating domain in which the developing system will operate.
1929:
1773:
1104:
ISO/IEC 10746-1, Information technology — Open Distributed Processing — Reference model: Overview
726:
632:
568:
420:
71:
905:
536:: illustrates a system from a programmers perspective and is concerned with software management.
222:, preserved this distinction by utilizing two separate terms: viewpoint and view, respectively.
194:
In the 1970s, methods began to appear in software engineering for modeling with multiple views.
1984:
1741:
1736:
1224:
575:
226:
163:
122:
83:
55:
709:
the association of engineering choices with computational interfaces and behavior requirements
598:
556:
or scenarios are utilized to illustrate the architecture. Hence the model contains 4+1 views.
1803:
1756:
1430:
1077:
606:
with an explanation of the rows. The original framework is more advanced, see for an example
468:
think of them and talk about them. The physical schema describes the internal formats of the
428:
338:
67:
1127:
2101:
1939:
1798:
1788:
1700:
1645:
1631:
730:
480:. The framework attempted to permit multiple data models to be used for external schemata.
346:
342:
297:
254:
78:
is a representation of the whole system from the perspective of a related set of concerns.
51:
1262:
415:
8:
2121:
2106:
1974:
1838:
1746:
1690:
1449:
1157:
582:
governance. An organization may wish to mandate that certain models be produced before a
477:
272:
250:
206:
63:
47:
1501:
1350:
26:
2111:
1751:
1331:
869:, goals, and objectives that drive the system. Says what the system must be able to do.
579:
353:
793:
2025:
1783:
1242:
1067:
887:
873:
617:
603:
516:
446:
302:
171:
2096:
2040:
1818:
1710:
1705:
1234:
1162:
Viewpoints: A framework for integrating multiple perspectives in system development
1028:
are at a sufficient state of maturity to be adopted for the mission being designed.
774:
759:
734:
489:
465:
436:
432:
345:
has a different focus, conceptualization, dedication and visualization of what the
214:, the scheme and notation by which the viewpoint expresses what it can see" and "a
2116:
1969:
1949:
1833:
1695:
1553:
1509:
1477:
1458:
1437:
1401:
1338:
1319:
1287:
1206:
1141:
500:
372:
195:
2020:
1924:
1665:
920:
876:. Includes user views and descriptions of how the system is expected to behave.
341:
is a set of different ways to represent pre-selected aspects of a system. Each
114:
1392:
872:
Scenario view – Describes the way that the system is intended to be used, see
2164:
2000:
1768:
1470:
1341:. The European Process Industries STEP Technical Liaison Executive (EPISTLE).
1307:
740:
583:
264:
142:
117:, to organize the elements of the problem and the solution around domains of
1369:. Edited by J. Ramadas & S. Chunawala, Homi Bhabha Centre, Mumbai, 2006.
1279:
530:: is concerned with the functionality that the system provides to end-users.
2035:
2030:
1959:
1362:
928:
859:
621:
113:
The purpose of views and viewpoints is to enable humans to comprehend very
969:
1418:
Architectural Blueprints — The “4+1” View Model of Software Architecture.
1144:
and K.E. Schoman, Jr. "Structured analysis for requirements definition."
898:
866:
703:
the use of enterprise objects and processes in defining information units
126:
1278:
US Department of the Treasury Chief Information Officer Council (2000).
1166:
International Journal of Software Engineering and Knowledge Engineering,
476:, and the external schema defines the view of the data presented to the
2010:
1600:
1238:
836:
419:
The notion of a three-schema model was first introduced in 1977 by the
376:
Illustration of the views, products and data in Architecture Framework.
1221:
13th IEEE International Conference on Requirements Engineering (RE'05)
830:
323:
260:
246:
219:
159:
118:
643:
253:
through the use of multiple views by applying viewpoints to address
1793:
1380:
New Directions for Database Systems: Revised Versions of the Papers
567:
defines how to organize the structure and views associated with an
553:
473:
457:
146:
1527:
Federal Enterprise Architecture Program Management Office (2006).
1461:, Roger Sessions, Microsoft Developer Network Architecture Center,
1451:
A Comparison of the Top Four Enterprise Architecture Methodologies
1095:
ISO/IEC/IEEE 42010:2011, Systems and so— Architecture description
461:
237:, but some have sprung from international or national efforts in
1367:
Research Trends in Science, Technology and Mathematics Education
129:
of physically intensive systems, viewpoints often correspond to
1650:
1589:
919:
Functional Dataflow view – An abstract view that describes the
656:
648:
276:
183:
138:
1218:
365:
viewpoint model, or a view of the system from that viewpoint.
1850:
1200:"Toward a Framework for Modeling Space Systems Architectures"
1062:
744:
439:. The Three schema approach defines three schemas and views:
179:
175:
1547:
Towards a Framework for Modeling Space Systems Architectures
1160:, J. Kramer, B. Nuseibeh, L. Finkelstein, and M. Goedicke. "
306:
carried out?” They are most easily developed by experts in
2061:
894:
512:
505:
484:
469:
269:
Systems and software engineering — Architecture description
242:
167:
31:
973:
MBED Top Level Ontology based on the Nominal set of views.
133:
and responsibilities within the engineering organization.
559:
1394:
Integration Definition for Information Modeling (IDEFIX)
780:
452:
Internal schema that defines physical storage structures
1577:
523:
The four views of the model are concerned with :
158:
Architecture description practices, as described in
1263:Understanding the Model Driven Architecture (MDA)
495:
456:At the center, the conceptual schema defines the
2162:
1431:A Tutorial on the Zachman Architecture Framework
1151:
1135:
886:Metamodel view – An abstract view that defines
58:is a framework which defines a coherent set of
16:Framework for enterprise and system engineering
1578:National Institute of Standards and Technology
909:Reference Architecture for Space Data Systems.
725:(DoDAF) defines a standard way to organize an
423:, which determined three levels to model data.
405:
1616:
574:Architecture Frameworks are commonly used in
398:is shared across several views and products.
723:Department of Defense Architecture Framework
1523:
1521:
1519:
1517:
1129:Concepts for Automating Systems Integration
840:Illustration of the "Nominal set of views".
384:
1623:
1609:
1545:Peter Shames & Joseph Skipper (2006).
1280:Treasury Enterprise Architecture Framework
1146:IEEE Transactions on Software Engineering,
1122:
1120:
1118:
1116:
1114:
1112:
1110:
1058:Treasury Enterprise Architecture Framework
1541:
1539:
1537:
1471:Federal Enterprise Architecture Framework
1429:US Department of Veterans Affairs (2008)
1228:
1814:Software development process/methodology
1630:
1514:
1496:
1494:
1412:
1410:
968:
927:Functional Control view – Describes the
904:
893:Information view – Describes the actual
835:
792:
739:
642:
597:
520:development, process and physical view:
499:
414:
410:
371:
333:
233:. Many of these have been funded by the
166:using multiple views include Kruchten's
90:, but are usually called "view models".
25:
1378:Gad Ariav & James Clifford (1986).
1344:
1330:Matthew West and Julian Fowler (1999).
1194:
1107:
1089:
823:
2163:
1534:
1502:DoD Architecture Framework Version 1.5
1192:
1190:
1188:
1186:
1184:
1182:
1180:
1178:
1176:
1174:
560:Types of enterprise architecture views
421:ANSI/X3/SPARC three-level architecture
1604:
1491:
1416:Kruchten, Philippe (1995, November).
1407:
1385:
1356:
1272:
781:Federal Enterprise Architecture views
2135:
1829:Software verification and validation
1732:Component-based software engineering
1324:
593:
282:
210:in this paper was to distinguish "a
62:to be used in the construction of a
1332:Developing High Quality Data Models
1171:
235:United States Department of Defense
13:
865:Requirements view – Describes the
359:
301:a particular organization. In the
88:enterprise architecture frameworks
14:
2192:
1809:Software configuration management
1676:Search-based software engineering
1661:Experimental software engineering
1582:
1043:Enterprise architecture framework
565:Enterprise architecture framework
34:Matrix of Views and Perspectives.
2145:
2144:
2134:
1588:
1572: This article incorporates
1567:
1420:IEEE Software 12 (6), pp. 42-50.
1053:Software development methodology
105:is related to view definitions.
1482:
1464:
1443:
1423:
1372:
1301:
1292:
1126:Edward J. Barkmeyer ea (2003).
798:Federal Enterprise Architecture
787:Federal Enterprise Architecture
638:
602:Simplified illustration of the
1656:Empirical software engineering
1353:. Retrieved 30 September 2008.
1255:
1212:
1198:Peter Shames, Joseph Skipper.
1098:
1073:Ontology (information science)
768:Technical Standards View (TV).
716:
496:4+1 view model of architecture
443:External schema for user views
1:
1083:
858:Organization view – Includes
313:
1681:Site reliability engineering
628:specifications, and models.
515:is a view model designed by
449:integrates external schemata
7:
1686:Social software engineering
1476:September 16, 2008, at the
1048:Organizational architecture
1036:
508:view model or architecture.
406:Types of system view models
108:
21:View model (disambiguation)
10:
2199:
1824:Software quality assurance
1337:December 21, 2008, at the
765:Systems View (SV), and the
756:Overarching All View (AV),
620:, originally conceived by
588:U.S. Department of Defense
189:
18:
2130:
2089:
2054:
1993:
1907:
1900:
1859:
1719:
1638:
808:Segment architecture, and
1980:Model-driven engineering
1779:Functional specification
1762:Software incompatibility
1671:Requirements engineering
1365:(2004). . published in:
1351:STRAP SECTION 2 APPROACH
1282:. Version 1, July 2000.
1261:Sinan Si Alhir (2003). "
949:solar pressure, gravity)
845:layered representation.
805:Enterprise architecture,
435:as the key to achieving
391:architecture description
385:Architecture description
308:functional decomposition
2171:Enterprise architecture
1774:Enterprise architecture
1508:March 11, 2005, at the
1440:. Accessed 06 Dec 2008.
1318:March 16, 2007, at the
727:enterprise architecture
679:computational viewpoint
633:enterprise architecture
569:enterprise architecture
287:
265:ISO/IEC/IEEE 42010:2011
227:architecture frameworks
164:architecture frameworks
84:architecture frameworks
72:enterprise architecture
1985:Round-trip engineering
1742:Backward compatibility
1737:Software compatibility
1574:public domain material
1436:July 13, 2007, at the
1148:SE-3(1), January 1977.
974:
910:
841:
811:Solution architecture.
801:
748:
652:
613:
576:Information technology
509:
424:
377:
56:enterprise engineering
35:
1804:Software architecture
1757:Forward compatibility
1529:FEA Practice Guidance
1286:18 March 2009 at the
1078:Knowledge acquisition
978:Engineering viewpoint
972:
908:
881:Information viewpoint
839:
800:levels and attributes
796:
747:linkages among views.
743:
686:engineering viewpoint
672:information viewpoint
646:
601:
552:In addition selected
503:
429:Three-schema approach
418:
411:Three-schema approach
375:
339:Modeling perspectives
334:Modeling perspectives
68:software architecture
29:
2176:Software engineering
2102:Computer engineering
1799:Software archaeology
1789:Programming paradigm
1701:Software maintenance
1646:Computer programming
1632:Software engineering
1597:at Wikimedia Commons
1391:itl.nist.gov (1993)
1223:. pp. 199–208.
1014:Technology viewpoint
914:Functional viewpoint
853:Enterprise Viewpoint
824:Nominal set of views
731:systems architecture
693:technology viewpoint
665:enterprise viewpoint
504:Illustration of the
478:application programs
328:architectural models
255:stakeholder concerns
212:representation style
52:software engineering
44:viewpoints framework
19:For other uses, see
2181:Systems engineering
2122:Systems engineering
2107:Information science
1887:Service orientation
1839:Structured analysis
1747:Compatibility layer
1691:Software deployment
1312:Conceptual modeling
1267:Methods & Tools
921:functional elements
354:information systems
251:system architecture
207:Anthony Finkelstein
201:How do we look at ?
64:system architecture
48:systems engineering
2112:Project management
1877:Object orientation
1844:Essential analysis
1752:Compatibility mode
1552:2010-05-27 at the
1457:2008-04-09 at the
1400:2013-12-03 at the
1239:10.1109/RE.2005.23
1205:2009-02-27 at the
975:
936:Physical viewpoint
911:
842:
802:
749:
653:
614:
580:Information system
510:
425:
378:
324:IEEE-Std-1471-2000
247:IEEE Std 1471-2000
160:IEEE Std 1471-2000
152:viewpoint language
36:
2158:
2157:
2085:
2084:
2026:Information model
1930:Incremental model
1784:Modeling language
1593:Media related to
1248:978-0-7695-2425-2
1168:2(1):31-58, 1992.
1068:Zachman Framework
888:information model
874:scenario planning
735:operational views
618:Zachman Framework
604:Zachman Framework
594:Zachman Framework
517:Philippe Kruchten
447:Conceptual schema
396:architecture data
349:is representing.
303:Zachman Framework
283:View model topics
172:Zachman Framework
123:separate concerns
2188:
2148:
2147:
2138:
2137:
2097:Computer science
1905:
1904:
1819:Software quality
1711:Systems analysis
1706:Software testing
1625:
1618:
1611:
1602:
1601:
1592:
1571:
1570:
1557:
1543:
1532:
1525:
1512:
1504:. 23 April 2007
1498:
1489:
1486:
1480:
1468:
1462:
1447:
1441:
1427:
1421:
1414:
1405:
1389:
1383:
1376:
1370:
1360:
1354:
1348:
1342:
1328:
1322:
1305:
1299:
1296:
1290:
1276:
1270:
1259:
1253:
1252:
1232:
1216:
1210:
1196:
1169:
1155:
1149:
1139:
1133:
1124:
1105:
1102:
1096:
1093:
775:operational view
760:Operational View
534:Development view
490:computer storage
437:data integration
433:conceptual model
168:"4+1" view model
2198:
2197:
2191:
2190:
2189:
2187:
2186:
2185:
2161:
2160:
2159:
2154:
2126:
2117:Risk management
2081:
2050:
1989:
1970:Waterfall model
1940:Prototype model
1935:Iterative model
1896:
1872:Aspect-oriented
1855:
1834:Software system
1715:
1696:Software design
1634:
1629:
1585:
1568:
1560:
1554:Wayback Machine
1544:
1535:
1526:
1515:
1510:Wayback Machine
1499:
1492:
1487:
1483:
1478:Wayback Machine
1469:
1465:
1459:Wayback Machine
1448:
1444:
1438:Wayback Machine
1428:
1424:
1415:
1408:
1402:Wayback Machine
1390:
1386:
1377:
1373:
1361:
1357:
1349:
1345:
1339:Wayback Machine
1329:
1325:
1320:Wayback Machine
1306:
1302:
1297:
1293:
1288:Wayback Machine
1277:
1273:
1260:
1256:
1249:
1217:
1213:
1207:Wayback Machine
1197:
1172:
1156:
1152:
1142:Douglas T. Ross
1140:
1136:
1125:
1108:
1103:
1099:
1094:
1090:
1086:
1039:
826:
783:
719:
641:
596:
562:
498:
413:
408:
387:
362:
360:Viewpoint model
336:
316:
290:
285:
196:Douglas T. Ross
192:
115:complex systems
111:
24:
17:
12:
11:
5:
2196:
2195:
2184:
2183:
2178:
2173:
2156:
2155:
2153:
2152:
2142:
2131:
2128:
2127:
2125:
2124:
2119:
2114:
2109:
2104:
2099:
2093:
2091:
2090:Related fields
2087:
2086:
2083:
2082:
2080:
2079:
2074:
2069:
2064:
2058:
2056:
2052:
2051:
2049:
2048:
2043:
2038:
2033:
2028:
2023:
2021:Function model
2018:
2013:
2008:
2003:
1997:
1995:
1991:
1990:
1988:
1987:
1982:
1977:
1972:
1967:
1962:
1957:
1952:
1947:
1942:
1937:
1932:
1927:
1925:Executable UML
1922:
1917:
1911:
1909:
1902:
1898:
1897:
1895:
1894:
1889:
1884:
1879:
1874:
1869:
1863:
1861:
1857:
1856:
1854:
1853:
1848:
1847:
1846:
1836:
1831:
1826:
1821:
1816:
1811:
1806:
1801:
1796:
1791:
1786:
1781:
1776:
1771:
1766:
1765:
1764:
1759:
1754:
1749:
1744:
1734:
1729:
1723:
1721:
1717:
1716:
1714:
1713:
1708:
1703:
1698:
1693:
1688:
1683:
1678:
1673:
1668:
1666:Formal methods
1663:
1658:
1653:
1648:
1642:
1640:
1636:
1635:
1628:
1627:
1620:
1613:
1605:
1599:
1598:
1584:
1583:External links
1581:
1565:
1564:
1559:
1558:
1556:. 25 May 2006.
1533:
1513:
1490:
1481:
1463:
1442:
1422:
1406:
1404:. 21 Dec 1993.
1384:
1371:
1355:
1343:
1323:
1300:
1298:IEEE-1471-2000
1291:
1271:
1254:
1247:
1230:10.1.1.78.4594
1211:
1170:
1158:A. Finkelstein
1150:
1134:
1106:
1097:
1087:
1085:
1082:
1081:
1080:
1075:
1070:
1065:
1060:
1055:
1050:
1045:
1038:
1035:
1030:
1029:
1025:
1021:
1016:
1015:
1011:
1010:
1007:
1003:
1000:
997:
993:
989:
985:
980:
979:
967:
966:
962:
958:
954:
950:
946:
943:
938:
937:
933:
932:
925:
916:
915:
903:
902:
891:
883:
882:
878:
877:
870:
863:
860:organizational
855:
854:
825:
822:
813:
812:
809:
806:
782:
779:
770:
769:
766:
763:
757:
718:
715:
714:
713:
710:
707:
704:
697:
696:
689:
682:
675:
668:
640:
637:
595:
592:
561:
558:
550:
549:
543:
537:
531:
497:
494:
472:stored in the
454:
453:
450:
444:
412:
409:
407:
404:
386:
383:
361:
358:
335:
332:
315:
312:
289:
286:
284:
281:
231:viewpoint sets
191:
188:
143:specifications
110:
107:
15:
9:
6:
4:
3:
2:
2194:
2193:
2182:
2179:
2177:
2174:
2172:
2169:
2168:
2166:
2151:
2143:
2141:
2133:
2132:
2129:
2123:
2120:
2118:
2115:
2113:
2110:
2108:
2105:
2103:
2100:
2098:
2095:
2094:
2092:
2088:
2078:
2075:
2073:
2070:
2068:
2065:
2063:
2060:
2059:
2057:
2053:
2047:
2044:
2042:
2041:Systems model
2039:
2037:
2034:
2032:
2029:
2027:
2024:
2022:
2019:
2017:
2014:
2012:
2009:
2007:
2004:
2002:
1999:
1998:
1996:
1992:
1986:
1983:
1981:
1978:
1976:
1973:
1971:
1968:
1966:
1963:
1961:
1958:
1956:
1953:
1951:
1948:
1946:
1943:
1941:
1938:
1936:
1933:
1931:
1928:
1926:
1923:
1921:
1918:
1916:
1913:
1912:
1910:
1908:Developmental
1906:
1903:
1899:
1893:
1890:
1888:
1885:
1883:
1880:
1878:
1875:
1873:
1870:
1868:
1865:
1864:
1862:
1858:
1852:
1849:
1845:
1842:
1841:
1840:
1837:
1835:
1832:
1830:
1827:
1825:
1822:
1820:
1817:
1815:
1812:
1810:
1807:
1805:
1802:
1800:
1797:
1795:
1792:
1790:
1787:
1785:
1782:
1780:
1777:
1775:
1772:
1770:
1769:Data modeling
1767:
1763:
1760:
1758:
1755:
1753:
1750:
1748:
1745:
1743:
1740:
1739:
1738:
1735:
1733:
1730:
1728:
1725:
1724:
1722:
1718:
1712:
1709:
1707:
1704:
1702:
1699:
1697:
1694:
1692:
1689:
1687:
1684:
1682:
1679:
1677:
1674:
1672:
1669:
1667:
1664:
1662:
1659:
1657:
1654:
1652:
1649:
1647:
1644:
1643:
1641:
1637:
1633:
1626:
1621:
1619:
1614:
1612:
1607:
1606:
1603:
1596:
1591:
1587:
1586:
1580:
1579:
1576:from the
1575:
1562:
1561:
1555:
1551:
1548:
1542:
1540:
1538:
1530:
1524:
1522:
1520:
1518:
1511:
1507:
1503:
1497:
1495:
1485:
1479:
1475:
1472:
1467:
1460:
1456:
1453:
1452:
1446:
1439:
1435:
1432:
1426:
1419:
1413:
1411:
1403:
1399:
1396:
1395:
1388:
1381:
1375:
1368:
1364:
1359:
1352:
1347:
1340:
1336:
1333:
1327:
1321:
1317:
1313:
1309:
1308:John Krogstie
1304:
1295:
1289:
1285:
1281:
1275:
1268:
1264:
1258:
1250:
1244:
1240:
1236:
1231:
1226:
1222:
1215:
1208:
1204:
1201:
1195:
1193:
1191:
1189:
1187:
1185:
1183:
1181:
1179:
1177:
1175:
1167:
1163:
1159:
1154:
1147:
1143:
1138:
1131:
1130:
1123:
1121:
1119:
1117:
1115:
1113:
1111:
1101:
1092:
1088:
1079:
1076:
1074:
1071:
1069:
1066:
1064:
1061:
1059:
1056:
1054:
1051:
1049:
1046:
1044:
1041:
1040:
1034:
1026:
1022:
1018:
1017:
1013:
1012:
1008:
1006:requirements.
1004:
1001:
998:
994:
990:
986:
982:
981:
977:
976:
971:
963:
959:
955:
951:
947:
944:
940:
939:
935:
934:
930:
929:control flows
926:
922:
918:
917:
913:
912:
907:
900:
896:
892:
889:
885:
884:
880:
879:
875:
871:
868:
864:
861:
857:
856:
852:
851:
850:
846:
838:
834:
832:
821:
817:
810:
807:
804:
803:
799:
795:
791:
788:
778:
776:
767:
764:
761:
758:
755:
754:
753:
746:
742:
738:
736:
732:
728:
724:
711:
708:
705:
702:
701:
700:
694:
690:
687:
683:
680:
676:
673:
669:
666:
662:
661:
660:
658:
650:
645:
636:
634:
629:
625:
623:
619:
611:
610:
605:
600:
591:
589:
585:
584:system design
581:
577:
572:
570:
566:
557:
555:
547:
546:Physical view
544:
541:
538:
535:
532:
529:
526:
525:
524:
521:
518:
514:
507:
502:
493:
491:
486:
481:
479:
475:
471:
467:
463:
459:
451:
448:
445:
442:
441:
440:
438:
434:
430:
422:
417:
403:
399:
397:
392:
382:
374:
370:
366:
357:
355:
350:
348:
344:
340:
331:
329:
325:
320:
311:
309:
304:
299:
294:
280:
278:
274:
270:
266:
262:
258:
256:
252:
248:
244:
240:
236:
232:
229:or sometimes
228:
223:
221:
217:
216:specification
213:
208:
203:
202:
197:
187:
185:
181:
177:
173:
169:
165:
161:
156:
153:
148:
144:
140:
134:
132:
128:
124:
120:
116:
106:
104:
100:
96:
91:
89:
85:
79:
77:
73:
69:
65:
61:
57:
53:
49:
45:
41:
33:
28:
22:
2045:
2036:Object model
2031:Metamodeling
1960:Spiral model
1860:Orientations
1566:
1484:
1466:
1450:
1445:
1425:
1393:
1387:
1379:
1374:
1366:
1363:John F. Sowa
1358:
1346:
1326:
1303:
1294:
1274:
1269:. Fall 2003.
1266:
1257:
1220:
1214:
1209:. NASA, JPL.
1165:
1153:
1145:
1137:
1128:
1100:
1091:
1031:
1024:testing lab)
984:requirements
924:implemented.
867:requirements
847:
843:
827:
818:
814:
784:
771:
750:
720:
698:
692:
685:
678:
671:
664:
654:
639:RM-ODP views
630:
626:
622:John Zachman
615:
608:
573:
563:
551:
545:
540:Process view
539:
533:
528:Logical view
527:
522:
511:
482:
455:
426:
400:
395:
388:
379:
367:
363:
351:
337:
321:
317:
295:
291:
273:stakeholders
268:
259:
230:
224:
215:
211:
204:
200:
193:
157:
151:
135:
131:capabilities
112:
102:
98:
94:
92:
80:
75:
59:
43:
39:
37:
1727:Abstraction
1595:View models
1563:Attribution
1500:DoD (2007)
992:discipline.
953:attachment)
899:information
717:DoDAF views
343:perspective
199:determines
127:engineering
2165:Categories
2046:View model
2011:Data model
1310:, (2003).
1132:NIST 2003.
1084:References
1020:processes.
965:components
785:In the US
314:Viewpoints
103:view model
99:definition
93:Usually a
40:view model
2055:Languages
1225:CiteSeerX
831:IEEE 1471
554:use cases
261:IEEE 1471
220:IEEE 1471
125:. In the
119:expertise
2150:Category
2016:ER model
1882:Ontology
1794:Software
1720:Concepts
1550:Archived
1506:Archived
1474:Archived
1455:Archived
1434:Archived
1398:Archived
1335:Archived
1316:Archived
1284:Archived
1203:Archived
1037:See also
729:(EA) or
474:database
462:concepts
458:ontology
147:business
109:Overview
2140:Commons
1965:V-model
1265:". In:
996:system.
942:system.
464:as the
460:of the
241:or the
190:History
121:and to
1901:Models
1651:DevOps
1639:Fields
1245:
1227:
961:plane)
957:shade)
657:RM-ODP
649:RM-ODP
277:RM-ODP
184:RM-ODP
182:, and
170:, the
139:system
70:, or
54:, and
2077:SysML
2001:SPICE
1994:Other
1955:Scrum
1915:Agile
1867:Agile
1851:CI/CD
1063:TOGAF
762:(OV),
745:DoDAF
466:users
347:model
263:(now
180:DoDAF
176:TOGAF
60:views
2062:IDEF
2006:CMMI
1892:SDLC
1243:ISBN
897:and
895:data
721:The
691:the
684:the
677:the
670:the
663:the
647:The
616:The
609:here
578:and
485:data
470:data
427:The
298:view
288:View
243:IEEE
145:. A
95:view
76:view
74:. A
32:TEAF
30:The
2072:USL
2067:UML
1945:RAD
1920:EUP
1235:doi
1164:."
513:4+1
506:4+1
389:An
352:In
239:ISO
141:'s
86:or
46:in
42:or
2167::
1975:XP
1950:UP
1536:^
1516:^
1493:^
1409:^
1314:,
1241:.
1233:.
1173:^
1109:^
833:.
296:A
267:,
186:.
178:,
174:,
66:,
50:,
38:A
1624:e
1617:t
1610:v
1531:.
1251:.
1237::
612:.
23:.
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.
