Architecture Frameworks

An enterprise architecture (EA) is a blueprint for conducting enterprise analysis, design, planning, and implementation. Just like building structural architecture, the blue print is a guide for a successful development and execution of strategy for software project.

The purpose of enterprise architecture is to determine how an organization can most effectively achieve the current and future objectives of its business goals. A good enterprise architecture provide governing principles that drive an ongoing discussion about business strategy and how it can be expressed through technology.

Enterprise architects are professionals who put building blocks together for a complete view of enterprise technology map such as to ensure that technology systems are aligned with ongoing business need, strategies and standards.

An enterprise architecture framework (EA framework) provides a guideline on how to create and use an enterprise architecture.It provides tools and approaches that help enterprise architects to optimize different architecture domains 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. Typically, the architecture domains are listed below based on four basic interrelated areas of specialization:
Enterprise Architecture framework

  • Business architecture defines the business strategy, governance, organization, and key business processes of the organization
  • Applications architecture provides a blueprint for the individual systems to be deployed, the interactions between the application systems, and their relationships to the core business processes of the organization with the frameworks for services to be exposed as business functions for integration
  • Data architecture describes the structure of an organization’s logical and physical data assets and the associated data management resources
  • Technical architecture describes the hardware, software, and network infrastructure needed to support the deployment of core, mission-critical applications

The Major EA Frameworks

Architecture Framework organizes the system architecture of an enterprise into different views so that they can be discussed from different perspective such as Data, System, Process, Flow. There are different types of frameworks:

  1. Template Framework – Zachman Framework
  2. Content Framework, i.e. The Open Group Architecture Framework (TOGAF), the DoD Architecture Framework (DoDAF), the variants (MODAF and NAF), and
  3. Unified Profile for EA frameworks from OMG (UDPM, UAF):

EA Template Framework

The EA Template Framework is any specific method or process for collecting, managing or using the information that it describes.; rather, it is an ontology whereby a schema for organizing architectural artifacts (in other words, design documents, specifications, and models) is used to take into account both who the artifact targets (for example, business owner and builder) and what particular issue (for example, data and functionality) is being addressed.

The Zachman Framework

Zachman Framework is an enterprise ontology and is a fundamental structure for Enterprise Architecture which provides a way of viewing an enterprise and its information systems from different perspectives and showing how the components of the enterprise are related. The Zachman Framework goes beyond IT. It offers structural connections into any aspect of an enterprise.

The rows of Zachman Framework focus on describing the enterprise from six viewpoint perspectives of the stakeholders. These six perspectives are based on English language interrogatives ‘what’, ‘where’, ‘who’, ‘when’, ‘why’, and ‘how’ (known as W5H).

The columns of the framework consist of a set of artifacts that are a description of the enterprise from a specific viewpoint of a group of stakeholders. The stakeholders are generally grouped as planners, owners, designers (architects), implementers, sub-constructors, users, or sometimes represented as viewpoints: scope context, business concepts, system logic, technology, physics, component assemblies, and operations classes.

The framework enables complex subjects to be distilled into systematic categories in the column headers, using these six basic questions (known as 5WH). The answers to these questions will differ, depending on the perspective or audience (represented in the rows)

EA Content Framework

An EA content framework defines the artifacts that EA should produce. In TOGAF, the ADM defines the method including the process, steps, and guidelines for developing the artifacts and deliverables for each of the development phases.

The Open Group Architectural Framework (TOGAF)

The Open Group Architectural Framework (TOGAF) was first developed in 1995 created and owned by The Open Group, which was based on the Department of Defense’s Technical Architecture Framework for Information Management. It is one of the most common framework structures in business today and accounts for over 80 percent of the entire business framework structure. TOGAF contains all the needed pieces for a powerful framework. It has a common vocabulary to use, recommended standards and compliance methods, suggested software and tools, and even a method to define best practices.

