The Software Design And Architecture

Published Date: 02 Nov 2017

A Framework is a set of approaches, components, configurations, models, services, standards and principles that can guide you in your documentation adventure of a particular view of architecture. Architecture frameworks are methods used in architecture modeling. They provide a structured and systematic approach to designing systems. This survey provides a model of understanding through analyzing six Architecture Frameworks. It characterizes different architecture frameworks and identifies advantages.

This survey report investigates the concept of architecture by examining three architecture frameworks. Architecture plays a major role in the development of information systems. Typically, the development of an information system would entail requirements gathering, analysis, software design, development and hardware configuration. The act of architecture in this development cycle is generally understood to be systematic analysis and design of related information to provide a model for guiding the actual development of information systems. Researchers have offered various definitions and explanations of architecture. Garlan and Shaw suggested that software architecture is concerned with issues beyond algorithms and data structures of computation. Perry and Wolf distinguished architecture from design by suggesting that architecture is concerned with the selection of architectural elements, their interaction and their constraints, but design is concerned with the modularization and detailed interfaces of the design element. Monroe et al. suggested that architecture is not about details of implementation. Architecture Practice was proposed to bring separate or isolated architectures and activities into an engineering context. IEEE’s definition of architecture states that it is "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" (IEEE 2000). There was also an attempt to formally distinguish architecture activities from design activities. Further design is required in diverse areas of requirements modeling, network infrastructure, servers configuration and middleware technologies. For instance, the security design of a system may require security process engineering, design of multiple layers of firewalls and network configuration to complement software security. An architecture framework would provide a consistent approach for standardizing, planning, analyzing and modeling of these components.

Several Architecture Frameworks have been published for this purpose. Some were published by organizations to guide their internal system development. Others were published by standards body for establishing architecture standards. Activities defined in these architecture frameworks vary and so do their outcomes. By analyzing and comparing architecture frameworks, this paper provides a model of understanding for architecture. The section on Architecture Frameworks introduces what they intend to achieve. The following sections explainabout Department of Defense Architecture Framework (DODAF), Ministry of Defense Architecture Framework (MODAF), The Open Group Architecture Framework(TOGAF) and Attribute-Driven Design (ADD). And also, it provides the comparisions of DODAF, MODAF and TOGAF with ADD.

ARCHITECTURE FRAMEWORKS

Architecture commonly uses high level abstraction called views. Architecture frameworks use viewpoints to create views that represent different perspectives of a system model. Common viewpoints are business architecture, information architecture, software architecture and technical architecture. Specific frameworks being studied may have underlying goals to focus on distributed systems, enterprise architecture or industry specific systems. After examining different architecture frameworks, the IEEE Recommended Practice for Architectural Description of Software-Intensive System and methods for architecture evaluation, this paper puts forward a set of common goals for architecture frameworks. These goals are independent of industry domain, architecture style and system size.

Architecture Definition and Understanding – make use of standard terms, principles and guidelines for consistent application of the framework for the communication of architecture information to stakeholders.

Architecture Process – employ a well-defined process to guide the construction of architecture

Architecture Evolution Support – employ a framework that supports systems evolution

Architecture Analysis – provide a set of viewpoints to guide the collection and analysis of information for making architecture choices.

Architecture Models – provide consistent standards to document architecture specifications for the planning, management, communication and execution of activities related to system development.

Design Tradeoffs – select a design from more than one design choices by resolving multidimensional conflicting requirements

Design Rationale – document reasons behind design decisions for verification, i.e. "architect for a reason" (Bass et al. 2003) .

Standardization – ensure development and architectural standards are maintained

Architecture Knowledge Base – provide consistent representation and repository of design and architecture design rationale

Architecture Verifiability – provide sufficient information or explanation in the architecture design for review and verification.

These common goals collectively provide an objective guideline for the selection and use of architecture frameworks. As such, resulting architecture models produced by architecture frameworks would provide consistent representation of architecture models. A well defined architecture process would provide a structured approach to architecture analysis and modeling for making design decisions based on tradeoffs. Architecture rationale cross-reference design decisions to facilitate verification of architecture models. Architecture models are documented and stored in a standard architecture knowledge base to support change management and system evolution.

DoD ARCHITECTURE FRAMEWORK (DoDAF)

DoD Architecture framework (DoDAF) defines a common approach for DoD architecture description, development, presentation, and integration for both war fighting operations and business operations and processes .DoD moves toward net-centric operations and warfare. Frame work is intended to ensure that architecture descriptions can be compared and related across organizational boundaries, including Joint and multi-national boundaries. The Department of Defense Architecture Framework (DoDAF) is an architecture for the United States Department of Defense.

DoDAF defines a set of views that act as mechanisms for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through tabular, structural, behavioral, ontological, pictorial, temporal or graphical means. It is especially suited to large systems with complex integration and interoperability challenges, and is apparently unique in its use of "operational views" detailing the external customer's operating domain in which the developing system will operate. Three related views of DoDAF architecture:

Operational view (OV)

Systems View (SV)

Technical Standards (TV)

-->Operational view (OV) – description of the tasks and activities, operational elements and information exchanges required to accomplish the mission

-->Systems View (SV) – a set of graphical and textual products that describes systems and interconnect- ions providing for, or supporting DoD functions

