TOGAF Certification Series 7: TOGAF® 9 Certified ADM Phases E,F,G,H And Requirements Management

Chapter 9 Phase E: Opportunities & Solutions

  • The objectives of Phase E: Opportunities and Solutions are to:
    • Generate the initial complete version of the Architecture Roadmap, based upon the gap analysis and candidate Architecture Roadmap components from Phases B, C, and D
    • Determine whether an incremental approach is required, and if so identify Transition Architectures that will deliver continuous business value
  • Phase E is a collaborative effort with stakeholders required from both the business and IT sides. It should include both those that implement and those that operate the infrastructure. It should also include those responsible for strategic planning, especially for creating the Transition Architectures, if required.
  • Phase E consists of the following steps:
    • 1. Determine/confirm key corporate change attributes
    • 2. Determine business constraints for implementation
    • 3. Review and consolidate Gap Analysis results from Phases B to D
    • 4. Review consolidated requirements across related business functions
    • 5. Consolidate and reconcile interoperability requirements
    • 6. Refine and validate dependencies
    • 7. Confirm readiness and risk for business transformation
    • 8. Formulate Implementation and Migration Strategy
    • 9. Identify and group major work packages
    • 10. Identify Transition Architectures
    • 11. Create the Architecture Roadmap & Implementation and Migration Plan
  • The most significant issue to be addressed is business interoperability. Most SBBs or COTS will have their own embedded business processes. Changing the embedded business processes will often require so much work, that the advantages of re-using solutions will be lost with updates being costly and possibly requiring a complete rework. Furthermore, there may be a workflow aspect between multiple systems that has to be taken into account. The acquisition of COTS software has to be seen as a business decision that may require rework of the domain architectures. The enterprise architect will have to ensure that any change to the business interoperability requirements is signed off by the business architects and architecture sponsors in a revised Statement of Architecture Work.

Chapter 10 Phase F: Migration Planning

  • The objectives of Phase F: Migration Planning are to:
    • Finalize the Architecture Roadmap and the supporting Implementation and Migration Plan
    • Ensure that the Implementation and Migration Plan is coordinated with the enterprise’s approach to managing and implementing change in the enterprise’s overall change portfolio
    • Ensure that the business value and cost of work packages and Transition Architectures is understood by key stakeholders
  • Phase F consists of the following steps:
    • 1. Confirm management framework interactions for the Implementation and Migration Plan
    • 2. Assign a business value to each work package
    • 3. Estimate resource requirements, project timings, and availability/delivery vehicle
    • 4. Prioritize the migration projects through the conduct of a cost/benefit assessment and risk validation
    • 5. Confirm Architecture Roadmap and update Architecture Definition Document
    • 6. Complete the Implementation and Migration Plan
    • 7. Complete the architecture development cycle and document lessons learned
  • A technique to assess business value is to draw up a matrix based on a value index dimension and a risk index dimension. An example is shown in Figure 12. The value index should include criteria such as compliance to principles, financial contribution, strategic alignment, and competitive position. The risk index should include criteria such as size and complexity, technology, organizational capacity, and impact of a failure. Each criterion should be assigned an individual weight. The index and its criteria and weighting should be developed and approved by senior management. It is important to establish the decision-making criteria before the options are known.

Chapter 11 Phase G: Implementation Governance

  • The objectives of Phase G: Implementation Governance are to:
    • Ensure conformance with the Target Architecture by implementation projects
    • Perform appropriate Architecture Governance functions for the solution and any implementation-driven architecture Change Requests
  • The Architecture Contract produced in this phase features prominently in the area of Architecture Governance (see Chapter 22). It is often used as the means to driving change. In order to ensure that the Architecture Contract is effective and efficient, the following aspects of the governance framework should be introduced in this phase:
    • Simple process
    • People-centered authority
    • Strong communication
    • Timely responses and effective escalation process
    • Supporting organization structures
  • Phase G consists of the following steps:
    • Confirm scope and priorities for deployment with development management
    • Identify deployment resources and skills
    • Guide development of solutions deployment
    • Perform enterprise Architecture Compliance Reviews
    • Implement business and IT operations
    • Perform post-implementation review and close the implementation

Chapter 12 Phase H: Architecture Change Management

  • The objectives of Phase H: Architecture Change Management are to:
    • Ensure that the architecture lifecycle is maintained
    • Ensure that the Architecture Governance Framework is executed
    • Ensure that the enterprise Architecture Capability meets current requirements
  • Phase H consists of the following steps:
    • 1. Establish value realization process
    • 2. Deploy monitoring tools
    • Manage risks
    • 4. Provide analysis for architecture change management
    • 5. Develop change requirements to meet performance targets
    • 6. Manage governance process
    • 7. Activate the process to implement change

Chapter 13 ADM Architecture Requirements Management

  • The objectives of the Requirements Management phase are to:
    • Ensure that the Requirements Management process is sustained and operates for all relevant ADM phases
    • Manage architecture requirements identified during any execution of the ADM cycle or a phase
    • Ensure that relevant architecture requirements are available for use by each phase as the phase is executed

Advertisements

TOGAF Certification Series 5: Building Blocks

Chapter 11 Building Blocks

  • A building block is a package of functionality defined to meet business needs across an organization. A building block has published interfaces to access functionality. A building block may interoperate with other, possibly inter-dependent building blocks.
  • An architecture is a composition of:
    • A set of building blocks depicted in an architectural model
    • A specification of how those building blocks are connected to meet the overall requirements of an information system
  • Architecture Building Blocks (ABBs) are architecture documentation and models from the enterprise’s Architecture Repository classified according to the Architecture Continuum.
  • The characteristics of ABBs are as follows:
    • They define what functionality will be implemented.
    • They capture architecture requirements; e.g., Business, Data, Application, and Technology requirements.
    • They direct and guide the development of Solution Building Blocks
  • The characteristics of ABBs are as follows:
    • They define what functionality will be implemented.
    • They capture architecture requirements; e.g., Business, Data, Application, and Technology requirements.
    • They direct and guide the development of Solution Building Blocks

  • Building blocks are what you use; patterns can tell you how you use them, when, why, and what trade-offs you have to make in doing that. Patterns offer the promise of helping the architect to identify combinations of Architecture and/or Solution Building Blocks (ABBs/SBBs) that have been proven to deliver effective solutions in the past and may provide the basis for effective solutions in the future.

Chapter 12 ADM Deliverables

  • Architecture Building Blocks (ABBs): ABBs are architecture documentation and models from the enterprise’s Architecture Repository.
  • Architecture Contract: Architecture Contracts are the joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture. They are produced in Phase G: Architecture Governance. Successful implementation of these agreements will be delivered through effective Architecture Governance.
  • Architecture Definition Document: The Architecture Definition Document is the deliverable container for the core architectural artifacts created during a project and for important related information. The Architecture Definition Document spans all architecture domains (Business, Data, Application, and Technology) and also examines all relevant states of the architecture (baseline, transition, and target).
  • Architecture Definition Document versus Architecture Requirements Specification The Architecture Definition Document is a companion to the Architecture Requirements Specification, with a complementary objective: The Architecture Definition Document provides a qualitative view of the solution and aims to communicate the intent of the architects. The Architecture Requirements Specification provides a quantitative view of the solution, stating measurable criteria that must be met during the implementation of the architecture.
  • Architecture Requirements Specification: The Architecture Requirements Specification provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture. An Architecture Requirements Specification will typically form a major component of an implementation contract or a contract for more detailed Architecture Definition.
  • Architecture Roadmap: The Architecture Roadmap lists individual work packages that will realize the Target Architecture and lays them out on a timeline to show progression from the Baseline Architecture to the Target Architecture. The Architecture Roadmap highlights individual work packages’ business value at each stage. Transition Architectures necessary to effectively realize the Target Architecture are identified as intermediate steps. The Architecture Roadmap is incrementally developed throughout Phases E and F, and informed by the roadmap components developed in Phases B, C, and D.
  • The Architecture Vision is created in Phase A and provides a high-level summary of the changes to the enterprise that will follow from successful deployment of the Target Architecture.
  • Business principles, business goals, and business drivers provide context for architecture work, by describing the needs and ways of working employed by the enterprise. These will have usually been defined elsewhere in the enterprise prior to the architecture activity. Many factors that lie outside the consideration of architecture discipline may have significant implications for the way that architecture is developed.

