Talk:Architecture domain

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

content from the main Enterprise Architecture article[edit]

The main article on Enterprise Architecture attempted to duplicate the notion of domains with content. Rather than having the same information in two articles, I'm moving the notion of 'domains' to this article and will improve the references from the main article to this location. The information copied from the main page follows. Nickmalik (talk) 08:53, 14 December 2011 (UTC)[reply]


Several enterprise architecture frameworks break down the practice of enterprise architecture into a number of practice areas or domains. In his book on Enterprise Architecture, Spewak divides the practice into two domains at 'level 2': business modelling and current systems and technology, and three subordinate domains at 'level 3': data architecture, applications architecture, and technology architecture. The final level of Spewak's EAP is the implementation or methods level, which deals with "how" to migrate the Enterprise to match the new model.[1]

The popular TOGAF framework divides the practice into three domains: business architecture, information systems architecture and technology architecture—and then subdivides the information systems architecture into information architecture and applications architecture.[2]

The Strategic Architecture model allows for a flexible division into up to ten domains covering many aspects of an enterprise from its objectives and goals through its projects and programmes to its software applications and technology.[3]

EA Domains: An enterprise architecture’s landscape is usually divided into various domains based on the attributes of the environment and the logical grouping based on Industry EA Frameworks

The dividing of the practice into a number of domains allows enterprise architects to describe an enterprise from a number of important perspectives. This practice also encourages the contributions of many individuals and allows the practice as a whole to make good use of individual domain-specific expertise and knowledge. By taking this approach, enterprise architects can ensure a holistic description is produced.

The popular and most common four domains and their component parts look like this:

1. Business:

    1. Strategy maps, goals, corporate policies, Operating Model
    2. Functional decompositions (e.g. IDEF0, SADT), business capabilities and organizational models expressed as enterprise / line of business architecture
    3. Business processes, Workflow and Rules that articulate the assigned authorities, responsibilities and policies
    4. Organization cycles, periods and timing
    5. Suppliers of hardware, software, and services

2. Information:

    1. Information architecture - a holistic view on the flow of information in an enterprise
    2. Data Architecture- describes the way data will be processed, stored , data flows and used by the projects teams that will use it
    3. Master Data Management, is the authoritative, reliable foundation for data used across many applications and business processes with the goal to provide a single view of the truth no matter where the data is located
    4. Metadata - data that describes your enterprise data elements
    5. Business Intelligence Analytics & Reporting BI (Business Intelligence) is a broad category of applications and technologies for gathering, storing, analyzing, and providing access to data to help the organization users make better business decisions. These include the activities of decision support systems, query and reporting, dashboards , scorecards ,statistical analysis, forecasting, and data mining. This includes Reporting Data Stores ( Operational Data Store (ODS), Datamart and DataWarehouses)
    6. Data Quality helps identify, analyze, improve, and measure the data quality and data integrity issues and improvement efforts
    7. Data models: conceptual expressed as enterprise information architectures, logical, and physical
    8. Data Life Cycle Management Processes to govern how to create, classify, update, use, distribute, and archive, and obsolete data and information
Layers of the enterprise architecture.[4]

3. Applications:

    1. Application software inventories and diagrams, expressed as conceptual / functional or system enterprise / line of business architectures
    2. Interfaces between applications - that is: events, messages

4. Technology:

    1. Inter-application mediating software or 'middleware'.
    2. Application execution environments and operating frameworks including applications server environments and operating systems, authentication and authorisation environments, security systems and operating and monitoring systems.
    3. Hardware, platforms, and hosting: servers, datacentres and computer rooms
    4. Local and wide area networks, Internet connectivity diagrams
    5. Intranet, Extranet, Internet, eCommerce, EDI links with parties within and outside of the organization
    6. Operating System
    7. Infrastructure software: Application servers, DBMS
    8. Programming Languages, etc. expressed as enterprise / line of business technology architecture.
Good idea about isolating the Domain-specific content, Nickmalik. The Open Grouop serves as a good reference. We should also consider talking about architecture partitioning - TOGAF concept, which is similar to Architecture Domain but more business-oriented. Voywiki (talk) 13:13, 4 June 2014 (UTC)[reply]

References

  1. ^ Spewak, Steven H. and Hill, Steven C. , Enterprise Architecture Planning - Developing a Blueprint for Data Applications and Technology,(1992), John Wiley
  2. ^ The Open Group Architectural Framework (TOGAF) 8.1.1, (2009), opengroup.org
  3. ^ The Open Group Architectural Framework (TOGAF) 8.1.1, (2009), opengroup.org
  4. ^ Niles E Hewlett (2006) , The USDA Enterprise Architecture Program. PMP CEA, Enterprise Architecture Team, USDA-OCIO. January 25, 2006.