-->Technical Standards (TV) – set of rules governing the arrangement, interactions and interdependence of system parts or elements.

C:\Documents and Settings\Admin\Desktop\320px-DoD_Architecture_Framework.jpg

EVOLUTION OF THE DOD ARCHITECTURE FRAMEWORK

PAST

C4ISR Architecture Framework v1.0, 7 June 1996

The Command, Control, Communications, Computers, and Intelligence, Surveillance, and

Reconnaissance (C4ISR) Architecture Framework v1.0 was created in response to the passage of

the Clinger-Cohen Act and addressed in the 1995 Deputy Secretary of Defense directive that a

DoD-wide effort be undertaken to define and develop a better means and process for ensuring

that C4ISR capabilities were interoperable and met the needs of the warfighter.

C4ISR Architecture Framework v2.0, 18 December 1997

The C4ISR Architecture Framework v2.0 was the result of the continued development effort

by the C4ISR Architecture Working Group and was mandated for all C4ISR architecture

descriptions in a February 1998 memorandum by the Architecture Coordination Council, cochaired by the Under Secretary of Defense for Acquisition and Technology (USD[A&T]), the

Assistant Secretary of Defense for Command, Control, Communications, and Intelligence

(ASD[C3I]), and the Command, Control, Communications, and Computer Systems Directorate,

Joint Staff (J6).

DoD Architecture Framework v1.0, 30 August 2003

The DoDAF v1.0 restructured the C4ISR Framework v2.0 to offer guidance, product

descriptions, and supplementary information in two volumes and a Desk Book. It broadened the

applicability of architecture tenets and practices to all Mission Areas rather than just the C4ISR

community. This document addressed usage, integrated architectures, DoD and Federal policies,

value of architectures, architecture measures, DoD decision support processes, development

techniques, analytical techniques, and the CADM v1.01, and moved towards a repository-based

approach by placing emphasis on architecture data elements that comprise architecture products.

PRESENT

DoD Architecture Framework, v1.5, 23 April 2007

The DoDAF v1.5 is an evolution of the DoDAF v1.0 and reflects and leverages the

experience that the DoD Components have gained in developing and using architecture

descriptions. This transitional version provides additional guidance on how to reflect net-centric

concepts within architecture descriptions, includes information on architecture data management

and federating architectures through the Department, and incorporates the pre-release CADM

v1.5, a simplified model of previous CADM versions that includes net-centric elements.

FUTURE

DoD Architecture Framework v2.0, TBD

The DoDAF v2.0 is currently being scoped to include further guidance on planning,

developing, managing, maintaining, and governing architectures through a coherent semantic

and structural meta model. This version will place greater emphasis on a "data-centric" approach

that facilitates the use of architecture by a wider variety of decision makers and will include

additional information on federation for improved enterprise decisions.

C:\Documents and Settings\Admin\Desktop\800px-DoDAF_Evolution.jpg

Purpose and Scope

The DoDAF provides the guidance needed to establish a common vocabulary for architecture development, for the exchange of architecture information, and for facilitating interoperability between Architectural Descriptions. Architectures are created for a number of reasons, ---from a compliance perspective, DoD development of architectures is compelled by law and policy.

-- From a practical perspective, the management of large organizations employing sophisticated

systems, technologies, and services in pursuit of complex joint missions demands a structured, repeatable method for evaluating investments and investment alternatives, as well as the ability to implement organizational change effectively, create new systems, deploy new technologies, and offer services which add value to decisions and management practices.

Guidance provided by DoDAF V2.0 applies to all architectures developed, maintained, and used within the DoD. The DoDAF also provides the foundational constructs to support the concept of architecture federation at each tier, enabling the sharing of all pertinent architecture information, and facilitates creation of the federated version of the DoD Enterprise Architecture. DoDAF V2.0 provides guidance in all areas of the architecture lifecycle, consistent with both DoD and OMB Guidance (i.e., Development, Maintenance, and Use of Architectures).It is the foundation for long-term administration and management of architectural data, and its accompanying models , views, and consolidated viewpoints that compose the presentation capability of an architecture.

DoDAF V2.0 also supports the concept of SOA development. Volume 1 provides management guidance on development of architectural views and viewpoints, based on service requirements. Volume 2 provides the technical information needed, data views, and other supporting resources for development of services-based architectures

What is New in DoDAF V2.0

The major changes for DoDAF V2.0 Volume 1 are:

The major emphasis on architecture development has changed from a product-centric process

to a data-centric process designed to provide decision-making data organized as information

for the manager.

• The three major viewpoints of architecture described in previous version (e.g., Operational,

Technical, and System) have been changed to more specific viewpoints that relate to the

collection of architecture-related data which can be organized as useful information for the

manager in decision-making. To support customer requirement and re-organization needs. All the models of data—conceptual, logical, or physical—have been placed into the Data

and Information Viewpoint.

-The Technical Standards Viewpoint has been updated to the Standards Viewpoint and

can describe business, commercial, and doctrinal standards, in addition to technical

standards.

– The Operational Viewpoint now can describe rules and constraints for any function

(business, intelligence, warfighting, etc.) rather that just those derived from data

relationships.

– Due to the emphasis within the Department on Capability PfM and feedback from the

Acquisition community, the Capability Viewpoint and Project Viewpoint have been

added.

• Products have been replaced by views that represent specific types of presentation for