Chapter 13 TOGAF Reference Models

  • Major characteristics of a Foundation Architecture include the following:
    • It reflects general computing requirements.
    • It reflects general building blocks.
    • It defines technology standards for implementing these building blocks. It provides direction for products and services.
    • It reflects the function of a complete, robust computing environment that can be used as a foundation.
    • It provides open system standards, directions, and recommendations.
    • It reflects directions and strategies.
  • The TRM has two main components:
    • 1. A taxonomy that defines terminology, and provides a coherent description of the components and conceptual structure of an information system
    • 2. A model, with an associated TRM graphic, that provides a visual representation of the taxonomy, as an aid to understanding

  • The Integrated Information Infrastructure Reference Model: The III-RM is a reference model that focuses on the Application Software space, and is a “Common Systems Architecture” in Enterprise Continuum terms. The III-RM is a subset of the TOGAF TRM in terms of its overall scope, but it also expands certain parts of the TRM – in particular, the business applications and infrastructure applications parts – in order to provide help in addressing one of the key challenges facing the enterprise architect today: the need to design an integrated information infrastructure to enable Boundaryless Information Flow.

  • Boundaryless Information Flow 1. A trademark of The Open Group. 2. A shorthand representation of “access to integrated information to support business process improvements” representing a desired state of an enterprise’s infrastructure specific to the business needs of the organization. An infrastructure that provides Boundaryless Information Flow has open standard components that provide services in a customer’s extended enterprise that:  Combine multiple sources of information  Securely deliver the information whenever and wherever it is needed, in the right context for the people or systems using that information

TOGAF Certification Series 4: The ADM Guidelines and Techniques

Chapter 8 ADM Guidelines and Techniques

  • Architecture Principles: are a set of general rules and guidelines for the architecture being developed. They are intended to be enduring and seldom amended and inform and support the way in which an organization sets about fulfilling its mission. Often, they are one element of a structured set of ideas that collectively define and guide the organization, from values through to actions and results.
  • Enterprise principles provide a basis for decision-making throughout an enterprise and dictate how the organization fulfills its mission. Such principles are commonly used as a means of harmonizing decision-making. They are a key element in a successful Architecture Governance strategy. Within the broad domain of enterprise principles, it is common to have subsidiary principles within a business or organizational unit; for example, IT, HR, domestic operations, or overseas operations.
  • Architecture principles are a set of principles that relate to architecture work. They reflect consensus across the enterprise, and embody the spirit of the enterprise architecture. Architecture principles govern the architecture process, affecting the development, maintenance, and use of the enterprise architecture.
  • The TOGAF Template for Defining Architecture Principles:
    • Name
    • Statement
    • Rationale
    • Implications
  • What Makes a Good Architecture Principle?
    • Understandability
    • Robustness
    • Completeness
    • Consistency
    • Stability
  • Business Scenarios
    • What is a Business Scenario? Business scenarios are a technique used to help identify and understand the business requirements that an architecture must address. A business scenario describes:
      • A business process, application, or set of applications
      • The business and technology environment
      • The people and computing components (“actors”) who execute the scenario
      • The desired outcome of proper execution
    • The technique may be used iteratively, at different levels of detail in the hierarchical decomposition of the Business Architecture. The generic business scenario process is as follows:
      • Identify, document, and rank the problem that is driving the project
      • Document, as high-level architecture models, the business and technical environments where the problem situation is occurring
      • Identify and document desired objectives; the results of handling the problems successfully.
      • Identify human actors and their place in the business model, the human participants, and their roles.
      • Identify computer actors and their place in the technology model, the computing elements, and their roles
      • Identify and document roles, responsibilities, and measures of success per actor, the required scripts per actor, and the desired results of handling the situation properly.
      • Check for fitness-for-purpose of inspiring subsequent architecture work and refine only if necessary.

A good business scenario represents a significant business need or problem and enables vendors to understand the value of a solution to the customer. A good business scenario is also “SMART”:

  • Specific, by defining what needs to be done
  • Measurable, through clear metrics for success
  • Actionable, by clearly segmenting the problem and providing the basis for a solution
  • Realistic, in that the problem can be solved within the bounds of physical reality, time, and cost constraints
  • Time-bound, in that there is a clear statement of when the opportunity expires.
  • Gap Analysis: A key step in validating an architecture is to consider what may have been forgotten. The architecture must support all the essential information processing needs of the organization. The most critical source of gaps that should be considered is stakeholder concerns that have not been addressed in prior architectural work.
  • The determination of interoperability occurs throughout the ADM:
    • In Phase A: Architecture Vision, the nature and security considerations of information and service exchanges are found using business scenarios.
    • In Phase B: Business Architecture, information and service exchanges are defined in business terms.
    • In Phase C: Data Architecture, the content of information exchanges is detailed using the corporate data and/or information exchange model.
    • In Phase C: Application Architecture, the ways that applications are to share information and services are specified.
    • In Phase D: Technology Architecture, appropriate technical mechanisms to permit information and service exchanges are specified.
    • In Phase E: Opportunities & Solutions, actual solutions are selected.
    • In Phase F: Migration Planning, interoperability is implemented logically.
  • Business Transformation Readiness Assessment: The recommended activities are:
    • Determine the readiness factors that will impact the organization
    • Present the readiness factors using maturity models
    • Assess the readiness factors, and determine the readiness factor ratings
    • Assess the risks for each readiness factor and identify improvement actions to mitigate the risk
    • Document the findings into the Capability Assessment and later incorporate the actions into the Implementation and Migration Plan in Phases E and F
  • Risk Management: is a technique used to mitigate risk when implementing an architecture project. There are two levels of risk that should be considered:
    • Initial Level of Risk: Risk categorization prior to determining and implementing mitigating actions. Residual Level of Risk: Risk categorization after implementation of mitigating actions.
  • The recommended process for managing risk consists of the following activities:
    • Risk classification
    • Risk identification
    • Initial risk assessment
    • Risk mitigation and residual risk assessment
    • Risk monitoring
  • Capability-Based Planning: Capability-Based Planning is a business planning technique that focuses on business outcomes. It is business-driven and business-led and combines the requisite efforts of all lines of business to achieve the desired capability. It accommodates most, if not all, of the corporate business models and is especially useful in organizations where a latent capability to respond (e.g., an emergency preparedness unit) is required and the same resources are involved in multiple capabilities. Often the need for these capabilities is discovered and refined using business scenarios.

