EA Domain Ontology

Domain Context

Domain Definition needs to be:

• Need to support industry standard method

• Neutral towards tools and technologies

• Ca be used for developing the products associated with any recognized architecture

Current EA framework examples

• Open Group TOGAF

• Zachman Framework

• Federal Enterprise Architecture Framework (FEAF)

• Treasury Enterprise Architecture Framework (TEAF)

• C4ISR/DoD Framework

Commonality and variance

Domain strategy also impacts on commonality and variations

What functionality is enterprise and what is in Domain

(The enterprise-domain dichotomy)

Source: The Open Group

The Enterprise-Domain Dichotomy

An everyday question is when is functionality better designed and exposed as an enterprise service or encapsulated as domain functionality? For example, is it better to access data from a database by developing generic enterprise functionality and then permit variability by overriding that functionality in an application, or should each application manage the whole data access process itself?

What

The enterprise-domain dichotomy recognizes the design dilemma that architects and developers grapple with: What functionality is better defined as enterprise or domain functionality?

Where

The dichotomy is present throughout the enterprise wherever the same or similar functionality is required by multiple applications, or similar functionality is required within a given application.

Why

It is not always obvious when functionality has an enterprise implication. Often, with hindsight, it may have been better to design an application not as a domain application, but as abstract functionality in the enterprise services layer or platform. However, using an enterprise or services option consumes more design and development resources, and the last thing that we want to do is waste resources by cluttering enterprise services with functionality that turns out not to be sufficiently enterprise in nature. On the other hand, while "domain" functionality that turns out to have an "enterprise" role may be migrated from the domain to the enterprise services layer, which is a common practice, that may be expensive and disruptive.

How

The ways that the dichotomy is handled may be classified using the following terminology: proactive code review, reactive code review, and passive code review. A proactive code review requires that all proposed functionality is reviewed to determine whether there is an enterprise implication, as a preliminary to design and development. Often, an "in-house" cutoff rule may be used as a measure to determine whether functionality is a candidate for an enterprise service; for example, if there is a reasonable likelihood that given functionality may be used three or more times (in one or multiple applications), then it qualifies to be designed and developed as enterprise functionality. A reactive code review requires that if functionality fails the proactive review (i.e., it was considered that it would be used once or twice), then it is developed as domain code, where maximum use is made of variable or discretionary coupling (see the section "Coupling" later in this chapter) and maximum use is made of generalization (i.e., programming against abstract classes and interface types). Then, if subsequently it emerges that the functionality has been used three times, consider migrating the functionality into the services layer and referencing it by the domain application. Finally, a passive code review is the extreme high-risk option: don't review code from an enterprise perspective (in other words, ignore the dichotomy). That option exposes the organization to the cost of duplication, likelihood of application lock-ins, and reengineering or application replacement in the future. The terminology is summarized as follows:

• Proactive code review: Prior to development, review all new functionality and apply a cutoff reuse rule: for example, where functionality is likely to be used three or more times, then develop it as an enterprise service (e.g., develop a regex enterprise class).

• Reactive code review: Subsequent to a proactive code review, if code is duplicated three times, then review code and consider reengineering the functionality as an enterprise service (e.g., develop a regex domain class and subsequently reengineer or refactor it as regex enterprise functionality).

• Passive code review: Exclude code from a proactive or reactive review (e.g., develop similar or duplicate regex classes) with domain coupling and without generalization.

The Standard: Design Dichotomy

The standard acknowledges that consideration may be given to determine whether functionality has an enterprise or a limited domain role. The earlier the consideration is made, the better.

Modularity

Implicit in an information technology structure is the componentization of software and hardware, which is encapsulated within layers and coordinated into a seamless system of functionality.

What

Modularity refers to the ability to encapsulate functionality into a unit, which exposes an interface against which other modules may connect. A module may be independent or rely on a dependency. The Unified Modeling Language (UML) notation has a module (e.g., class) shared in two types of dependencies or associations (e.g., aggregation and composition) with other modules of functionality.

Note