architectural data and derived information.

• Architecture views are, in turn, organized into viewpoints, which provide a broad

understanding of the purpose, objectives, component parts, and capabilities represented by

the individual architectural views.

• The Department initiatives for Architecture Federation and Tiered Responsibility have been

incorporated into Version 2.0.

• Requirements for sharing of data and derived information in a Federated environment are

described.

• Specific types of architecture within the Department have been identified and described (e.g.,

Department-level [which includes Department, Capability & Component architectures] and

Solution Architectures).

• The DoD Enterprise Architecture is defined and described.

• Linkages to the Federal Enterprise Architecture are defined and described.

• Architecture constructs originally described in the UK Ministry of Defense Architecture

Framework (MODAF), the NATO Architecture Framework (NAF), and the Open Group

Architecture Framework (TOGAF) are adopted for use within DoDAF.

• A DM2, containing a CDM, a LDM, and a PES has been created.

• Approaches to SOA development are described and discussed.

Differences between (ADD) and MODAF

ADD ( Attribute-Driven design )

DODAF (Department of Defense Architecture Framework )

It’s a recursive method consists of 2 parts:

using tactics to achieve quality requirements:

make sure there is enough requirements information

decide which part of the system that will be decomposed

identify candidates architectural drivers

documenting decomposition:

instantiate architectural elements and assign responsibilities

define interfaces for the instantiated elements

verify requirements and define constraints for the instantiated elements

repeat all of the above steps for each element

DODAF consists of a set of rules and templates, known as Views that, when its established, it shows a graphical and textual visualization of the business being investigated. The Views are divided into 7 categories:

Operational view (OV) – description of the tasks and activities, operational elements and information exchanges required to accomplish the mission.

Systems View (SV) – a set of graphical and textual products that describes systems and interconnect- ions providing for, or supporting DoD functions

Technical Standards (TV) – set of rules governing the arrangement, interactions and interdependence of system parts or elements

MoD ARCHITECTURE FRAMEWORK (MoDAF)

The Ministry of Defense Architecture Framework (MODAF) defines a standard way to organize enterprise architectures for defense applications in the United Kingdom (UK). All major MOD weapons and information technology system procurements are required to document their enterprise architectures using the view products prescribed by the MODAF. MODAF is well suited to large systems and systems-of-systems (SoSs) with complex integration and interoperability issues. Although MODAF is primarily focused on defense applications, it can also be applied to commercial systems.

Guidance on MODAF

MODAF provides a coherent set of rules and templates, known as Views that, when populated, provide a graphical and textual visualization of the business area being investigated which would be developing both hardware and software for a phone running on android operating system. Each View offers a different perspective on the system to support different stakeholder interests. The Views are divided into seven categories:

Strategic Views (StVs) define the desired business outcome, and what capabilities are required to achieve. these kind of views will represent our main goal of the project which is developing a FullertonPhone system and defining the requirements that the customer desire.

Operational Views (OVs) define (in abstract rather than physical terms) the processes, information and entities needed to fulfil the capability requirements. those views will be used to define the processes required to apply the requirements of the customers.

Service Oriented Views (SOVs) describe the services, (i.e. units of work supplied by providers to consumers), required to support the processes described in the operational Views. Those views will be used by the customers to provide us with all the information required to produce work products.

Systems Views (SVs) describe the physical implementation of the Operational and Service Orientated Views and, thereby, define the solution. Those views will drive the implementation of the system

Acquisition Views (AcVs) describe the dependencies and timelines of the projects that will deliver the solution. Those views will be used to define the schedule that should be followed to fulfill the timeline of providing the system

Technical Views (TVs) define the standards that are to be applied to the solution. Those views will consider the standards that should be followed to develop the right work products and therefore providing the desired system

All Views (AVs) provide a description and glossary of the contents of the architecture

To ensure the coherence between the Views, MODAF is underpinned by a model which defines the relationship between all the data in all the Views. This model is called the MODAF Meta Model, also known as the "M3". The M3 also provides a technical standard to enable the exchange of data between architectures developed in different modeling (software) applications.

Specs of MODAF:

MODAF supports the application of rigour to requirements capture

The use of MODAF provides a de-facto element of rigour to requirements capture because the population of the Views requires the application of a structured analytical approach that leads the user from desired outcome to solution options.

MODAF supports the modeling of options

There are a number of commercially available tools that support the use of MODAF. As well as allowing the presentation of the Views, these tools also provide a repository in which the architecture can be stored and enable the modeling of different change options to support decision making.

MODAF supports interoperability

The use of MODAF as the standard architecture framework enables the coherent sharing of architectural information which helps identify gaps and overlaps between operating processes and the systems that support them.

MODAF has pedigree

MODAF was developed by MOD from the US Department of Defense Architecture Framework (DoDAF) version 1.0, but has been extended and modified to meet MOD requirements. MODAF is now itself internationally recognised as a best practice for enterprise architecting, and provided the template against which NATO Architecture Framework version 3.0 was developed.

MODAF has been adopted by organisations outside MOD

As well as MOD, MODAF is widely used by its industry partners, such as BAE Systems, Thales, Lockheed Martin, Boeing and Serco. It is also used by other government departments, such as GCHQ, and external bodies, such as the National Air Traffic Services. MODAF was recently adopted for use by the Swedish Armed Forces.