Chapter 9 Architecture Governance

  • Architecture Governance includes the following:
    • Implementing a system of controls over the creation and monitoring of all architectural components and activities, to ensure the effective introduction, implementation, and evolution of architectures within the organization
    • Implementing a system to ensure compliance with internal and external standards and regulatory obligations
    • Establishing processes that support effective management of the above processes within agreed parameters
    • Developing practices that ensure accountability to a clearly identified stakeholder community, both inside and outside the organization
  • What is Governance? Governance is about ensuring that business is conducted properly. It is less about overt control and strict adherence to rules, and more about effective usage of resources to ensure sustainability of an organization’s strategic objectives. The following characteristics, adapted from Corporate Governance (Naidoo, 2002), are used in the TOGAF standard to highlight both the value and necessity for governance as an approach to be adopted within organizations and their dealings with all involved parties:
    • Discipline: All involved parties will have a commitment to adhere to procedures, processes, and authority structures established by the organization.
    • Transparency: All actions implemented, and their decision support will be available for inspection by authorized organization and provider parties.
    • Independence: All processes, decision-making, and mechanisms used will be established to minimize or avoid potential conflicts of interest.
    • Accountability: Identifiable groups within the organization – e.g., governance boards who take actions or make decisions – are authorized and accountable for their actions.
    • Responsibility: Each contracted party is required to act responsibly to the organization and its stakeholders.
    • Fairness: All decisions taken, processes used, and their implementation will not be allowed to create unfair advantage to any one party.
  • Architecture Governance covers the management and control of all aspects of the development and evolution of architectures. It needs to be supported by an Architecture Governance Framework which assists in identifying effective processes so that the business responsibilities associated with Architecture Governance can be elucidated, communicated, and managed effectively.

  • Key Architecture Governance Processes The following are the key processes:
    • 1. Policy Management and Take-On
    • 2. Compliance
    • 3. Dispensation
    • 4. Monitoring and Reporting
    • 5. Business Control
    • 6. Environment Management

  • Architecture Governance is beneficial because it:
    • Links IT processes, resources, and information to organizational strategies and objectives
    • Integrates and institutionalizes IT best practices
    • Aligns with industry frameworks such as COBIT (planning and organizing, acquiring and implementing, delivering and supporting, and monitoring IT performance)
    • Enables the organization to take full advantage of its information, infrastructure, and hardware/software assets
    • Protects the underlying digital assets of the organization
    • Supports regulatory and best practice requirements such as auditability, security, responsibility, and accountability
  • What are the Key Success Factors when establishing Architecture Governance? It is important to consider the following to ensure a successful approach to Architecture Governance, and effective management of the Architecture Contract:
    • Establishment and operation of best practices for submission, adoption, re-use, reporting, and retirement of architecture policies, procedures, roles, skills, organizational structures, and support services
    • Establishment of correct organizational responsibilities and structures to support Architecture Governance processes and reporting requirements
    • Integration of tools and processes to facilitate take-up of processes (both procedural and cultural)
    • Management of criteria for control of Architecture Governance processes, dispensations, compliance assessments, Service Level Agreements (SLAs), and Operational Level Agreements (OLAs)
    • Meeting internal and external requirements for effectiveness, efficiency, confidentiality, integrity, availability, compliance, and reliability of Architecture Governance-related information, services, and processes
  • The Architecture Board is typically made responsible, and accountable, for achieving some or all the following goals:
    • Providing the basis for all decision-making about changes to the architectures
    • Consistency between sub-architectures
    • Establishing targets for re-use of components
    • Flexibility of enterprise architecture; to meet business needs and utilize new technologies
    • Enforcement of Architecture Compliance
    • Improving the maturity level of architecture discipline within the organization
    • Ensuring that the discipline of architecture-based development is adopted
    • Supporting a visible escalation capability for out-of-bounds decisions
  • The Meaning of Architecture Compliance:

Chapter 10 Views, Viewpoints, and Stakeholders

  • A system is a collection of components organized to accomplish a specific function or set of functions. “The term system encompasses individual applications, systems in the traditional sense, subsystems, systems of systems, product lines, product families, whole enterprises, and other aggregations of interest
  • Stakeholders are people who have key roles in, or concerns about, the system; for example, users, developers, etc. Stakeholders can be individuals, teams, organizations, etc.
  • Concerns are key interests that are crucially important to stakeholders and determine the acceptability of the system.
  • A view is a representation of a system from the perspective of a related set of concerns. A view is what you see (or what a stakeholder sees). An architect creates architecture models. A view consists of parts of these, chosen to show stakeholders that their concerns are being met.
  • A viewpoint defines the perspective from which a view is taken. It defines how to construct and use a view, the information needed, the modeling techniques for expressing and analyzing it, and a rationale for these choices (e.g., by describing the purpose and intended audience of the view). The relationship between viewpoint and view is analogous to that of a template and an instance of the completed template. In constructing an enterprise architecture, an architect first selects the viewpoints (templates), then constructs a set of corresponding views (instances).
  • The architect has a responsibility for ensuring:
    • The completeness of the architecture: — Does it address all the concerns of its stakeholders?
    • The integrity of the architecture: — Can the views be connected to each other? — Can the conflicting concerns be reconciled? — What trade-offs have been made (e.g., between security and performance)?
  • Recommended Steps: The following are the recommended steps to create the required views for a architecture:
    • 1. Refer to any existing libraries of viewpoints (note that TOGAF 9 includes a set of architecture viewpoints).
    • 2. Select key stakeholders.
    • 3. Analyze their concerns and document them.
    • 4. Select appropriate viewpoints (based on the stakeholders and their concerns).
    • 5. Generate views of the system using the selected viewpoints as templates.

TOGAF Certification Series 3: The Architecture Development Method

Chapter 5: Introduction to the Architecture Development Method

  • The Architecture Development Cycle

    • Preliminary Phase: Prepares the organization for successful TOGAF architecture projects. Undertake the preparation and initiation activities required to create an Architecture Capability, including the customization of the TOGAF framework, selection of tools, and the definition of Architecture Principles.
    • Requirements Management: Every stage of a TOGAF project is based on and validates business requirements. Requirements are identified, stored, and fed into and out of the relevant ADM phases, which dispose of, address, and prioritize requirements.
    • Phase A: Architecture Vision: Sets the scope, constraints, and expectations for a TOGAF project. Create the Architecture Vision, Identify stakeholders, Validate the business context and create the Statement of Architecture Work, and Obtain approvals.
    • Phase B: Business Architecture Phase C: Information Systems Architectures (Application & Data) Phase D: Technology Architecture Develop architectures in four domains:
      • 1. Business
      • 2. Information Systems – Application
      • 3. Information Systems – Data
      • 4. Technology

      In each case, develop the Baseline and Target Architecture and analyze gaps.

    • Phase E: Opportunities & Solutions Perform initial implementation planning and the identification of delivery vehicles for the building blocks identified in the previous phases. Determine whether an incremental approach is required, and if so identify Transition Architectures.
    • Phase F: Migration Planning Develop Detailed Implementation and Migration Plan that addresses how to move from the Baseline to the Target Architecture.
    • Phase G: Implementation Governance Provide architectural oversight for the implementation. Prepare and issue Architecture Contracts. Ensure that the implementation project conforms to the architecture.
    • Phase H: Architecture Change Management: Provide continual monitoring and a change management process to ensure that the architecture responds to the needs of the enterprise and maximizes the value of the architecture to the business.

Chapter 6: The Enterprise Continuum and Tools

  • The Architecture Repository:
    • The Architecture Metamodel describes the organizationally tailored application of an architecture framework, including a method for architecture development and a metamodel for architecture content.
    • The Architecture Capability defines the parameters, structures, and processes that support governance of the Architecture Repository.
    • The Architecture Landscape presents an architectural representation of assets in use, or planned, by the enterprise at particular points in time.
    • The Standards Information Base captures the standards with which new architectures must comply, which may include industry standards, selected products and services from suppliers, or shared services already deployed within the organization. The Open Group provides an example of a Standards Information Base on its web site.
    • The Reference Library provides guidelines, templates, patterns, and other forms of reference material that can be leveraged in order to accelerate the creation of new architectures for the enterprise.
    • The Governance Log provides a record of governance activity across the enterprise.