An aggregation association is one where two modules may exist independently; however, they may form a relationship to make up a whole. For example, a garage may be used independently, as may a car; however, they may form an association that enables the car to be parked in the garage. A composition association, which is a form of an aggregation association, is one where there is an independent and a dependent party. For example, a car tire is independent of a car—it may be used on a trailer; however, the car is dependent on a tire (or several of them), because a car is composed of tires (and other components).

Where

Modularity is used across the enterprise framework, from an architecture layer to a class module.

Why

Modularity is premised on cohesion and self-responsibility, which are attributes essential to designing, developing, and maintaining composite structures (e.g., software and hardware structures). The importance of modularity to structural design further underscores the value of development using a first class object-oriented development tool, such as C#.

How

There are many implementations of modularity, for example, class module, namespace, assembly, layer, and architecture. To encapsulate modularity, the unit must also expose an interface through which it may participate in an association with other modules, in order to form a composite or super structure. To minimize maintenance and maximize longevity, the interface should be sufficiently abstract, loosely coupled, and appropriately deployed.

The Standard: Modularity

The standard acknowledges the use of modularity as a method to design, build, and maintain complex structures.

Coupling

A tenet of good design is that artifacts are loosely coupled, yet coupling is ambivalent: it represents an association and detachment.

What

Coupling represents the association between two or more artifacts; for example, a business object is coupled to the schema of a database table. Or an application is coupled to an operating system. There are two aspects to coupling: it has fixed and variable attributes. Fixed coupling refers to that part of the association over which, within a given context, there is no discretion. For example, if a business object represents an employee and all employee data is held in tblEmployee table, then the business object has a fixed coupling with the table. Variable or discretionary coupling refers to how a fixed coupling is implemented. A business object, for example, may access employee data indirectly through an interposed data-controller object, or it may access the data directly. If the object was to directly access the data from tblEmployee, then it would be a tightly coupled association; however, if it accessed the data through an interposed object, then it would be loosely coupled, relative to tblEmployee. It is only through recognizing a fixed and a variable attribute that we are able to explain the ambivalence of coupling.

Where

Coupling is present throughout the enterprise framework; it is unavoidable where there are associations.

Why

Coupling is a necessary part of associations or collaborations. It recognizes that artifacts have specialized roles and that to compose functionality, artifacts have to be able to associate or collaborate directly to indirectly with other artifacts.

How

The key to coupling is to manage it appropriately. The strategy is to exercise discretion where the consequence of fixed coupling, which is tight coupling, is problematic. For example, when an employee object is tightly coupled to tblEmployee, then if there is change in the schema of tblEmployee, the use of the object is impacted and it will need to be reengineered. However, if the interface of the object is loosely coupled to the tblEmployee through middleware, then change may have no effect on the object, because the change may be accommodated within the middleware, leaving the interface between the employee object and the middleware unchanged. In this case, the coupling is loosened by exercising discretion and designing an association with an interposed party (e.g., middleware). The rationale for using an interposed party is that it is preferable to form a direct association or coupling with a party that is less demanding when circumstances change. The point is illustrated when comparing a three-tier and a five-tier application design (refer to the section "Application Design Architectures" later in this chapter). The five-tier design differs from the three-tier design, because the business layer is interposed by UI and data integration layers, which directly manage the relationship between the presentation and data source tiers, respectively. The loose coupling shelters the business layer from those underlying layers. The interposed integration layers may fully or substantially accommodate a change in circumstances (e.g., supplementing a Web interface with a Windows interface or changing a data schema). The consequences may be absorbed in the interposed layers, leaving the business layer unaffected or having to accommodate minimal change. The endpoint of decoupling is that the cost associated with change can be more efficiently managed, thereby lowering cost of ownership and safeguarding longevity of an application.

The Standard: Coupling

The standard acknowledges the appropriate management of coupling and the value of decoupling where the exercise of discretion effects a net positive return on investment.

Layers

Layers are tiers, which are a convenient way to encapsulate, decompose complexity, and marshal specialty while recognizing the value of a sphere of responsibility.

What