THE MODAF ARCHITECTING PROCESS

What is the MODAF Architecting Process?

The overall approach to developing a MODAF compliant architecture is broadly the same regardless of which MOD community is doing the work, or the MODAF views that are being generated. However, the MOD does not prescribe a "MODAF Method" for architecting and creating MODAF views. What this document presents is an example of one approach to take; there are many different ways to approach the architecting process.

In reality, few, if any, teams within the MOD will simply follow the general six-step process outlined above from start to finish once only and then not utilise the architectures again. In practice there will be a wide variety of approaches to conducting architectural work that will involve various iterations and variations around this general process.

Step 1 – Establish Intended Use

It is essential that any architectural activities are conducted with a clear purpose in mind; the production of a suitable abstraction of complex real world situations that are amenable to detailed analysis. Therefore, step 1 of the architecture development process is aimed at determining and documenting the intended usage of the architecture which can subsequently be used to test whether the developed architecture is fit for purpose. It is often useful to elicit statements of intended use for the architecture through a workshop that includes all of the potential stakeholders who are expected to provide data to and / or utilise the resulting architecture.

Step 2 – Define Architecture Scope

The key outcome of this stage is a clear definition of the content and boundaries of the architecture that is to be developed. This will include a definition of the architectural scope in relation to many dimensions, examples of which may include:

• Process scope.

• Organisational scope.

• Systems / platforms scope – including those that have to be interfaced with.

• Geographic scope.

• Coverage of the Defense Lines of Development.

• Degree of granularity that is to be modeled (eg system, subsystem or component).

During this stage the team should also start to consider how the architectural information is likely to be presented so as to address the "exam questions" developed during Step 1. This would normally include a list of the key MODAF views that are expected to be produced.

In some cases modified MODAF views may be desirable in order to enhance the required analysis or presentation of results. For example, modified MODAF views may include the addition of overlays to enhance understanding. However, there is a risk that modified views my not be compatible with other tools / repositories. Therefore, advice should be sought through the SEIG to ensure maximum compatibility.

At this stage it is also important to inform the MODAF governance processes of the intended architectural activities. This will help ensure that architecture developers can be made aware of all extant architectural data sources before they commence work and can also be put in touch with other teams that may be developing architectures with similar or overlapping scopes. As repositories become more densely populated this will considerably ease the burden of developing architectures – whole elements could be cut-and-pasted from extant models.

Step 3 – Develop Data Requirements

Before commencing data gathering in order to populate the architecture, it is good practice to establish a data gathering plan. This should include the definition of what data is required, the level of granularity of data that is required, identification of multiple / redundant data sources to provide data validation and / or back-up sources. The data gathering plan should also consider data formats, pre-processing and data migration issues.

Over time, architectural repositories should become a valuable source of existing architectural data which could be re-utilised with little, if any, translation effort required. This is why it is important to inform the MODAF governance processes of the architecture’s intended scope; to enable a central register of all the MOD’s architectural activities to be built. Based upon this scope information, the repository team(s) can provide a summary of the available architectural data that may be of value to the new architecture.

An important consideration associated with the data gathering plan is conducting an assessment of the security aspects of the populated architecture. This needs to consider not only the classification of the individual data sources, but also the potential for a higher classification if certain combinations / aggregations of lower classification data are presented through the architecture. Consideration should also be made of the security implications for accessing the published architectural data and conducting the required analyses.

Tool Selection

This is probably also the most appropriate stage of the overall process in which to consider tool selection. MODAF does not require a particular tool / suite of tools to be implemented; definitive guidance as to tool availability and fit with different COIs is not available.

Architecting teams should, however, consider the following when selecting a tool / suite of tools:

• Does the tool enable modeling of the architecture at the right level (eg is it modeling at the business level or the technical level? Can it provide the right level of detail?)

• Does / can the tool support the MODAF Meta Model (M3)?

• Can architectural models created in the tool be easily shared with other tools or with the SEIG repository?

• Can the tool exploit existing architectural models?

Having made the tool selection it may be necessary to provide tool-specific training to those who are going to be deeply involved in capturing and editing the architectural models. It is expected that there will be a variety of tool-specific MODAF course available through tool vendors and their intermediaries.

Step 4 – Capture Architecture

It is during this stage of the process that the bulk of the architecture development actually takes place: importing and editing extant architectural models, capturing additional data and entering it into the architecture. This is likely to include extracting data from existing architectures via the SEIG or other repositories.

When building the architecture it is important that it is only constructed in accordance with the MODAF Meta Model and MODAF Taxonomy4. These constraints underpin the MODAF tool interoperability mechanisms and compliance with them ensures that the architecture will be compatible with the SEIG and other repositories and that others will be able to re-use the content in the future. Help on how to achieve this will be available through the CIO MODAF team, The Information Coherence Authority for Defence or the SEIG.

It is important that before the resulting architecture is baselined for publication and analysis its accuracy and validity is confirmed. This should include a review of the entire architecture by the subject matter experts who have provided key inputs. It may also be advisable to consult the MODAF governance processes / SEIG during the review process to ensure that any dependent architectures (eg with details of interfacing processes or systems) have not changed or are not in the process of changing.

At this point in the architecture development process the baseline (ie pre-analysis) architecture should be published to an appropriate repository in order to provide visibility to others across the MOD.