Chapter 7: The ADM Phases

  • Preliminary Phase: includes the preparation and initiation activities to create an Architecture Capability. Key activities are as follows:
    • Understand the business environment
    • Ensure high-level management commitment
    • Obtain agreement on scope
    • Establish architecture principles
    • Establish governance structure
    • Customization of the TOGAF framework
  • Business Capability Management (Business Direction and Planning) which determine what business capabilities are required.
  • Portfolio/Project Management Methods which determine how a company manages its change initiatives.
  • Operations Management Methods which describe how a company runs its day-to-day operations, including IT.
  • Solution Development Methods which formalize the way that business systems are delivered

  • Phase A: Architecture Vision: Phase A is about project establishment and initiates an iteration of the Architecture Development Cycle, setting the scope, constraints, and expectations for the iteration. Objectives:
    • Develop a high-level aspirational vision of the capabilities and business value to be delivered because of the proposed enterprise architecture.
    • Obtain approval for a Statement of Architecture Work that defines a program of works to develop and deploy the architecture outlined in the Architecture Vision.
  • Phase B: Business Architecture Phase B is about development of a Business Architecture to support an agreed Architecture Vision. This describes the fundamental organization of a business embodied in:
    • Its business process and people
    • Their relationships to each other and the people
    • The principles governing its design and evolution
    • and shows how an organization meets its business goals.
  • Objectives are:
    • Develop the Target Business Architecture describing how the enterprise needs to operate to achieve the business goals, responds to the strategic drivers set out in the Architecture Vision, and addresses the Request for Architecture Work and stakeholder concerns
    • Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Business Architectures
  • Phase C: Information Systems Architectures: Phase C is about documenting the Information Systems Architectures for an architecture project, including the development of Data and Application Architectures. This describes the major types of information and the application systems that process the information, and their relationships to each other and the environment. There are two steps in this phase, which may be developed either sequentially or concurrently:
    • Data Architecture
    • Application Architecture
  • Objectives
    • Develop the Target Information Systems (Data and Application) Architecture, describing how the enterprise’s Information Systems Architecture will enable the Business Architecture and the Architecture Vision, in a way that addresses the Request for Architecture Work and stakeholder concerns.
    • Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Information Systems (Data and Application) Architectures
  • Key Considerations for the Data Architecture:
    • Data Management
      • Defining application components which will serve as the system of record or reference for enterprise master data
      • Defining enterprise-wide standards that all application components, including software packages, need to adopt
      • Understanding how data entities are utilized by business functions, processes, and services
      • Understanding how and where enterprise data entities are created, stored, transported, and reported
      • Understanding the level and complexity of data transformations required to support the information exchange needs between applications
      • Defining the requirement for software in supporting data integration with the enterprise’s customers and suppliers (e.g., use of ETL tools during the data migration, data profiling tools to evaluate data quality, etc.)
    • Data Migration
    • Data Governance
  • Phase D: Technology Architecture is about documenting the Technology Architecture for an architecture project, in the form of the fundamental organization of the IT systems:
    • Embodied in the hardware, software, and communications technology
    • Their relationships to each other and the environment
    • The principles governing its design and evolution
  • Objectives
    • Develop the Target Technology Architecture that enables the logical and physical application and data components and the Architecture Vision, addressing the Request for Architecture Work and stakeholder concerns
    • Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Technology Architectures
  • Phase E: Opportunities and Solutions: is the first phase which is directly concerned with implementation. It describes the process of identifying major implementation projects and grouping them into work packages that deliver the Target Architecture identified in previous phases. Key activities are as follows:
    • Perform initial implementation planning
    • Identify the major implementation projects
    • Group changes into work packages
    • Decide on approach: — Make versus buy versus re-use — Outsource — COTS — Open Source
    • Assess priorities
    • Identify dependencies
  • Objectives
    • Generate the initial complete version of the Architecture Roadmap, based upon the gap analysis and candidate Architecture Roadmap components from Phases B, C, and D
    • Determine whether an incremental approach is required, and if so identify Transition Architectures that will deliver continuous business value.
  • Phase F: Migration Planning: addresses detailed migration planning; that is, how to move from the Baseline to the Target Architectures. Key activities include:
    • For work packages and projects identified, perform a cost/benefit analysis and a risk assessment
    • Finalize a detailed Implementation and Migration Plan
  • Objectives
    • Finalize the Architecture Roadmap and the supporting Implementation and Migration Plan
    • Ensure that the Implementation and Migration Plan is coordinated with the enterprise’s approach to managing and implementing change in the enterprise’s overall change portfolio
    • Ensure that the business value and cost of work packages and Transition Architectures is understood by key stakeholders
  • Phase G: Implementation Governance: defines how the architecture constrains the implementation projects, monitors it while building it, and produces a signed Architecture Contract. Key activities include:
    • Provide architectural oversight for the implementation
    • Define architecture constraints on implementation projects
    • Govern and manage an Architecture Contract
    • Monitor implementation work for conformance
  • Objectives
    • Ensure conformance with the Target Architecture by implementation projects
    • Perform appropriate Architecture Governance functions for the solution and any implementation-driven architecture Change Requests
  • Phase H: Architecture Change Management: ensures that changes to the architecture are managed in a controlled manner. Key activities include:
    • Provide continual monitoring and a change management process
    • Ensure that changes to the architecture are managed in a cohesive and architected way
    • Provide flexibility to evolve rapidly in response to changes in the technology or business environment
    • Monitor the business and capacity management
  • Objectives
    • Ensure that the architecture lifecycle is maintained
    • Ensure that the Architecture Governance Framework is executed
    • Ensure that the enterprise’s Architecture Capability meets current requirement
  • Requirements Management: The process of managing architecture requirements applies to all phases of the ADM cycle. The Requirements Management process is a dynamic process, which addresses the identification of requirements for the enterprise, stores them, and then feeds them in and out of the relevant ADM phases. This process is central to driving the ADM process.
  • Objectives
    • Ensure that the Requirements Management process is sustained and operates for all relevant ADM phases
    • Manage architecture requirements identified during any execution of the ADM cycle or a phase
    • Ensure that the relevant architecture requirements are available for use by each phase as the phase is executed.

TOGAF Certification Series 2: Foundations Core Concepts

Chapter 3: Core Concepts

  • What are the ADM phase names and the purpose of each phase?


  • The Preliminary Phase describes the preparation and initiation activities required to create an Architecture Capability, including the customization of the TOGAF framework, and the definition of Architecture Principles.
  • Phase A: Architecture Vision describes the initial phase of an Architecture Development Cycle. It includes information about defining the scope, identifying the stakeholders, creating the Architecture Vision, and obtaining approvals.
  • Phase B: Business Architecture describes the development of a Business Architecture to support an agreed Architecture Vision.
  • Phase C: Information Systems Architectures describes the development of Information Systems Architectures for an architecture project, including the development of Data and Application Architectures.
  • Phase D: Technology Architecture describes the development of the Technology Architecture for an architecture project.
  • Phase E: Opportunities and Solutions describes the process of identifying major implementation projects and grouping them into work packages that deliver the Target Architecture defined in the previous phases.
  • Phase F: Migration Planning describes the development of a detailed Implementation and Migration Plan that addresses how to move from the Baseline to the Target Architecture.
  • Phase G: Implementation Governance provides an architectural oversight of the implementation.
  • Phase H: Architecture Change Management establishes procedures for managing change to the new architecture.
  • Requirements Management examines the process of managing architecture requirements throughout the ADM.
  • What are deliverables, artifacts, and building blocks?


  • What is the Enterprise Continuum?