TOGAF is often viewed as more an overarching process. The details and methods contained within TOGAF help guide businesses through any step of business organization. A key element of TOGAF is the Architecture Development Method (ADM) which specifies a process for developing enterprise architecture.

The TOGAF Framework consists of six important parts as shown in the following figure:

  • Architecture Development Method (ADM)
  • ADM Guidelines and Techniques
  • Architecture Content Framework
  • Enterprise Continuum & Tools
  • TOGAF Reference Models
  • Architecture Capability Framework

DOD ARCHITECTURE FRAMEWORK (DODAF)

The DoD Architecture Framework (DoDAF) is the industry-standard Enterprise Architecture Framework for defense and aerospace applications. It defines how to organize the specification of enterprise architectures for the U.S. Department of Defense (DoD) applications. All major DoD weapons and information technology system procurements are required to document their enterprise architectures using the view products prescribed by the DoDAF. Although DoDAF is primarily focused on defense applications, it can also be applied to commercial systems. The DoDAF provides a foundational framework for developing and representing architecture descriptions that ensure a common denominator for understanding, comparing, and integrating architectures across organizational, joint, and multinational boundaries.

DoDAF establishes data element definitions, rules, and relationships and a baseline set of products for consistent development of systems, integrated, or federated architectures. It is well suited to large systems and systems-of-systems (SoSs) with complex integration and interoperability issues. The objective of DoDAF is to concretely define models and concepts that are usable in the DoD’s core processes:

  • Joint Capabilities and Integration Development (JCIDS)
  • Planning, Programming, Budgeting, and Execution (PPBE)
  • Defense Acquisition System (DAS)
  • Systems Engineering (SE)
  • Operational Planning (OPLAN)
  • Capability Portfolio Management (CPM)

Version 2.0 of the DoDAF had the following specific goals:

  • Establish guidance for architecture content as a function of purpose – “fit for purpose”
  • Increase utility and effectiveness of architectures via a rigorous data model – the DoDAF Meta Model (DM2) — so the architectures can be integrated, analyzed, and evaluated with more precision.

Version 2.0 viewpoints:

In DoDAF V2.0, architectural viewpoints are composed of data that has been organized to facilitate understanding. To align with ISO Standards, where appropriate, the terminology has changed from Views to Viewpoint (e.g., the Operational View is now the Operational Viewpoint).

All Viewpoint (AV) – Describes the overarching aspects of architecture context that relate to all viewpoints.

Capability Viewpoint (CV) – New in DoDAF V2.0. It articulates the capability requirements, the delivery timing, and the deployed capability.

Data and Information Viewpoint (DIV) – New in DoDAF V2.0. Articulates the data relationships and alignment structures in the architecture content for the capability and operational requirements, system engineering processes, and systems and services.

Operational Viewpoint (OV) – Includes the operational scenarios, activities, and requirements that support capabilities.

Project Viewpoint (PV) – New in DoDAF V2.0. Describes the relationships between operational and capability requirements and the various projects being implemented. The Project Viewpoint also details dependencies among capability and operational requirements, system engineering processes, systems design, and services design within the Defense Acquisition System process.

Services Viewpoint (SvcV) – New in DoDAF V2.0. Presents the design for solutions articulating the Performers, Activities, Services, and their Exchanges, providing for or supporting operational and capability functions.

Standards Viewpoint (StdV) – Renamed from Technical Standards View. Articulates the applicable operational, business, technical, and industry policies, standards, guidance, constraints, and forecasts that apply to capability and operational requirements, system engineering processes, and systems and services.

Systems Viewpoint (SV) – Articulates, for legacy support, the design for solutions articulating the systems, their composition, interconnectivity, and context providing for or supporting operational and capability functions.

Federal Enterprise Architectural Framework