In order to facilitate the searching and query of architectures it is essential that the All Views (AV-1 with meta data regarding the architecture and AV-2 with the architecture’s object dictionary) are completed thoroughly for all architectures before they are published. It may even be appropriate to start the documentation of the AVs during an earlier stage and to refine them as the scope of the architecture evolves.

Step 5 – Conduct Analyses

Given the validated baseline architecture delivered through step 4 of the process, all of the required data should now be available to conduct the analyses that were identified during step 1. These analyses are likely to be COI-specific, and may include a variety of analytical techniques, including but not limited to:

• Static analysis, such as a gap / overlap analysis against the Strategic Views in order to identify capability issues.

• Dynamic analysis such as network traffic / bandwidth analysis based upon network configurations from SV-1 and traffic data from OV-2 / OV-3.

• Experimentation. Using information developed from the architectural analysis to establish the use cases / context for experimentation campaigns such as those run through NITEworks.

• Trials. Using architectures to provide use case / context information for exercises and trials at a variety of scales from battle labs to full brigade or division level exercises.

Step 6 – Document Results

Having conducted the required analyses, changes to the baseline architecture will often be identified. Examples might include:

• Capability analysis may have highlighted a serious capability gap which has been developed into an EP option. The capability, timing and other details of which should then be entered into the finalised architecture

• System interoperability analyses may identify interface problems that have to be rectified by means of changes to the applicable standards or introduction of gateway equipment, which need to be included in the finalised architecture

When the architecture has been updated with the relevant changes it should again be subjected to a further review and the resulting finalized architecture published to the appropriate repository.

What is the MODAF Meta-Model?

The MODAF Meta Model (M3) is the reference model that underpins MODAF. It, defines the structure of the underlying architectural information that is presented in the MODAF views. The goal is that MODAF tools are ‘model-driven’; ie, the views that are presented to the user are snapshots of underlying architectural data which is stored in the tool or in a repository.

Individually, views can only provide consistency in terms of the type of information produced; ie, it can be recognised that one view is a systems model, whilst another is a process model. However, the same information may be represented in more than one view, and there may be important relationships between the information in different views that should be captured. This consistency between views is provided by a reference model which identifies all the types of architectural elements represented across all the views, and the relationships between those concepts. The reference model (or Meta Model in the case of MODAF) therefore provides semantic rigour for the architectural framework.

Many of the benefits from using an architectural approach will ultimately come about from the ability to share, integrate, search and re-use architectural information across an enterprise. In order for the architectural information to be stored, managed and queried electronically, the reference model that underpins the views needs to support the sharing of architectural products between tools and the implementation of an architectural repository that stores those products and the metadata relating to those products.

Differences between (ADD) and MODAF

ADD ( Attribute-Driven design )

MODAF ( Ministry Of Defense Architecture Framework )

It’s a recursive method consists of 2 parts:

using tactics to achieve quality requirements:

make sure there is enough requirements information

decide which part of the system that will be decomposed

identify candidates architectural drivers

pick the design concept that will satisfy the architectural drivers been identifid

documenting decomposition:

instantiate architectural elements and assign responsibilities

define interfaces for the instantiated elements

verify requirements and define constraints for the instantiated elements

repeat all of the above steps for each element

MODAF consists of a set of rules and templates, known as Views that, when its established, it shows a graphical and textual visualization of the business being investigated. The Views are divided into 7 categories:

Strategic Views (StVs) define the desired business outcome expected, and what capabilities are required to achieve it

Operational Views (OVs) define the processes, information and entities needed to achieve the capability requirements

Service Oriented Views (SOVs) define the services, (i.e. units of work supplied by providers to consumers), required to support the processes described in the operational Views

Systems Views (SVs) define the implementation of the Operational and Service Orientated Views and, thereby, define the solution

Acquisition Views (AcVs) define the dependencies and timelines of the projects that will deliver the solution

Technical Views (TVs) define the standards to be applied to the solution

ToG ARCHITECTURE FRAMEWORK (TOGAF)

The Open Group Architecture Framework (TOGAF) is a framework – a logical model, a detailed method and a set of supporting tools - for developing enterprise architecture. It may be used freely by any organization planning to develop an enterprise architecture .

TOGAF was developed by members of The Open Group, working within the Architecture Forum. The original development of TOGAF Version 1 in 1995 was derived from the Technical Architecture Framework for Information Management (TAFIM), developed by the US Department of Defense (DoD). The DoD gave The Open Group explicit permission and encouragement to create TOGAF by building on the TAFIM, which itself was the result of many years of development effort and many millions of dollars of US Government investment.

Starting from this sound foundation, the members of The Open Group Architecture Forum have developed successive versions of TOGAF each year and published each one on The Open Group public web site.

Structure of the TOGAF Document :

There are four main parts to the TOGAF document:

PART I

(Introduction) This Part provides a high-level introduction to some of the key concepts behind enterprise architecture and in particular the TOGAF approach.

PART II

(Architecture Development Method) This is the core of TOGAF. It describes the TOGAF Architecture Development Method (ADM) - a step-by-step approach to developing an enterprise architecture.

PART III

(Enterprise Continuum) This Part describes the TOGAF Enterprise Continuum, a virtual repository of architecture assets, which includes the TOGAF Foundation Architecture, and the Integrated Information Infrastructure Reference Model (III-RM).