A layer is an abstract or concrete composition of modularity, for example, a business object layer or a network services layer.

Where

Throughout an enterprise architecture, there are layers of functionality. Layering may be used to structure functionality within an application framework (e.g., UI, BO, and DB layers) or to represent architectures within an enterprise framework.

Why

An efficient and effective way to design, develop, maintain, and manage complex and large structures is to decompose them into smaller units that exhibit a defining characteristic (e.g., integration or security layer). Layers encourage the development of specialized skills, which in turn encourages the development of expertise.

How

Defining a layer is situation dependent: a large site has more options than a small site, or what works in theory may not work in practice in a given situation. Unfortunately, layering is not easily reversed, and to do so may require expensive reengineering or replacement. However, as organizations are dynamic, a key to defining layers is to design them cohesively and flexibly, and do it early. Layering is a two-edged sword: on one hand, it is extremely useful in decomposing and managing complexity; yet on the other hand, each layer is an overhead that the network and the budget have to support. The art is in striking the right balance for the situation: in other words, how layers are implemented, in a given situation, is a matter of considered judgment. Often, the structure of layers tends to follow industry lines, where common business objectives are deterministic.

The Standard: Layers

The standard acknowledges the use of layers as an efficient and effective way to design, develop, maintain, and manage complex and large structures.

Design Context

The role of the design context is to give the design policy a context in which it is applied.

What

The design context defines the workspace or domain in which the design policy is to be implemented. For example, certain enterprise functionality may be excluded from an enterprise design context because it is legacy and flagged for depreciation, or domain functionality may be excluded because it is managed by a functional department (e.g., Microsoft Access applications and spreadsheets in the marketing department).

Where

A design context is used, for example, by an enterprise architecture framework as the conceptual foundation (or land) on which the framework is to be built. A design context may be limited to a given layer or architecture, however.

Why

The workspace has to be identified so that appropriate resources may be organized. In practice, not all of the functionality of an enterprise may be included within an enterprise context, for example. Commonly, organizations are iterating architecture towards a target architecture and may include or exclude functionality flagged for redundancy from the context of a structural design.

How

The design context is defined as the workspace to be structured. In Figure 6-1, the design context is defined as the enterprise architecture workspace, as identified within the design policy.

Figure 6-1: Design context

The Standard: Design Context

The standard acknowledges that the design workspace has to be identified, so that appropriate resources may be organized. In practice, not all of the functionality of an enterprise may be included within an enterprise context.

Enterprise Design Framework

While the design context defines the workspace, it is the framework that transposes the concept of architecture into concrete layers (e.g., application or enterprise services layer) in which to design a composition of interrelated modules of functionality.

Note

The tiers or layers of the enterprise framework may follow industry best practices, which, for example, are articulated in the Open Groups' Architecture Framework (TOGAF 8.1 Enterprise Edition). TOGAF derives from TAFIM, an architecture framework developed by the U.S. Department of Defense. You can review TOGAF at www.opengroup.org/architecture.

What

An enterprise design framework is a blueprint that defines the structures or layers of an enterprise. The structures or layers map conceptually, although not always physically, to a given architecture.

Where

The enterprise design framework is used where there are many structures that need to be blended or unified into a systematic whole.

Why

Enterprise design embodies purpose and discipline, so it requires a framework on which to guide it to that end.

Note

The design framework is itself a design that evolves from a synthesis of community ideas and practices. Once an idea or practice becomes accepted, then it is inevitable that it will find favor in a design policy.

How

The framework is mapped to layers or tiers of functionality. For practical purposes, the deployment architecture is shown conceptually, although it is a concrete layer on which all other concrete layers are deployed. The enterprise architecture remains a concept that acts as the outer boundary of the framework. Figure 6-2 illustrates an enterprise design framework. Note that it shows the mapping of respective architectures to layers (except for the deployment). The framework is implemented in various summarized forms, where typically reference is limited to layers or tiers of "architecture" that exclude reference to the surrounding architectures (e.g., deployment and enterprise); the framework is commonly summarized as an "n-tier" architecture.