The Enterprise Continuum is a view of the Architecture Repository that provides methods for classifying architecture and solution artifacts as they evolve from generic Foundation Architectures to Organization-Specific Architectures. The Enterprise Continuum comprises two complementary concepts: the Architecture Continuum and the Solutions Continuum.

The Enterprise Continuum and the Architecture Repository The Enterprise Continuum provides a view of the Architecture Repository that shows the evolution of these related architectures from generic to specific, from abstract to concrete, and from logical to physical. [Source: TOGAF 9 Part V: Enterprise Continuum and Tools]

  • What is the Architecture Repository?

Architecture Repository is used to store different classes of architectural output at different levels of abstraction

The major components within an Architecture Repository are as follows:

  • The Architecture Metamodel describes the organizationally tailored application of an architecture framework, including a metamodel for architecture content.
  • The Architecture Capability defines the parameters, structures, and processes that support governance of the Architecture Repository.
  • The Architecture Landscape shows an architectural view of the building blocks that are in use within the organization today (e.g., a list of the live applications). The landscape is likely to exist at multiple levels of abstraction to suit different architecture objectives
  • The Standards Information Base (SIB) captures the standards with which new architectures must comply, which may include industry standards, selected products and services from suppliers, or shared services already deployed within the organization.
  • The Reference Library provides guidelines, templates, patterns, and other forms of reference material that can be leveraged to accelerate the creation of new architectures for the enterprise.
  • The Governance Log provides a record of governance activity across the enterprise. abstraction to suit different architecture objectives
  • How to establish and operate an enterprise architecture capability?



    The benefits of Architecture Governance include:

  • Increased transparency of accountability, and informed delegation of authority
  • Controlled risk management
  • Protection of the existing asset base through maximizing re-use of existing architectural components
  • Proactive control, monitoring, and management mechanisms
  • Process, concept, and component re-use across all organizational business units
  • Value creation through monitoring, measuring, evaluation, and feedback
  • Increased visibility supporting internal processes and external parties’ requirements; in particular, increased visibility of decision-making at lower levels ensures oversight at an appropriate level within the enterprise of decisions that may have far-reaching strategic consequences for the organization
  • Greater shareholder value; in particular, enterprise architecture increasingly represents the core intellectual property of the enterprise – studies have demonstrated a correlation between increased shareholder value and well-governed enterprises
  • Integrates with existing processes and methodologies and complements functionality by adding control capabilities
  • How to use the TOGAF framework with other frameworks?

Why is the TOGAF standard becoming so popular in the industry? One key reason is that architects can use the TOGAF ADM in conjunction with any of the popular frameworks. The TOGAF ADM is framework-agnostic and helps IT architects fill in the framework they might already have in use.

Chapter 4: Key Terminology

  • Architecture: Architecture has two meanings depending upon its contextual usage:
    • A formal description of a system, or a detailed plan of the system at component level to guide its implementation
    • The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.
  • Architecture Principles: A qualitative statement of intent that should be met by the architecture. Has at least a supporting rationale and a measure of importance.
  • Architecture Vision: A succinct description of the Target Architecture that describes its business value and the changes to the enterprise that will result from its successful deployment. It serves as an aspirational vision and a boundary for detailed architecture development.
  • Baseline: A specification that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development or change and that can be changed only through formal change control procedures or a type of procedure such as configuration management.

TOGAF Certification Series 1: Foundations Introduction

Chapter 1 Introduction:

  • Why is TOGAF certification important? The existence of a certification program for the TOGAF standard provides a strong incentive for organizations to standardize on the TOGAF standard as the open method for enterprise architecture, and so avoid lock-in to proprietary methods. It is an important step in making enterprise architecture a well-recognized discipline, and in introducing rigor into the procurement of tools and services for enterprise architecture.
  • The purpose of certification to TOGAF 9 Level 1, known as TOGAF 9 Foundation, is to provide validation that the candidate has gained an acceptable level of knowledge of the terminology, structure, and basic concepts of TOGAF 9, and understands the core principles of enterprise architecture and the TOGAF standard
  • Individuals certified at this level will have demonstrated their understanding of:
    • The basic concepts of enterprise architecture and the TOGAF standard
    • The core concepts of TOGAF 9
    • The key terminology of TOGAF 9 
    • The ADM cycle and the objectives of each phase, and how to adapt and scope the ADM
    • The concept of the Enterprise Continuum; its purpose, and its constituent parts
    • How each of the ADM phases contributes to the success of enterprise architecture
    • The ADM guidelines and techniques
    • How Architecture Governance contributes to the Architecture Development Cycle
    • The concepts of views and viewpoints and their role in communicating with stakeholders
    • The concept of building blocks
    • The key deliverables of the ADM cycle
    • The TOGAF reference models
    • The TOGAF certification program
  • What is the relationship between TOGAF 9 Foundation and TOGAF 9 Certified? The learning outcomes for TOGAF 9 Foundation are a subset of those for TOGAF 9 Certified. Candidates are able to choose whether they wish to become certified in a stepwise manner by starting with TOGAF 9 Foundation and then at a later date TOGAF 9 Certified, or alternately to go direct to TOGAF 9 Certified by taking the combined examination