PART IV

(Resources) This Part comprises the TOGAF Resource Base - a set of tools and techniques available for use in applying TOGAF and the TOGAF ADM.

What is TOGAF?

TOGAF is an architecture framework - The Open Group Architecture Framework. It enables you to design, evaluate, and build the right architecture for your organization.

The key to TOGAF is the Architecture Development Method (ADM) - a reliable, proven method for developing an IT enterprise architecture that meets the needs of your business.

What kind of architecture does TOGAF deal with?

There are four types of architecture that are commonly accepted as subsets of an overall enterprise architecture, all of which TOGAF is designed to support:

A Business (or Business Process) Architecture - this defines the business strategy, governance, organization, and key business processes.

A Data Architecture - this describes the structure of an organization's logical and physical data assets and data management resources.

An Applications Architecture - this kind of architecture provides a blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization.

A Technology Architecture - this describes 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, standards, etc.

Who would benefit from using TOGAF?

Any organization undertaking, or planning to undertake, the design and implementation of an enterprise architecture for the support of mission-critical business applications, using open systems building blocks.

Customers who design and implement enterprise architectures using TOGAF are ensured of a design and a procurement specification that will greatly facilitate open systems implementation, and will enable the benefits of open systems to accrue to their organizations with reduced risk.

What specifically does TOGAF contain?

TOGAF provides a common-sense, practical, prudent, and effective method of developing an enterprise architecture.

TOGAF consists of three main parts:

TOGAF ADM

The TOGAF Architecture Development Method(ADM) gives a walkthrough for implementation and execution of an organization’s EA. The process is made up of multiple sequential phases which is shown below in form of a closed loop.(FIGURE 10)

figure 10

Figure 10: TOGAF Architecture Development Method (ADM)

Preliminary Phase: decides the implementation process stakeholders and accommodate them together. This phase gives over Architecture Guiding Principles which is depended on the organization’s business principles and explains methods and terms for monitoring the EA implementation’s development.

Phase A is dedicated to find the business objectives and if failed in finding the business objectives then this phase takes the responsibilities of setting up the business objectives and how to execute these objectives. The Statement of Architectural Work, which is also obtained in this phase characterize the EA’s scope and limitations and obtains a plan for the architectural work.

Phase B is devoted to the detail design of the architecture of the business which leads to technical analysis. Business process modeling, business object modeling and use case modeling are important techniques used to obtain the Business Architecture.

Phase C is dedicated to delivery of Application and Data architectures for current and anticipated environments, meeting the scope and following plan as mentioned in the Statement of Architectural Work.

Phase D completes the detailed architecture work of the TOGAF ADM cycle with the delivery of Technology Architecture. As in the preceding phases, gap analysis and draft architectures are used as a baseline, as are the architecture guiding principles agreed upon in the preliminary phase. Modeling notations, such as UML, are actively used during this phase to produce various viewpoints.

Phase D gets over with the Architecture work and delivers the Technology Architecture. Modeling notations(UML) are significantly used in this phase to obtain various viewpoints.

Phase E is especially dedicated to figure out the opportunities presented by the target architectures and comes out with the potential solutions which are practical and feasible.

Phase F moves to prioritize proposed implementation projects and perform detailed planning and gap analysis of the migration process. This work includes assessing dependencies between projects and minimizing their overall impact on enterprise operations. In this phase, the Project List is updated, the Implementation Plan is detailed, and the Blueprint is handed to the implementation teams.

Phase F focuses on the implementation and hence hands over the blueprint to the implementation team after updating the Project List and structuring the Implementation Plan.

The focus in Phase H shifts towards change management of the architecture baseline that is achieved with the delivery of the implemented solutions. The phase might produce a Request for Architecture Work that sets targets for a subsequent cycle of enterprise architecture efforts.

Phase H works towards the change management of the architecture baseline which is achieved after the delivery of solutions.

2) The Enterprise Continuum, which is a "virtual repository" of all the architecture assets - models, patterns, architecture descriptions, etc. - that exist both within the enterprise and in the IT industry at large, which the enterprise considers itself to have available for the development of architectures. At relevant places throughout the TOGAF ADM, there are reminders to consider which architecture assets from the Enterprise Continuum the architect should use, if any. TOGAF itself provides two reference models for consideration for inclusion in an enterprise's own Enterprise Continuum:

The TOGAF Foundation Architecture - an architecture of generic services and functions that provides a foundation on which specific architectures and Architecture Building Blocks (ABBs) can be built. This Foundation Architecture in turn includes:

The TOGAF Technical Reference Model (TRM), which provides a model and taxonomy of generic platform services

The TOGAF Standards Information Base (SIB), which is a database of open industry standards that can be used to define the particular services and other components of an enterprise-specific architecture

The Integrated Information Infrastructure Reference Model (III-RM), which 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.

3) The TOGAF Resource Base, which is a set of resources - guidelines, templates, background information, etc. - to help the architect in the use of the ADM.

Just how do you use TOGAF?

TOGAF is published by The Open Group on its public web site, and may be reproduced freely by any enterprise wishing to use it to develop an enterprise architecture for use within that enterprise.

