TOGAF1
- Scope of organizations impacted
- Maturity assessment, gaps, and resolution approach
- Roles and responsibilities for architecture team(s)
- Constraints on architecture work
- Re-use requirements
- Budget requirements
- Requests for change
- Governance and support strategy
- Architecture Principles
- Identify the key stakeholders and their concerns/objectives, and define the key business requirements to be addressed in the architecture engagement.
- Based on the stakeholder concerns, business capability requirements, scope, constraints, and principles, create a high-level view of the Baseline and Target Architectures. The Architecture Vision typically covers the breadth of scope identified for the project, at a high level. Informal techniques are often employed. A common practice is to draw a simple solution concept diagram that illustrates concisely the major components of the solution and how the solution will result in benefit for the enterprise.
- Develop the business case for the architectures and changes required
- Produce the value proposition for each of the stakeholder groupings
- Assess and define the procurement requirements
- Review and agree the value propositions with the sponsors and stakeholders concerned
- Define the performance metrics and measures to be built into the Enterprise Architecture to meet the business needs
- Identify new work products that will need to be changed
- Provide direction on which existing work products, including building blocks, will need to be changed and ensure that all activities and dependencies on these are co-ordinated
- Identify the impact of change on other work products and dependence on their activities
- Based on the purpose, focus, scope, and constraints, determine which architecture domains should be developed, to what level of detail, and which architecture views should be built
- Assess the resource requirements and availability to perform the work in the timescale required; this will include adhering to the organization's planning methods and work products to produce the plans for performing a cycle of the ADM
- Estimate the resources needed, develop a roadmap and schedule for the proposed development, and document all these in the Statement of Architecture Work
- Define the performance metrics to be met during this cycle of the ADM by the Enterprise Architecture team
- Develop the specific Enterprise Architecture Communications Plan and show where, how, and when the Enterprise Architects will communicate with the stakeholders, including affinity groupings and communities, about the progress of the Enterprise Architecture developments
- Review and agree the plans with the sponsors, and secure formal approval of the Statement of Architecture Work under the appropriate governance procedures
- Gain sponsor's sign-off to proceed
- Deliverables
- Architecture project description and scope
- Overview of Architecture Vision
- Architecture project plan and schedule
- Architecture Principles
- Capability Assessment
- Architecture Vision -Architecture Vision describes how the new capability will meet the business goals and strategic objectives and address the stakeholder concerns when implemented. The Architecture Vision provides a first-cut, high-level description of the Baseline and Target Architectures, covering the business, data, application, and technology domains. These outline descriptions are developed in subsequent phases.
- Problem description
- Objective of the Statement of Architecture Work
- Summary views
- Business Scenario (optional)
- Refined key high-level stakeholder requirements
- In addition, the Architecture Vision explores other domains
- Information
- Security
- Digital
- Network Management
- Knowledge
- Industry-specific
- Services
- Partnership
- Cybersecurity
- Business Architecture
- Business scenarios are a useful technique to discover and document business requirements, and may be used iteratively, at different levels of detail in the hierarchical decomposition of the Business Architecture. The Business Architecture phase therefore needs to identify which components of the architecture are functions and which are services. Services are distinguished from functions through the explicit definition of a service contract. A service contract covers the business/functional interface and also the technology/data interface. The Business Architecture will define the service contract at the business/functional level, which will be expanded on in the Application and Technology Architecture phases.
- Business Capability Mapping: identifies, categorizes, and decomposes the business capabilities required for the business to have the ability to deliver value to one or more stakeholders.
- Use-case Analysis: the breakdown of business-level functions across actors and organizations allows the actors in a function to be identified and permits a breakdown into services supporting/delivering that functional capability.
- Process Modeling: the breakdown of a function or business service through process modeling allows the elements of the process to be identified, and permits the identification of lower-level business services or functions
- Data Architecture
- During the Business Architecture phase, a Business Service/Information diagram was created showing the key data entities required by the main business services. This is a prerequisite to successful Data Architecture activities.
- Data Entity/Data Component catalog
- Data Entity/Business Function (showing which data supports which functions and which business function owns which data)
- Application/Data (developed across the Application Architecture and Data Architecture phases)
- Conceptual Data diagram
- Logical Data diagram
- Data Dissemination diagram
- Data Lifecycle diagram
- Data Security diagram
- Data Migration diagram
- Does this Data Architecture create an impact on any pre-existing architectures?
- Will this Data Architecture be impacted by other projects ?
- When an existing application is replaced, there will be a critical need to migrate data (master, transactional, and reference) to the new application. The Data Architecture should identify data migration requirements and also provide indicators as to the level of transformation, weeding, and cleansing that will be required to present data in a format that meets the requirements and constraints of the target application.
- Application Architecture
- The recommended process for developing an Application Architecture is as follows:
- Simplify complicated applications by decomposing them into two or more applications.
- Ensure that the set of application definitions is internally consistent, by removing duplicate functionality as far as possible, and combining similar applications into one
- Develop matrices across the architecture by relating applications to business service, business function, data, process, etc.
- Application Portfolio catalog
- Interface catalog
- Application/Organization matrix
- Role/Application matrix
- Application Interaction matrix
- Application/Function matrix
- Application Communication diagram
- Application and User Location diagram
- Enterprise Manageability diagram
- Process/Application Realization diagram
- Application Migration diagram
- Software Distribution diagram
- Software Engineering diagram
- Application Use-Case diagram
- Technical Architecture - The areas where the Technology Architecture may be impacted will include the following:
- Coarse-grained services contain several units of functionality with potentially varying non-functional requirements, so platform performance should be considered.
- if service granularity is too coarse, then introducing changes to that service becomes difficult and impacts the maintenance of the service and the platform on which it is delivered
- Product selection processes may occur within the Technology Architecture phase where existing products are re-used, incremental capacity is being added, or product selection decisions are a constraint during project initiation.
- Technology standards
- Technology portfolio
- Application/Technology matrix
- Environments and Locations diagram
- Platform Decomposition diagram
- Processing diagram
- Networked Computing/Hardware diagram
- Network and Communications diagram
- Fundamental functionality and attributes - semantic, unambiguous including security capability and manageability
- Dependent building blocks with required functionality and named interfaces
- Interfaces - chosen set, supplied (APIs, data formats, protocols, hardware interfaces, standards)
- Map to business/organizational entities and policies
- Technology Components and their relationships to information systems
- Technology platforms and their decomposition, showing the combinations of technology required to realize a particular technology "stack"
- Environments and locations - a grouping of the required technology into computing environments (e.g., development, production)
- Expected processing load and distribution of load across technology components
- Physical (network) communications
- Hardware and network specifications
- Create an overall Implementation and Migration Strategy that will guide the implementation of the Target Architecture, and structure any Transition Architectures. The first activity is to determine an overall strategic approach to implementing the solutions and/or exploiting opportunities. There are three basic approaches as follows:
- Greenfield: a completely new implementation
- Revolutionary: a radical change (i.e., switch on, switch off)
- Evolutionary: a strategy of convergence, such as parallel running or a phased approach to introduce new capabilities
- Where the scope of change to implement the Target Architecture requires an incremental approach, then one or more Transition Architectures may be necessary. These provide an ability to identify clear targets along the roadmap to realizing the Target Architecture. The Transition Architectures should provide measurable business value. The time-span between successive Transition Architectures does not have to be of uniform duration.
- Recommendations on service delivery requirements
- Recommendations on performance metrics
- Service-Level Agreements (SLAs)
Name | Should both represent the essence of the rule as well as be easy to remember. Specific technology platforms should not be mentioned in the name or statement of a principle. Avoid ambiguous words in the Name and in the Statement such as: "support", "open", "consider", and for lack of good measure the word "avoid", itself, be careful with "manage(ment)", and look for unnecessary adjectives and adverbs (fluff). |
Statement | Should succinctly and unambiguously communicate the fundamental rule. For the most part, the principles statements for managing information are similar from one organization to the next. It is vital that the principles statement is unambiguous. |
Rationale | Should highlight the business benefits of adhering to the principle, using business terminology. Point to the similarity of information and technology principles to the principles governing business operations. Also describe the relationship to other principles, and the intentions regarding a balanced interpretation. Describe situations where one principle would be given precedence or carry more weight than another for making a decision. |
Implications | Should highlight the requirements, both for the business and IT, for carrying out the principle - in terms of resources, costs, and activities/tasks. It will often be apparent that current systems, standards, or practices would be incongruent with the principle upon adoption. The impact to the business and consequences of adopting a principle should be clearly stated. The reader should readily discern the answer to: "How does this affect me?". It is important not to oversimplify, trivialize, or judge the merit of the impact. Some of the implications will be identified as potential impacts only, and may be speculative rather than fully analyzed. |
There are five criteria that distinguish a good set of principles:
- Understandable: the underlying tenets can be quickly grasped and understood by individuals throughout the organization
The intention of the principle is clear and unambiguous, so that violations, whether intentional or not, are minimized.
- Robust: enable good quality decisions about architectures and plans to be made, and enforceable policies and standards to be created
Each principle should be sufficiently definitive and precise to support consistent decision-making in complex, potentially controversial situations.
- Complete: every potentially important principle governing the management of information and technology for the organization is defined - the principles cover every situation perceived
- Consistent: strict adherence to one principle may require a loose interpretation of another principle
The set of principles must be expressed in a way that allows a balance of interpretations. Principles should not be contradictory to the point where adhering to one principle would violate the spirit of another. Every word in a principle statement should be carefully chosen to allow consistent yet flexible interpretation.
- Stable: principles should be enduring, yet able to accommodate changes
Principles
Maximize Benefit to the Enterprise
: Business Continuity
Service Orientation
Data is an Asset
Data is Shared
Data is Accessible
Data Trustee
Data Security
Technology Independence
Control Technical Diversity
Interoperability
Comments
Post a Comment