Chapter 2 Basic Concepts:

  • What is the TOGAF Standard? The TOGAF standard is an architecture framework. The TOGAF standard is a tool for assisting in the acceptance, production, use, and maintenance of enterprise architectures. It is based on an iterative process model supported by best practices and a re-usable set of existing architectural assets.
  • Structure of the TOGAF Document:
    • Part I: Introduction This part provides a high-level introduction to the key concepts of enterprise architecture and, in particular, to the TOGAF approach. It contains the definitions of terms used throughout the TOGAF standard and release notes detailing the changes between this version and the previous version of the TOGAF standard.
    • Part II: Architecture Development Method (ADM) This part is the core of the TOGAF standard. It describes the TOGAF Architecture Development Method (ADM) – a step-by-step approach to developing an enterprise architecture.
    • Part III: ADM Guidelines and Techniques This part contains a collection of guidelines and techniques available for use in applying the ADM.
    • Part IV: Architecture Content Framework This part describes the TOGAF content framework, including a structured metamodel for architectural artifacts, the use of re-usable Architecture Building Blocks (ABBs), and an overview of typical architecture deliverables.
    • Part V: Enterprise Continuum and Tools: This part discusses appropriate taxonomies and tools to categorize and store the outputs of architecture activity within an enterprise.
    • Part VI: TOGAF Reference Models: This part provides two architectural reference models, namely the TOGAF Technical Reference Model (TRM), and the Integrated Information Infrastructure Reference Model (III-RM).
    • Part VII: Architecture Capability Framework: This part discusses the organization, processes, skills, roles, and responsibilities required to establish and operate an architecture practice within an enterprise.
  • What is an Enterprise? An “enterprise” is any collection of organizations that has a common set of goals. For example, an enterprise could be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership. The term “enterprise” in the context of “enterprise architecture” can be used to denote both an entire enterprise, encompassing all of its information systems, and a specific domain within the enterprise. An extended enterprise frequently includes partners, suppliers, and customers. If the goal is to integrate an extended enterprise, then the enterprise comprises the partners, suppliers, and customers, as well as internal business units. For example, an organization with an online store that uses an external fulfillment house for dispatching orders would extend its definition of the enterprise in that system to include the fulfillment house.
  • What is Architecture in the Context of the TOGAF Standard? Architecture has two meanings depending upon the context:
    • 1. A formal description of a system, or a detailed plan of the system at a component level to guide its implementation \
    • 2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time
  • Enterprise architecture is:
    • 1. The organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm’s operating model.
    • 2. A conceptual blueprint that defines the structure and operation of an organization. The intent of an enterprise architecture is to determine how an organization can most effectively achieve its current and future objectives.
  • Why do I Need Enterprise Architecture? The purpose of enterprise architecture is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy. Effective management and exploitation of information through IT is a key factor to business success, and an indispensable means to achieving competitive advantage. An enterprise architecture addresses this need, by providing a strategic context for the evolution of the IT system in response to the constantly changing needs of the business environment. Ultimately, the benefits of enterprise architecture derive from the better planning, earlier visibility, and more informed designs that result when it is introduced.
  • What is an Architecture Framework? An architecture framework is a foundational structure, or set of structures, that can be used for developing a broad range of different architectures. It should describe a method for designing a target state of the enterprise in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks. Using an architecture framework will speed up and simplify architecture development, ensure more complete coverage of the designed solution, and make certain that the architecture selected allows for future growth in response to the needs of the business.
  • Why is the TOGAF Standard Suitable as a Framework for Enterprise Architecture? Using the TOGAF standard results in enterprise architecture that is consistent, reflects the needs of stakeholders, employs best practice, and gives due consideration both to current requirements and to the perceived future needs of the business.
  • What are the Different Architecture Domains that the TOGAF Standard deals with?
    • Business Architecture: The business strategy, governance, organization, and key business processes.
    • Data Architecture: The structure of an organization’s logical and physical data assets and data management resources.
    • Application Architecture: A blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization.
    • Technology Architecture: The software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, and standards.
  • Definition of “Capability”: An ability that an organization, person, or system possesses. Capabilities are typically expressed in general and high-level terms and typically require a combination of organization, people, processes, and technology to achieve. For example, marketing, customer contact, or outbound telemarketing.
    • An enterprise architecture capability (or architecture capability) in the context of the TOGAF standard, is the ability for an organization to effectively undertake the activities of an enterprise architecture practice.
  • What does the TOGAF Standard Contain?
  • TOGAF Reference Models
    • TOGAF Foundation Architecture Technical Reference Model: The TOGAF Technical Reference Model is an architecture of generic services and functions that provides a foundation on which specific architectures and Architecture Building Blocks (ABBs) can be built.
    • Integrated Information Infrastructure Reference Model (III-RM) : The Integrated Information Infrastructure Reference Model (III-RM) is based on the TOGAF Foundation Architecture, and is specifically aimed at helping the design of architectures that enable and support the vision of Boundaryless Information Flow.

MuleSoft: Salesforce Synchronization with Retry Sample

In addition to MuleSoft connection Retry, this pattern adds the retry of rejected or failed records by the target system validation, in case another retry would succeed

Scenario

In a recent project I was working on, I needed to keep Salesforce objects updates synchronized with Siebel. The basic integration scenario is shown in Figure 1.

Figure 1: Integration Scenario

There is one complication though, sometimes Siebel will reject updates or new records as validations fails due to missing data or racing conditions with other data records. Rather than letting records fail and logging errors for support or the user to resubmit, a retry approach after a period of time could remedy most of the errors. As depicted in figure 2, the logic for the synch is as follows:

  1. The synchronization job is schedule to run every 10 minutes.
  2. Fetch the last datetime the synch had run (in case the synch job was stopped for any reason such as maintenance).
  3. Fetch all modified or created accounts IDs from Salesforce since the last run
  4. Process Accounts
    1. Fetch the Account Objects for the records ID from steps 3
    2. Do the necessary conversions to Siebel format and send the updates to Siebel
    3. Send the Siebel IDs for accepted records to Salesforce
    4. For records that got rejected by Siebel, keep track of the record IDs and store them in MuleSoft Object Store with the number of retries.
  5. If there are Stored Rejected Record IDs from a previous run in MuleSoft Object Sore
    1. Fetch the record ID from Object Store
    2. Execute Process Accounts step 4
    3. If the number of retries exceeds 3 times log the rejection and create a ServiceNow ticker so support can track and resolve the issue

Figure 2: Synchronization with Capturing errors and Retry

The Sample

In the sample code found at my GitHub (https://github.com/RefaatM/MuleSoft_SyncWithRetry), I am simulating Siebel with a MySQL DB. The implementation will synchronize the Salesforce Account changes with a table in MySQL DB. The next few sections, walks through the code details

Project Structure

When you open the sample code in AnyPoint Studio, you will find the project code consisting of:

  1. Src\main\mule which contains the 4 workflows
  2. Src\main\java which contains 1 java helper class
  3. Src\main\resources which contains the configurations config.yaml

The other packages are the standard packages of any MuleSoft project. The 4 Workflows, 1 Java class and config.yaml implement the solutions.

Figure 3: Project Structure

General Workflow and Global Configuration

Figure 4: General Workflow

Following the MuleSoft best practices the Global workflow is where you will find the Global Exception Handler in this sample it just logs the error (figure 4) and the global configuration to use a config file for the different environments and the connections to Salesforce and MySQL DB (figure 5).

Figure 5: Global Configuration

Figure 6 shows that the Default Error Hander is set to the “General Error Handler” in the General Workflow. For a refresher on MuleSoft Exception Handling see MuleSoft: Understanding Exception Handling/

Figure 6: Global Error handler Configuration

Figure 7 Shows the setting of config.yaml as the source for the configuration information. It is important not to hard code any environment or properties.

Figure 7: Configuration properties source file

The listing below shows the contents of the config.yaml . All sensitive information is masked with * to run the sample you will have to enter the proper information for your environment.

sfdc:


username: “**************”


password: “***********”


token: “*****”

db:


host: “localhost”


port: “3306”


user: “root”


password: “****”


database: “synchsample”

Figure 8 shows the configuration of the Salesforce connection with parametrized information to be retrieved from config.yaml

Figure 8: Salesforce configuration

Figure 9 shows the configuration of the MySQL DB connection with parametrized information to be retrieved from config.yaml

Figure 9: MySQL Connection configuration

MainFlow

Figure 10: MainFlow

The mainflow is triggered by the scheduler the logic is :

  1. Log the start time
  2. Call the Get Duration subflow
  3. Query Sales force for update accounts
  4. Convert the result to a list of IDs to query
  5. Call Record Processing subflow
  6. Log the operation is finished
  7. In case of any error just log it.

CallRecordsProcessing Workflow

Figure 11: CallRecordProcessing Subworkflow

  1. Check if the list of record IDs is empty
    1. Not Empty: call Process Records
    2. Empty: log no modified records found

GetDuration Subworkflow

Figure 12: GetDuration Subworkflow

  1. Check if Object store contains saved lastTimeRun
  2. Contains LastTimeRun:
    1. Fetch the lastTime
    2. Call Helper Java method to get the duration
  3. Does not contain LastTimeRun:
    1. Set the duration to 10 minutes

The Java method code is listed below which just calculates the duration since last time the workflow ran till now in minutes

package sfsynchwithretrypattern;

import java.time.Duration;

import java.time.LocalDateTime;

import java.time.ZonedDateTime;

public class StaticHelpers {

    public static long getDuration(ZonedDateTime lastTime) {

        LocalDateTime now = LocalDateTime.now();

     Duration duration = Duration.between(now, lastTime.toLocalDateTime());

     return Math.abs(duration.toMinutes());

    }

}

StoreRetryAccounts Workflow

Figure 13: StoreRetryAccounts SubWorkflow

  1. Check if there are stored RetryIDs
    1. RetryIDS stored: Append the new IDs to the existing IDS
    2. Does not Exist: set the store load to the new IDs
  2. Store the updated value

ProcessRecords SubWorkflow

Figure 14: ProcessRecords SubWorkflow

  1. Retrieve accounts with IDs
  2. For each retrieve account IF
    1. Check if the Account info exists in the DB
      1. Exists: update the account information
      2. Does not Exist: Insert a new record

    Note here I am taking an new records and saving them in the retry ID to simulate rejections. This should be moved to where you receive results and the errors

RetryProcessing Workflow

The retryprocessing workflow is triggered by a schedular, it starts with:

  1. Check if there are any retry id stored
    1. Exists: retrive the stored IDs and process them
    2. Does not Exist: Log no Stored IDs were found.

Conclusion

This is a good way to handle transient errors that occasionally occur during integrating system, when a simple retry might resolve the issue rather than having to ask the user to re-submit or getting support to chase the error. I hope this helps you in your projects. Feedback is welcome.

Figure 15: MySQL DB Table with Updates

What are the Downsides of a Microservice based solution

A Microservice based solution has the following downsides:

  1. Distributing the application adds complexity for developers when they are designing and building the services and in testing and exception handling. It also adds latency to the system.
  2. Without a Microservice-oriented infrastructure, An application that has dozens of Microservices types and needs high scalability means a high degree of deployment complexity for IT operations and management.
  3. Atomic transactions between multiple Microservices usually are not possible. The business requirements must embrace eventual consistency between multiple Microservices.
  4. Increased global resource needs (total memory, drives, and network resources for all the servers or hosts). The higher degree of granularity and distributed services requires more global resources. However, given the low cost of resources in general and the benefit of being able to scale out just certain areas of the application compared to long-term costs when evolving monolithic applications, the increased use of resources is usually a good tradeoff for large, long-term applications.
  5. When the application is large, with dozens of Microservices, there are challenges and limitations if the application requires direct client-to-Microservice communications. When designing and building a complex application based on Microservices, you might consider the use of multiple API Gateways instead of the simpler direct client‑to‑Microservice communication approach.
  6. Deciding how to partition an end-to-end application into multiple Microservices is challenging. As You need to identify areas of the application that are decoupled from the other areas and that have a low number of hard dependencies. Ideally, each service should have only a small set of responsibilities. This is like the single responsibility principle (SRP) applied to classes, which states that a class should only have one reason to change. 

 

 

Practical REST API Design, implementation and Richardson Maturity Model

Richardson Maturity Model classifies REST API maturity as follows

  • Level Zero: These services have a single URI and use a single HTTP method (typically POST). For example, most Web Services (WS-*)-based services use a single URI to identify an endpoint, and HTTP POST to transfer SOAP-based payloads, effectively ignoring the rest of the HTTP verbs. Similarly, XML-RPC based services which send data as Plain Old XML (POX). These are the most primitive way of building SOA applications with a single POST method and using XML to communicate between services.
  • Level One: These services employ many URIs but only a single HTTP verb – generally HTTP POST. They give each individual resource in their universe a URI. Every resource is separately identified by a unique URI – and that makes them better than level zero.
  • Level Two: Level two services host numerous URI-addressable resources. Such services support several of the HTTP verbs on each exposed resource – Create, Read, Update and Delete (CRUD) services. Here the state of resources, typically representing business entities, can be manipulated over the network. Here service designer expects people to put some effort into mastering the APIs – generally by reading the supplied documentation. Level 2 is the good use-case of REST principles, which advocate using different verbs based on the HTTP request methods and the system can have multiple resources.
  • Level Three: Level three of maturity makes use of URIs and HTTP and HATEOAS. This is the most mature level of Richardson’s model which encourages easy discoverability and makes it easy for the responses to be self-explanatory by using HATEOAS. The service leads consumers through a trail of resources, causing application state transitions as a result.

Where HATEOAS (Hypermedia as the Engine of Application State) is a constraint of the REST application architecture that keeps the RESTful style architecture unique from most other network application architectures. The term “hypermedia” refers to any content that contains links to other forms of media such as images, movies, and text. This architectural style lets you use hypermedia links in the response contents so that the client can dynamically navigate to the appropriate resource by traversing the hypermedia links. This is conceptually the same as a web user navigating through web pages by clicking the appropriate hyperlinks to achieve a final goal. Like a human’s interaction with a website, a REST client hits an initial API URI and uses the server-provided links to dynamically discover available actions and access the resources it needs. The client need not have prior knowledge of the service or the different steps involved in a workflow. Additionally, the clients no longer have to hard code the URI structures for different resources. This allows the server to make URI changes as the API evolves without breaking the clients.

Naturally you would want to build to highest standard and provide level three REST API. That would mean providing a links field as in the following example below from GT-IDStorm API

The data payload as you can see from this sample is huge, compared to the actual data returned.

{

“value”: [

{

“id”: “63b2c70e-2bcb-4335-9961-3d14be642163”,

“name”: “Entity-1”,

“description”: “Testing Entity 1”,

“links”: [

{

“href”: “https://localhost:44379/api/v1/entity/63b2c70e-2bcb-4335-9961-3d14be642163”,

“rel”: “self”,

“method”: “GET”

},

{

“href”: null,

“rel”: “get_entitydefinition_byname”,

“method”: “GET”

},

{

“href”: “https://localhost:44379/api/v1/entity/63b2c70e-2bcb-4335-9961-3d14be642163/full”,

“rel”: “get_full_entitydefinition”,

“method”: “GET”

},

{

“href”: “https://localhost:44379/api/v1/entity/63b2c70e-2bcb-4335-9961-3d14be642163”,

“rel”: “delete_entitydefinition”,

“method”: “DELETE”

},

{

“href”: “https://localhost:44379/api/v1/entity/63b2c70e-2bcb-4335-9961-3d14be642163/attributes”,

“rel”: “create_attribute_for_entitydefinition”,

“method”: “POST”

},

{

“href”: “https://localhost:44379/api/v1/entity/63b2c70e-2bcb-4335-9961-3d14be642163/attributes”,

“rel”: “get_attributes_for_entitydefinition”,

“method”: “GET”

},

{

“href”: “https://localhost:44379/api/v1/entity/63b2c70e-2bcb-4335-9961-3d14be642163/systems”,

“rel”: “create_system_for_entitydefinition”,

“method”: “POST”

},

{

“href”: “https://localhost:44379/api/v1/entity/63b2c70e-2bcb-4335-9961-3d14be642163/systems”,

“rel”: “get_system_for_entitydefinition”,

“method”: “GET”

},

{

“href”: “https://localhost:44379/api/v1/entity/63b2c70e-2bcb-4335-9961-3d14be642163/data”,

“rel”: “get_data_for_entitydefinition”,

“method”: “GET”

},

{

“href”: “https://localhost:44379/api/v1/entity/63b2c70e-2bcb-4335-9961-3d14be642163/data/GetEntityDataWithMissingSystems”,

“rel”: “get_data_WithMissingSystems_for_entitydefinition”,

“method”: “GET”

}

]

},

{

“id”: “54bc1f18-0fd5-43dd-9309-4d8659e3aa91”,

“name”: “Entity-10”,

“description”: “Testing Entity 10”,

“links”: [

{

“href”: “https://localhost:44379/api/v1/entity/54bc1f18-0fd5-43dd-9309-4d8659e3aa91”,

“rel”: “self”,

“method”: “GET”

},

{

“href”: null,

“rel”: “get_entitydefinition_byname”,

“method”: “GET”

},

{

“href”: “https://localhost:44379/api/v1/entity/54bc1f18-0fd5-43dd-9309-4d8659e3aa91/full”,

“rel”: “get_full_entitydefinition”,

“method”: “GET”

},

{

“href”: “https://localhost:44379/api/v1/entity/54bc1f18-0fd5-43dd-9309-4d8659e3aa91”,

“rel”: “delete_entitydefinition”,

“method”: “DELETE”

},

{

“href”: “https://localhost:44379/api/v1/entity/54bc1f18-0fd5-43dd-9309-4d8659e3aa91/attributes”,

“rel”: “create_attribute_for_entitydefinition”,

“method”: “POST”

},

{

“href”: “https://localhost:44379/api/v1/entity/54bc1f18-0fd5-43dd-9309-4d8659e3aa91/attributes”,

“rel”: “get_attributes_for_entitydefinition”,

“method”: “GET”

},

{

“href”: “https://localhost:44379/api/v1/entity/54bc1f18-0fd5-43dd-9309-4d8659e3aa91/systems”,

“rel”: “create_system_for_entitydefinition”,

“method”: “POST”

},

{

“href”: “https://localhost:44379/api/v1/entity/54bc1f18-0fd5-43dd-9309-4d8659e3aa91/systems”,

“rel”: “get_system_for_entitydefinition”,

“method”: “GET”

},

{

“href”: “https://localhost:44379/api/v1/entity/54bc1f18-0fd5-43dd-9309-4d8659e3aa91/data”,

“rel”: “get_data_for_entitydefinition”,

“method”: “GET”

},

{

“href”: “https://localhost:44379/api/v1/entity/54bc1f18-0fd5-43dd-9309-4d8659e3aa91/data/GetEntityDataWithMissingSystems”,

“rel”: “get_data_WithMissingSystems_for_entitydefinition”,

“method”: “GET”

}

]

}

],

“links”: [

{

“href”: “https://localhost:44379/api/v1/entity?orderBy=Name&searchQuery=Testing%20Entity%201&pageNumber=1&pageSize=10”,

“rel”: “self”,

“method”: “GET”

}

]

}

For example if we remove the HATEOAS requirement that data returned for the same query would be

This would less data would have huge impact on the system as a whole performance, Less traffic on the network, less data to process and manipulate by the client and servers.

[

{

“id”: “63b2c70e-2bcb-4335-9961-3d14be642163”,

“name”: “Entity-1”,

“description”: “Testing Entity 1”

},

{

“id”: “54bc1f18-0fd5-43dd-9309-4d8659e3aa91”,

“name”: “Entity-10”,

“description”: “Testing Entity 10”

}

]

I usually implement the API to have and accept header with multiple options

  • Application/json: returns just the data
  • Application/hateoas+json: return the data with the hateoas (Links) data.

I also implement another resource or operation that provides the links structures

In Conclusion

I would recommend implementing the API to:

  • Support Level Two and Leve Three at the same time by using the accept header for the request to
    • Application/json: returns just the data
    • Application/hateoas+json: return the data with the hateoas (Links) data.
  • Implement another resource or the root that would return the URLs (structures and operations) that are supported by the API.

As I found just support HATEAOS only would make the system pay heavy price on performance specially with large data loads while very few clients if any would utilize the links returned. I would love to hear your thoughts and experience on APIs with HATEAOS?

What is Solution Architecture,

In my opinion, Solution Architecture is defining the design or organization of different systems and components to fulfill a business needs and requirements. By systems and components, I mean software applications, and the infrastructure (hardware devices, virtual machines, on-premises or on the cloud) the software runs on. Solution architecture is the combination of Application Architecture, Integration Architecture and Infrastructure Architecture. Solution Architecture takes a high-level description of all Applications, Integrations and Infrastructure architectures in an implementation. For example, with any new application implementation in the enterprise, that new system needs definitions of:

  • Application architecture, that is what components of the application would be utilized and how they will be used by the organization, which components would need customizations and how the system would be configured to accomplish the goals the business wants.
  • Integration with other systems. The new application at least would need to connect to the enterprise Identity management store and how to provision and manage users access to the system and export information to the enterprise data warehouse or bigdata system such as Hadoop or analytics systems, and diagnostics and monitoring to the enterprise monitoring system.
  • Infrastructure, that is an environment to run on wither on premises or in the cloud, that is servers, operating systems, networks, firewall, storage, security and access control, auditing etc.

As solution architect will need to understand the business requirements, the enterprise IT standards, and work on the selection of the appropriate software application to satisfy the business requirements, the enterprise standards, project budgets, and author a solution blueprint that describes how the proposed architecture. Solution architecture is tightly coupled with Enterprise Architecture and infrastructure Architecture teams in most organizations. Solution architecture is one of the key methods, by which enterprise architecture delivers value to the organization. Solution architecture activities take place during solution ideation, solution design, and solution implementation. During ideation, solution architecture establishes the complete business context for the solution and defines the vision and requirements for the solution. During design, solution architecture elaborates potential options, which may include RFIs, RFPs or prototype development. It selects the most optimal option and develops the roadmap for the selected solution. During implementation, solution architecture communicates the architecture to the stakeholders, and guides the implementation team.

Typically, a Solution Architect will work project managers on defining tasks, estimates, discusses architecturally significant requirements with stakeholders, designs a solution architecture blueprint, evaluate proposals, communicates with designers and stakeholders, document solution alternatives. There are four core activities in solution architecture design.

  1. Architectural analysis is the process of understanding the environment in which a proposed solution will operate and determining the requirements for the solution. The input or requirements to the analysis activity can include items such as:
    1. what the system will do when operational (the functional requirements)
    2. how well the system will perform runtime non-functional requirements such as reliability, operability, performance efficiency, security, compatibility.
    3. development-time non-functional requirements such as maintainability and transferability
    4. business requirements and environmental contexts of a system that may change over time, such as legal, social, financial, competitive, and technology concerns
    5. Organizational development capabilities
  2. Architectural synthesis or design is the process of creating an architecture. Given the architecturally significant requirements determined by the analysis, the current state of the design and the results of any evaluation activities, the design is created and improved.
  3. Architecture evaluation is the process of determining how well the current design or a portion of it satisfies the requirements derived during analysis. An evaluation can occur whenever an architect is considering a design decision, it can occur after some portion of the design has been completed, it can occur after the final design has been completed or it can occur after the system has been constructed.
  4. Knowledge management and communication is the activity of exploring and managing knowledge that is essential to designing a solution architecture. A solution architect does not work in isolation. SA get inputs, functional and non-functional requirements and design contexts, from various stakeholders; and provides outputs to stakeholders. Solution architecture knowledge management activity is about finding, communicating, and retaining knowledge. As software architecture design issues are intricate and interdependent, a knowledge gap in design reasoning can lead to incorrect software architecture design.
  5. Documentation is the activity of recording the design generated during the solution architecture process. A solution architecture is described in a solution blueprint that usually contains
    1. Business Architecture section: The business strategy, governance, organization, and key business processes
    2. Interface Architecture (APIs): A blueprint for the individual application interfaces both User Interface and Application Programming Interface and their relationships to the core business processes of the organization.
    3. Application Architecture section: A blueprint for the individual application components to be deployed, their interactions, and their relationships to the core business processes of the organization.
    4. Data Architecture Section: The structure of the application logical and physical data assets and data management resources
    5. Technology Architecture Section: The logical software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, and standards.
    6. Delivery Approach Section: Describes the approach of the solution delivery, what are the phases, would there be POC, would there be a Pilot implementation, who would be doing what, the responsibilities of various internal and external teams.

What do we mean by Architecture?

Architecture is defined as “The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. An architecture has two meanings depending upon the context:

  1. A formal description of a system, or a detailed plan of the system at a component level to guide its implementation.
  2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time