Basically, information about the advantages and limitations of the existing implementation, together with requirements for change, are combined using the methods described in the TOGAF ADM, resulting in a "Target Architecture" or set of Target Architectures.

The SIB provides a database of open industry standards that can be used to define the particular services and components required in the products purchased to implement the developed architecture. The SIB provides a simple and highly effective way to procure against enterprise architecture.

How much does TOGAF cost?

The Open Group operates as a not-for-profit consortium committed to delivering greater business efficiency by bringing together buyers and suppliers of information systems to nullify the barriers of integrating new technology across the enterprise. Its goal is to realize the vision of Boundary less Information Flow.

TOGAF is a key part of its strategy for achieving this goal, and The Open Group wants TOGAF to be taken up and used in practical architecture projects, and the experience from its use fed back to help improve it.

The Open Group therefore publishes TOGAF on its public web server, and allows and encourages its reproduction and use free-of-charge by any organization wishing to use it internally to develop an enterprise architecture. (There are restrictions on its commercial exploitation, however).

Since TOGAF is freely available, why join The Open Group?

Organizations wishing to reduce the time, be cost-effective, and risk of implementing multi-vendor solutions that integrate within and between enterprises opt for The Open Group as their key partner.

The Open Group binds together the buyers and suppliers of information systems worldwide, and enables them to work together, both to ensure that IT solutions achieves customer satisfaction, and to make it easier to integrate IT across the enterprise.

The Open Group Architecture Framework is a key enabler in this task.

Yes, TOGAF itself is freely available. But how much will you spend on developing or updating your enterprise architecture using TOGAF? And how much will you spend on procurements based on that architecture?

The price of membership of The Open Group is insignificant in comparison with these amounts.

In addition to the general benefits of membership, as a member of The Open Group you will be eligible to participate in The Open Group Architecture Forum, which is the development program within which TOGAF is evolved, and in which TOGAF users come together to exchange information and feedback.

Members of the Architecture Forum gain:

Immediate access to the fruits of the current year's TOGAF work program (not publicly available until publication of the next edition of the TOGAF document) - in effect, the latest information on TOGAF, as opposed to information that is up to a year old

Exchange of experience with other customer and vendor organizations involved in enterprise architecture in general, and networking with architects using TOGAF in significant architecture development projects around the world

Peer review of specific architecture case study material

Where does TOGAF fits in ?

TOGAF is a framework that provides organizations with a step by step method of creating an enterprise level architecture.

It defines placeholders for defining things common to all organisations delivering services in an enterprise environment (and smaller).

• Business architecture – The strategy, governance and business processes governing how the business goes about it’s work

• Data architecture – A definition of the organisations logical/physical data stores, meta data and management resources

• Application architecture – Blueprints for how software systems interact with each other, are deployed and their relationships to business processes (mapped in the business architecture)

• Technology architecture – The assets of an organisation used to deliver its IT capabilities. Logical software models, hardware resources, support requirements, data/application capabilities etc. Includes things like network topologies, comms, standards etc.

Advantages of TOGAF :

• Decreased cost – Most of the upsides of E.A. have a cost benefit. Without it or providing significant business advantage there’s no point. However it’s ‘challenging’ to produce figures in most cases.

• Organisation reference model– Amongst other benefits, having a good idea of what you have now gives a better chance of executing change reasonably efficiently.

• Reduced effort – Endeavours such as design, development, business as usual should become easier/quicker.

• Increased visibility – Information about people, processes and systems is easier to access

DIFFERENCE BETWEEN ADD AND TOGAF:

ADD (Attribute Driven Design)

TOGAF ( The Open Group Architecture Framework)

ADD is a recursive method which consists of two parts

Using tactics to achieve quality requirements:

To confirm whether there is sufficient information about requirements.

to choose the element that is to decomposed.

Identifying candidate architectural drivers.

To choose design concept that satisfies architectural drivers.

Documenting Decomposition:

Instantiating architectural elements and allocating responsibilities.

Define interfaces for instantiated elements.

Verify & refine requirements and make them as constraints for instantiated elements.

Repeat steps to decompose next element.

TOGAF enable us to design, evaluate, and build the right architecture for the organization.

TOGAF Architecture Development Method(ADM) which explains how to derive an organization. ADM has multiple phases.

Phase A: Architecture Vision

Phase B: Business Architecture

Phase C:Information Systems Architecture

Phase D:Technology Architecture

Phase E:Opportunities&Solutions

Phase F:Migration Planning

Phase G:Implementation Governance

Phase H:Architecture change management

The Enterprise Continuum which is known as virtual repository of all architecture assets such as models, patterns, architecture descriptions etc.

TOGAF provides 2 reference models for consideration for inclusion in an enterprise's own enterprise continuum

TOGAF foundation architecture of generic services and functions that provide foundation for building architecture

The Integrated Information Infrastructure Reference Model (III-RM) based on TOGAF foundation architecture specifically aimed at helping the design of architecture.

The TOGAF resource base , a set of resources such as guidelines, templates, background information etc.

Overview of TOGAF in the Future

TOGAF in the future is more likely to introduce the use interactive tools which will facilitate the use of that extended range of information recorded in selecting building blocks.The whole purpose is to enhance TOGAF with a Building Blocks Information Base(BBIB),containing information about architectural and solution building blocks for implementation in architecture design.

http://pubs.opengroup.org/architecture/togaf7-doc/arch/p3/intro/fig1-2.gif

