C. Information Systems Architectures

[¤1] C. Information Systems Architectures

[¤2] Phase C: Information System Architectures (Introduction)

[¤3] Objective Approach Inputs Steps Outputs

[¤4] Objective

[¤5] The objective of this phase is to develop target architectures covering either or both (depending on project scope) of the Data and Application Systems domains.

[¤6] The scope of the business processes supported in this phase is limited to those that are supported by information technology, and the interfaces of those IT-related processes to non-IT-related processes.

[¤7] Approach

[¤8] Development

[¤9] This phase involves some combination of Data and Applications Architecture, in either order. Advocates exist for both sequences.

[¤10] For example, Spewak’s Enterprise Architecture Planning recommends a data-driven approach.

[¤11] On the other hand, major applications systems such as those for Enterprise Resource Planning, Customer Relationship Management, etc., often provide a combination of technology infrastructure and business application logic, and some organizations take an application-driven approach, whereby they recognize certain key applications as forming the core underpinning of the mission-critical business processes, and take the implementation and integration of those core applications as the primary focus of architecture effort (the integration issues often constituting a major challenge).

[¤12] Implementation

(m_iacob) Indicate design techniques that can be used in the design of Data and Application Architectures.
[¤13] Implementation of these architectures may not necessarily follow the same order. For example, one common implementation approach is top-down design and bottom-up implementation:

[¤14] Design:

[¤15] Business Architecture design

[¤16] Data (or Applications) architecture design

[¤17] Applications (or Data) architecture design

(chris_blake) Technology Architecture Design
[¤18] Infrastructure Architecture design

[¤19] Implementation:

(chris_blake) Technology Architecture Implementation
[¤20] Infrastructure Architecture implementation

[¤21] Applications (or Data) Architecture implementation

[¤22] Data (or Applications) architecture implementation

[¤23] Business Architecture implementation

[¤24] An alternative approach is a data-driven sequence, whereby application systems that create data are implemented first, then applications that process the data, and finally applications that archive data.

[¤25] Inputs

[¤26] Inputs to this phase are:

[¤27] Applications Principles (if existing)
[¤28] Data Principles (if existing)
[¤29] Request for Architecture Work
[¤30] Statement of Architecture Work
[¤31] Architecture Vision
[¤32] Enterprise Continuum
[¤33] Business Baseline - Version 2 (detailed) - if appropriate
[¤34] Target Business Architecture - Version 2 (detailed)
[¤35] Relevant technical requirements that will apply to this phase
[¤36] Gap analysis (from Business Architecture)
[¤37] Re-usable building blocks (from organization's Architecture Continuum, if available)

[¤38] Steps

[¤39] Detailed steps for this phase are given separately for each architecture domain:

[¤42] Outputs

[¤43] The main outputs are as follows:

[¤44] Statement of Architecture Work (updated if necessary)
[¤45] Target Data Architecture
[¤46] Target Applications Architecture
[¤47] Data Architecture Views corresponding to the selected viewpoints addressing key stakeholder concerns
[¤48] Applications Architecture Views corresponding to the selected viewpoints addressing key stakeholder concerns
[¤49] Data Architecture Report, summarizing what was done and the key findings
[¤50] Applications Architecture Report, summarizing what was done and the key findings
[¤51] Gap analysis
- [¤52] Areas where the Business Architecture may need to change to cater for changes in the Data and/or Applications Architecture
- [¤53] Constraints on the Technology Architecture about to be designed.
[¤54] Impact Analysis
[¤55] Updated business requirements (if appropriate)