The Federal Enterprise Architectural Framework (FEA) is one of the newest attempts to create a solid structure for organizations. The US Federal Government developed it in 2006. It helps organize the myriad of different agencies and organizations under its control.

  • Its predecessor, the FEAF, started in 1996.
  • The FEA combines the best of both the Zachman Framework and TOGAF.
  • The FEA has five reference models. They cover business, service, components, technical, and data. These five points combine with a segment model to create a perspective on how best to install enterprise architecture.
  • The segment model at its core allows a distinction of any number of organizations and connections.
  • FEA was the foundation for a massive restructuring of a high-end government. As such, the framework is a strong core to follow when building a strong foundation for a future company.

MODAF Framework

The Ministry of Defense Architecture Framework (MODAF) is an internationally recognized enterprise architecture framework developed by the Ministry of Defence (MOD) to support defense planning and change management activities. It does this by enabling the capture and presentation of information in a rigorous, coherent and comprehensive way that aids the understanding of complex issues.

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. Each view offers a different perspective on the business to support different stakeholder interests.

The views are divided into 7 categories:

  1. Strategic views (StVs) define the desired business outcome, and what capabilities are required to achieve it
  2. Operational views (OVs) define (in an abstract rather than physical terms) the processes, information, and entities needed to fulfill the capability requirements
  3. 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
  4. Systems views (SVs) describe the physical implementation of the operational and service orientated views and, thereby, define the solution
  5. Acquisition views (AcVs) describe the dependencies and timelines of the projects that will deliver the solution
  6. Technical views (TVs) define the standards that are to be applied to the solution
  7. 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 that defines the relationship between all the data in all the views. This model is called the MODAF.

Unified Profile for DoDAF / MODAF (UPDM 1.1)

UPDM is the Unified Profile for DoDAF / MODAF /NAF 3.0. It has been realized by the OMG (Object Management Group) to provide modeling support conforming to the USA Department of Defense Architecture Framework (DoDAF) and the UK Ministry of Defence Architecture Framework (MODAF).

NAF 4.0

The NAF is designed to ensure that architectures developed adhering to it can be understood, compared, justified and related across many organizations, including NATO and other National Defence initiatives. The aim of the NATO Architecture Framework Version 4 (NAFv4) is to provide a standard for developing and describing architectures for both military and business use. The objectives of the framework are to:

  • Provide a way to organize and present architectures to stakeholders
  • Specify the guidance, rules, and product descriptions for developing and presenting architecture information
  • Ensure a common approach for understanding, comparing, and integrating architectures,
  • Act as a key enabler for acquiring and fielding cost-effective and interoperable capabilities
  • Align with architecture references produced by international standard bodies

NAF 4.0 defines Viewpoints, Views and Architecture Descriptions. It details a two-dimensional classification scheme for the standardized architecture viewpoints, this serves as the baseline for any NAF-Compliant architecture effort. To aid architects, these viewpoints are organized into a logical and consistent manner and presented as a “grid”. This ‘grid’ structure, represents the various ‘subjects of concern’ (rows) and ‘aspects of concern’ (columns), as shown below:

The Latest Integration UAF from OMG

The Unified Architecture Framework® (UAF®) is based on the Unified Profile for DoDAF and MODAF™ (UPDM™). UAF defines ways of representing an enterprise architecture that enables stakeholders to focus on specific areas of interest in the enterprise while retaining sight of the big picture. UAF meets the specific business, operational and systems-of-systems integration needs of commercial and industrial enterprises as well as the U.S. Department of Defense (DoD), the UK Ministry of Defence (MOD), the North Atlantic Treaty Organization (NATO) and other defense organizations.

UAF provides a set of rules to enable users to create consistent enterprise architectures (as models) based on generic enterprise and system concepts with rich semantics. These models then become the repositories from which various views can be extracted. UAF supports current DoDAF/MODAF/NAF requirements and can evolve to meet future needs:

  • produce standard DoDAF / MODAF / NAF products as well as commercial extensions
  • leverage cross-industry, standards-based approaches (e.g., MDA, UML, SysML) to enhance tool and architecture data interoperability
  • MDA foundation enables UAF to evolve with DoDAF v2 and beyond (i.e. security, human factors)
  • UAF is methodology-agnostic (structured, OO, etc.)