Figure 1: Overview of TOGAF in the Future

ATTRIBUTE DRIVEN DESIGN

The Attribute Driven Design(ADD) is developed by Carnegie Mellon Software Engineering Institute(SEI). It is an approach to define a software architecture in which the design process is based on the software quality attribute requirements. ADD follows a recursive process that decomposes a system or system element by applying architectural tactics and patterns that satisfy its driving quality attribute requirements.

The Attribute Driven Design is a process in which the system is divided into small workable components. Quality Attributes are considered to select the types of elements. `These Elements satisfy the Quality Attribute requirements as well as Functional requirements.

The Attribute Driven Design(ADD) essentially follows a "Plan, Do and Check" cycle.

PLAN: Quality Attributes and design constraints are considered to select which types of elements will be used in the architecture.

DO: Elements are instantiated to satisfy quality attribute requirements as well as Functional requirements.

CHECK: The resulting design is analyzed to determine if the requirements are met.

This process is repeated until all architecturally significant requirements are met.

System

Quality Attribute Requirements

Design Constraints

Functional Requirements

System

Key:

Interface

Software Element

Uses

Realizes

Plan : Select types of Elements

Do : Instantiate Elements

Check : Analyze Design

Syste

STEPS OF ATTRIBUTE DRIVEN DESIGN(ADD) :

Steps of ADD

Inputs : Inputs for Attribute Driven Design are Functional Requirements, Design Constraints, and Quality Attribute Requirements that system stakeholders have prioritized according to business and mission goals.

Functional Requirements specify what functions a system must provide to meet stated and implied stakeholder needs when the software is used under specific conditions.

Design Constraints are decisions about a system's design that must be incorporated into any final design of the system. They represent a design decision with a predetermined out comes.

Quality Attribute Requirements are requirements that indicate the degrees to which a system must exhibit various properties.

Outputs to expect from ADD: The output of Attribute Driven Design is a system design in terms of the roles, responsibilities, properties, and relationships among software elements.

Software Element: A computational or developmental artifact that fulfills various roles and responsibilities, has defined properties, and relates to other software elements to compose the architecture of a system.

Role: A set of related responsibilities.

Responsibility: The functionality, data, or information that a software element provides.

Property: Additional information about a software element such as name, type, quality attributes characteristic, protocol, and so on.

Relationship: A definition of how two software elements are associated with or interact with one another.

The initial software architecture description from a set of design decisions produced by Attribute Driven Design (ADD) shows

How a system is to be partitioned into major computational and developmental elements.

The Elements are divided based on the properties and type of each element and structural relations they possess. The elements are differentiated with the structure of the system.

What interactions occur between these elements, the properties of those interactions and mechanisms by which they occur.

Step 0 : The requirements are prioritized by systems stakeholders according to business and mission goals. This comes outside the scope of Attribute Driven Design.

Step 1: This step confirms that there is sufficient information about the requirements. The architect confirms that there is sufficient information about the quality attribute requirement. Each of these Quality attribute requirements is expressed in a "Stimulus-Response" form.

Step 2: The Element of the system to be decomposed is chosen in this step. The only element to be decomposed is the system itself in the first iteration. In the following iterations the element is selected which is to decomposed based on the business and organizational criteria.

Step 3: This step identifies the candidate architectural drivers. The requirements that are ranked based on architectural impact are grouped based on priorities to the importance of stakeholders and their impact on architecture.

Step 4: The design concept that satisfies the architectural drivers is chosen in this step. This design concept includes all major types of elements that appear in the architecture and types of relationship between them.

Step 5: In this step previously selected software elements are instantiated and the instantiated elements are assigned with some responsibilities according to their types. Responsibilities are derived from the functional requirements associated with the candidate architectural drivers and parent element.

Step 6: The services and properties are defined that are required and provided by the software elements in our design. These services and properties are referred as element's interface in attribute driven design.

Step 7: In this step it is verified that the element decomposition meets the functional requirements, design constraints and quality attribute requirements. And also child elements are prepared for further decomposition.

Step 8: Once all the steps are completed the parent element is decomposed into child element and each child element is a collection of responsibilities. Steps 2 through 7 are repeated for the next element to be decomposed.

CHALLENGES:

Designing architecture for a system that meets user needs.

Meeting Quality Attribute Requirements for envisioned systems.

Determining architectural strategies that are appropriate for quality attribute requirements.

Understanding the impact of quality attribute tradeoffs while designing software architecture.

DESCRIPTION:

Applying Attribute driven design results in the decomposition of the architecture, documented using architectural views. Attribute driven design(ADD) is a recursive method and it has two parts

Part 1: Using tactics to achieve quality requirements.

Confirm that there is sufficient information about requirements.

Element of the system to decompose is chosen.

Identify Candidate architectural drivers.

Design concept satisfying architectural drivers is chosen.

Part 2: Documenting Decomposition

Instantiate architectural elements and allocate responsibilities.

Define interfaces for instantiated elements.

Verify and refine requirements and make them as constraints for instantiated elements.

Repeat these steps for decomposing next element.

BENEFITS:

The Attribute Driven Design (ADD) is a process that enables designers to understand quality attribute tradeoffs in the design process and helps in designing an architecture that satisfies both Quality Attribute and Functional requirements.