Figure 6-2: Enterprise design framework

The Standard: Enterprise Design Framework

The standard acknowledges the use of an enterprise design framework where there are many structures that need to be managed as a cohesive composite.

Application Layer

An application layer represents the software functionality of an enterprise. It may comprise in-house and outsourced functionality that is seamlessly presented to a user.

What

The application layer is a conceptual repository of applications that may be deployed across many networks and accessible locally, regionally, or globally. For example, a Web application would reside in the application layer, and it may through an application services layer consume security, transaction, and data services from the enterprise services layer.

Where

The application layer resides in an enterprise framework and leverages an integration layer to access enterprises services (or platform services).

Why

The design, development, and maintenance of software is a specialized skill with its own set of dynamics. Encapsulating software into a layer is an efficient and convenient way to manage the special needs of application development.

How

An application layer is built up as a composite of domain applications. Application integration and common functionality are abstracted into application integration and enterprise services layers, respectively. That has several benefits: it maximizes decoupling, minimizes the effect of change, and minimizes development in a domain application.

The Standard: Application Layer

The standard acknowledges that the design, development, and maintenance of software is a specialized skill with its own set of dynamics. Encapsulating domain software into a layer is an efficient and convenient way to manage the special needs of application development.

Application Design Architectures

In this section, we discuss application design architecture and examine the following: two-tier, three-tier, five-tier, and enterprise architectures. Is one design architecture better than the other? While there is much debate, the more relevant issue is when is one design architecture more appropriate than another. The essence of good design is to match the most appropriate solution to the requirements. Thus, on a site, much can be gained by using a range of design architectures, rather than shoe-horning all applications into one architecture type. For example, in a given situation, it may be inappropriate to be conservative and use a three-tier architecture when a more expensive five-tier architecture has a lower total cost of ownership. On the other hand, unnecessary cost and overhead may result from developing functionality as a three-tier application when a two-tier application would have been equally technically appropriate.

Two-Tier Design

We commence our reexamination of application design architectures by examining the two-tier architecture, which is a simple C# application.

Note

The simplest application design is the one-tier application (e.g., many Windows and Console applications)—that design has not been illustrated in this chapter. Its distinguishing characteristic is that all functionality resides in one layer or tier.

What

A two-tier design is an application architecture that compacts all of the functionality or application logic into a single tier that resides on one server, while data resides on a second tier (e.g., a database server). The two-tier design is suitable for Web and Windows applications.

Where

Where there is a requirement for an application that features low overhead and high performance, then the two-tier application is a common solution. It may, however, present integration inefficiencies, scalability issues, and maintenance overhead.

Why

The two-tier design can be built rapidly, offers high performance, and may be a cost-effective solution.

How

All of the functionality is encapsulated in one layer, which resides on one server (see Figure 6-3), and the data on a second server. Commonly, websites or Windows applications have used this design to rapidly develop functionality and to minimize performance overhead. However, the tight coupling between the UI, business, and data classes, which is implicit in the design, may be problematic if there is a change to data schema, for example. In this case, a solution may be to use an Adapter design pattern (refer to Chapter 11) as a short-term solution.

Figure 6-3: Two-tier design structure

The Standard: Two-Tier Design

The standard acknowledges the use of a two-tier design where there is a need for rapid development and high performance. It does caution, however, that over the medium to long term the design may encounter integration inefficiencies, and scalability, coupling, and maintenance issues.

Three-Tier Design

The three-tier design is generally considered to be the most popular design architecture in use today.

What

A three-tier design is an application architecture that separates functionality into two tiers (UI and business) that reside on separate servers, while access to data is via a third server. The three-tier design is suitable for Web and Windows applications.

Where

Where there is a requirement for an application that features high performance with a medium-to-long life expectancy, then the three-tier application is a popular solution. It supports integration efficiencies, scalability, and stability, and carries a relatively low maintenance overhead, while mildly reducing coupling concerns.

Why

The three-tier design is an alternative to a two-tier or five-tier design: it has a good mix of the advantages of the two- and five-tier architectures, but with relatively inferior de-coupling design features compared with a five-tier solution. While in theory, the user interface may be swapped between presentation types (Web or Windows), in practice, however, that is easier said than done. Commonly, problems arise because the user interface is coupled to the business layer, and the business layer is coupled to the data layer.

How

The functionality is divided over three layers (see Figure 6-4) with each layer residing on a separate server. Each layer is readily accessible, extensible, and maintainable.

Figure 6-4: Three-tier design structure

The Standard: Three-Tier Design

The standard acknowledges the use of a three-tier design where there is a requirement for an application that features high performance with a medium-to-long life expectancy. It cautions, however, that the business and data classes may be tightly coupled implementations to the user interface and datastore, which may cause future concern.

Five-Tier Design

The five-tier design is the elegant solution that overcomes the disadvantages of the three-tier model.

What

A five-tier design is an application architecture that separates functionality over four tiers that reside on two servers: a presentation tier resides on one server, while the UI, business, and data classes reside on a second server, and the fifth tier—the data source—is accessed via a third server. The cost of extra layers may be offset by the gain from encapsulating the UI, business, and data classes on the one server (which compares with the two-tier design and contrasts with the three-tier design). The five-tier design is suitable for Web and Windows applications.

Where

Where there is a requirement for an application that features high performance with a long life expectancy, then the five-tier application is a solution. It supports integration efficiencies, scalability, stability, and loose coupling, and carries a relatively low maintenance overhead.

Why

The five-tier design has all of the advantages of the three-tier design, but with a solution to the problem of coupling the business and data classes to the implementation of the user interface and data source. These benefits are supported by the merging of the logic functionality on to one server. However, developing a five-tier application may be more expensive than a three-tier application.

How

The functionality is divided over five layers (see Figure 6-5) with a presentation layer on its own server and the UI, business, and data classes residing on the same server, a feature that not only assists in decoupling, but also aids performance, as most of the grunt work is done on the same server. The data source is accessible via a third server. With this design, the functionality classes are decoupled from the presentation and data source. The UI classes are able to cater to the special needs of Web or Windows representation, and the data classes shelter the business functionality from changes to the underlying data source.

Figure 6-5: Five-tier design structure

The Standard: Five-Tier Design

The standard acknowledges the use of a five-tier design where there is a requirement for an application that requires high performance, presentation, and data source flexibility with a long life expectancy.

Application Integration Layer

A further safeguard of using an enterprise framework to manage design is that it mandates that integration be a design consideration implicit not only in application design, but also in the design of services and communication layers.

What

An application integration layer is a common layer through which applications are integrated. Commonly, applications are members of a system in which they must integrate and cooperate. Application integration design recognizes that integration is a systematic design consideration and is better managed through a common layer than discretely at application level.

Where

Application integration design resides within an enterprise design framework to encapsulate the task of managing connectivity between applications and services.

Why

It is more efficient, economic, and flexible to delegate the management of the integration of applications to a specialist layer, rather than require an application to self-manage integration. A major risk posed by self-management of integration is that it complicates a system by necessitating point-to-point integration, which exposes the organization to high maintenance, tight coupling, and duplication costs.

How

Within the context of the enterprise architecture framework, application integration is managed as a service to which applications subscribe. There are commonly four application integration designs that leverage an integration layer: XML messaging, dynamic link libraries (DLL), remoting, and XML Web services. The design of an application integration layer is one of the most critical stages in preparing an enterprise framework for longevity and extensibility.

XML Messaging

Messaging relies on a message bus to act as a conduit through which applications integrate to publish and subscribe to functionality, using open-standard XML messages. It offers ubiquity and asynchronous integration (refer to "Service-Oriented Architecture" in Chapter 5).

Dynamic Link Libraries

Application integration may be designed using DLLs (assemblies) that are deployed centrally on servers and referenced by subscribing applications. It is a synchronous binary solution; however, it is generally considered in situations that favor efficiency at the expense of integration ubiquity. DLLs commonly support a hub-and-spoke architecture (refer to "Service-Oriented Architecture" in Chapter 5).

Remoting

Application integration that uses remoting is an extension of the use of DLLs to integrate, with the added feature that integration outside of the immediate domain is managed through the partnership of a remotely deployed DLL acting as a proxy to communicate through a transport protocol to a server DLL, with a little help from .NET CLR at either end (refer to "Remote-Proxy Pattern Code" in Chapter 11).

XML Web Services

Web services is a solution for application integration that leverages Internet distribution functionality to offer synchronous and ubiquitous integration (refer to "Service-Oriented Architecture" in Chapter 5).

The Standard: Application Integration Layer

The standard acknowledges the use of an application integration layer to avoid the cost of high maintenance, duplication, and tight coupling.

Enterprise Services Layer

An enterprise services layer exposes or publishes common functionality that is accessible across the enterprise.

What

The enterprise services layer is a common layer through which enterprise functionality is published. It refers to a portfolio of services that act as an application platform from which applications are serviced, through an interposed integration layer, with common functionality.

Where

The enterprise services layer is located between the application integration layer and network services layer within an enterprise framework.

Why

Enterprise services enable an organization to manage application resources that are common. The objective is to standardize resource availability, usability, adaptability, and stability, while preventing or removing duplication and redundancy of functionality.

How

The enterprise services layer (see Figure 6-6) is the engine room of an enterprise framework; how it is designed is influenced by a range of factors, including implied requirements of the design policy, decisions made in terms of the enterprise-domain dichotomy (refer to the section "The Standard: Design Dichotomy" earlier in this chapter), the size of the organization, the nature of the industry, and the requirements of stakeholders. The choice of design centers around what services are defined as enterprise and what services are native to a domain. Generally, enterprise services include services that are more efficiently or effectively utilized, from an organizational perspective, outside of a domain, for example, security services, application services, data management and warehouse services, transaction management services, operating system services, and network management services.

Figure 6-6: Enterprise services

The Standard: Enterprise Services Design

The standard acknowledges the use of enterprise services that seek to standardize resource availability, usability, adaptability, and stability while preventing or removing duplication and redundancy.

Communications Integration Layer

The previously discussed standards relate very much to software services; however, software needs to run on fixed hardware and the ever-increasing array of mobile communication devices.

What

A communication integration layer encapsulates or abstracts to an interface layer the responsibility to integrate the enterprise services layer (the application platform) with the hardware and communication functionality.

Where

The communications integration layer lies in between the enterprise services layer and the communication layer in an enterprise framework.

Why

The wisdom of a communication integration layer mirrors that of an application integration layer by centralizing and coordinating the integration of multiple artifacts that may enable a more efficient, maintainable, and loosely coupled solution.

How

The integration focuses on the development of core functionality that commonly wrap IP-based networks, which enables connectivity between the enterprise services layer and Internet and other communication channels.

The Standard: Communications Integration Layer

The standard acknowledges the use of a communication's integration layer to centralize and coordinate the integration of multiple artifacts that may enable a more efficient, maintainable, and loosely coupled solution.

Communications Infrastructure Layer

The portfolio of services that enable the interconnection or communication between systems is referred to as a communications infrastructure.

What

The communications infrastructure represents the local and extended software and hardware transport components, which enable data exchange and network switching. The design of the infrastructure will be driven by the requirements of the application, integration, and enterprise services layers and the deployment architecture.

Where

The communications infrastructure is accessed through the communications integration layer that houses in the enterprise framework.

Why

To participate in the benefits of network computing, be it a Local Area Network (LAN), Wide Area Network (WAN), Virtual Private Network (VPN), or Internet network, an enterprise requires a hardware layer to manage and encapsulate communication functionality within an enterprise framework.

How

A portfolio of hardware artifacts is assembled as a network of communication devices that plug in to other communication systems to access and expose functionality.

The Standard: Communication Infrastructure Layer

The standard acknowledges the use of a communication infrastructure layer to manage and encapsulate communication functionality within an enterprise framework.

#EnterpriseArchitecture #Standards #TheOpenGroup