4+1 architectural view model

4+1 is a view model are used to describe the system from the viewpoint of different stakeholders and selected use case and scenarios.
Those are
– end-users,
– developers,
– system engineers, and
– project managers.
There are 4 view of architecture. Adding selected use cases or scenarios to illustrate the architecture is one addition view. Hence 4+1 view framework.

TIME Model

Tolerate: The top left quadrant reveals areaswhere there is a high quality application but low business value. Since it has high quality, there is not a lot of time or money invested to support this particular application and it is providing a certain amount of value. Since the value is not negligible, it is being used, and it doesn’t cost a lot to keep the lights on – those applications should be tolerated. You shouldn’t increase your level of investment but at the same time, you shouldn’t waste resources to kill it either. It is serving its purpose, it is good enough.

Invest: The next quadrant over is looking at high quality applications with a much higher business value. You have the best of both worlds here. The application is stable, it doesn’t require a lot of support, it is architected well, and you have the source code. Even better, the business actually uses it. It helps them do things like reducing headcount, increasing throughput, improving data quality, and enhancing business processes. There is an attributable and recognizable value. These are the applications worth investing in further to get even better returns or reduce more costs.

Migrate: Migrate is a little more difficult to identify because it has more nuance to it. It is similar to invest but it is low quality and high value. The business is definitely using the application and can articulate its value, the problem is, IT is dying on the vine of these applications. There could be a high cost of support, lack of knowledge, lack of source code, or a variety of different factors that make it an expensive application to maintain. Therefore, rather than continue the expense, you should look to migrate those applications. A lot of times this is confused with investing but investment is taking a current application and improving upon it or adding to it, but migrating is looking to recoup the value in another application. A great example of this we see often is with Lotus Notes. It provides distinct business value for collaboration but it is very expensive to maintain and is getting more expensive as the skill set to manage it is getting rarer and you have less people capable of supporting it. So, rather than investing in building a bigger Lotus Notes environment or hire more Lotus Notes developers, which would be the invest aspect, we would recommend migrating. Identify a similar technology where you can get 80% or more of the functionality and move towards it. Establish a migration path to a technology that is more similar to what you already have in the environment. In the Lotus Notes example, moving toward Microsoft SharePoint would give you a lot of the functionality you need as well as the integration with Exchange.

Eliminate: Eliminate is an essential part of the software lifecycle but is often missed. This quadrant looks at applications that are low quality and low business value. Sometime this can be very obvious – the application is down a lot, it takes a long time to fix, there might be only one person that knows how to use it and when that person is on vacation, the whole world is down. Nobody uses it except for one person on one day of the month. The biggest challenge is when this person is someone like your CEO or CFO. This is where you need intestinal fortitude to sunset the application and free up your resources.

While simple in its approach, TIME allows us to quickly review an application’s ability to meet business goals versus the technical integrity of the solution. This analysis is valuable on an annual or cyclical basis to evaluate the application portfolio over time as both technology and business goals change. Try it for yourself – we’ve created a free worksheet to help you get started evaluating your applications with TIME today!

References:

TOGAF References:

  • https://pubs.opengroup.org/architecture/togaf9-doc/arch/index.html
  • https://pubs.opengroup.org/architecture/togaf8-doc/arch/
  • https://pubs.opengroup.org/architecture/togaf8-doc/arch/toc.html
  • http://www.togaf.info/togaf9/togafSlides9/TOGAF-V9-Sample-Catalogs-Matrics-Diagrams-v2.pdf
  • https://pubs.opengroup.org/togaf-standard/integrating-risk-and-security/index.html

General References on Enterprise architecture: