Print

Domain Neutral Enterprise Architecture Framework (DNEAF)

The DNEAF provides a Platform Independent Model (PIM) based on the Object Management Group's (OMG's) Model Driven Architecture (MDA) standard consisting of model components that represent core functionality to carry out fundamental processes in the business from the Information Technology (IT) perspective. These functional components can vary from domain to domain but there is a constant set of components which must exist in a true Enterprise Platform. The problem with assessing enterprise platform components is compounded by the practice of product vendors that describe their architectures from the perspective of their product stack and not from the perspective of functionality. In order to effectively compare different products and solution approaches, a baseline of functionality must first be established. The DNEAF presents an architectural model that is neutral with regard to both the business and technology domains in order to identify the core components that exist within an enterprise platform. It is these components, which we call Proxy Components, whose functionality in the PIM is “marked up” to reflect specific technology and component implementation mappings or specific organizational processes and workflows.

Before introducing the core components, it helps to first define the categories of functionality, described as services, that the platform must provide. Any application, independent of its environment, is dependent on a set of what can be characterized as essential services. The OMG has defined five essential services as pervasive services. Pervasive services specify services that an infrastructure component offers to other assembled components. [1] [OMG; Model Driven Architecture, page 21; 2001, doc. No. ormsc/2001-07-01]. The pervasive services identified by the OMG include:
  • Directory Services
  • Event Handling
  • Persistence
  • Transactions
  • Security
An Enterprise Application Integration (EAI) platform must also provide the following six categories of functional enterprise services to all applications and in all environments; these services provide support for:
  • Messaging
  • Format transformation
  • Rules processing and contents-based routing
  • Security/authentication support (via Single Sign-On)
  • Workflow Execution
  • Interfaces to applications via access points
The various components that comprise an enterprise platform provide services to each other and to the applications that utilize the platform. When describing the platform components, it is common to refer to them in terms of services. For instance, the Content Management component would typically be referred to as Content Management Services (or by its shortened form, Content Services) since it is responsible for providing Content Management Services to the enterprise via the platform. Applications can also provide services to other applications and platform components when they have been integrated into the platform framework. In the component descriptions that follow, many of the components will be referred to as services. This indicates which components provide core functionality to the enterprise. Some components will be described as sub-components to indicate a special technical approach that needs to be explained. Other components will be referred to as mechanisms to indicate a technical approach for providing specified component functionality.

Each service within the enterprise platform will typically be assigned to a specific network security zone. From the enterprise perspective, there are five network security zone classifications (each zone can be further divided into “compartmentalized” zones):
  • Intranet – This is the most secure zone in a network. The Intranet is where the enterprise maintains its most sensitive applications and data. This is also the zone where application and data development takes place.
  • Extranet – This is the second most secure zone in a network. The Extranet is where the enterprise maintains applications and data that are accessible by employees that are located outside the company network and by partners. Some application and data development may take place in this zone depending on the requirement to have external partner participation in the development from outside the enterprise.
  • Demilitarized Zone (DMZ) – This is the least secure zone in a network. The DMZ is where web servers, applications, and data for external customers, partners, and the public are maintained. Development should never take place in this zone –artifacts built in more secure zones are deployed to the DMZ.
  • Partner Net – This is a network zone that is under the control of a partner organization. This zone is considered less secure than the DMZ because the enterprise typically lacks operational and audit control in a partner’s network – even when connecting to an Extranet or Intranet. Security is a critical issue since it is possible that a chain of trust can exist whereby access to and through a Partner Net zone can be indirect (for instance Organization A connects to Organization B and Organization B connects to Organization C – if the trust relationships and security configurations are not set up properly, it may be possible for A to connect to C indirectly through B or even for C to connect indirectly to A through B).
  • Internet – This is the least secure zone in a network. Any communications sent through the Internet should be considered unsecured. Even with encryption, any information could still be compromised by a third party willing to pay the costs. Information in this zone should be assessed for its value and timeliness. Information of high value but whose value is very short-lived is safer to transmit over the Internet compared with information that is of high value but whose value is long-lived.
In addition to the impact of security on the enterprise architecture, there is also a significant impact on scalability. In small to medium transaction volume platforms, the correlation between the number of transactions and the decrease in performance is geometric. In large-scale enterprise platforms, the correlation will reach a point where it becomes exponential. This exponential decrease in performance on large-scale enterprise platforms is one of the most serious architectural problems that an organization will face. There are several significant contributing factors to this problem, the three most common being:
  • Application Servers – Application Servers are used to manage transactions, sessions, and persistence through a “container.” Both IBM and Oracle rely on Java Application Servers based on the J2EE standard that manage the Enterprise Java Beans (EJB’s). The Open Source community has also adopted a similar approach (for instance, Red Hat Linux Enterprise running the JBoss Application Server); however, there are also alternative Open Source solutions such as Erlang, which is based on the Open Telephony Standard. Microsoft has not adopted an application server for .Net (the closest thing Microsoft has is BizTalk – but it is not an Application Server in the sense that a J2EE Application Server is). The new EJB3 standard will have a major impact on Java Application Servers when it is finalized and new products are released that take advantage of its benefits. IBM for instance, is already bringing their Application Server architecture in-line with the emerging EJB3 standard.
  • Clustering – Clustering functionally related servers together is a common way to share processing loads; however, it is also difficult to develop this technology. Many organizations do not have an adequate budget to invest in development, test, and production infrastructure environments. Instead, development is often done on a smaller scale using lower cost and performance infrastructure. An additional problem is maintaining synchronization between different persistence objects that reside on different servers within a cluster without creating a huge process overhead. Running Application Servers on a Cluster of servers can create numerous problems that are not often identified during development – especially if the development infrastructure is based on a single-server solution or on operating system and development environments not specifically designed for clustered deployment. Microsoft Clusters also require a high-level of management and operational synchronization that creates a performance bottleneck as the solution scales up.
  • Caching – Caching can be done at many locations and levels within an enterprise architecture; for instance, there is persistence layer caching, web or HTTP session layer caching, and business layer caching. Alternatives to these solutions for caching can include the use of stored procedures or the use of a dedicated caching solution. In a clustered environment, there is the added challenge of making sure that every instance of the same information has the same value. Caching can create a performance bottleneck during synchronization and garbage collection.
 
The diagram below provides a high-level overview of the Enterprise Portal Platform in the form of a Model Driven Architecture Platform Independent Model. This model view is based on a real-world solution developed by the Enterprise Systems Architecture Laboratory that has been successfully deployed in a number of domains including financial services and banking platforms; business-to-business platforms; telecom service provisioning portal platforms; air traffic management platforms; e-business portal platforms; and e-government portal platforms.
 
dneafbg01_thm.jpg
 
The model illustrated above has also been successfully deployed using IBM WebSphere, Oracle, Microsoft, and Open Source components including the Open Telephony Platform (OTP) with Erlang by the Enterprise Systems Architecture Laboratory in the domains listed above.

The DNEAF product line consists of white papers, analytic comparative worksheets, UML 1.x and 2.x models, and MS Word templates. The DNEAF was developed by the Enterprise Systems Architecture Laboratory (ESAL) as part of its applied research program Model Driven Architecture as a tool for evaluating Enterprise Systems Platform Technologies. The premise for this research is based upon work conducted from 2000 to 2003 in Stockholm, Sweden at the ESAL laboratory, which was initially presented at the Object Management Group (OMG) Technical Meeting in September 2001 (Toronto, Canada) and refined through 2003. This presentation builds upon a Model Driven Architecture (MDA) Platform Independent Model (PIM) developed by Chris de Vaney, Chief Architect at ESAL during 2000 to 2001, and extended into the current framework by Donald Baldwin, Core Enterprise IT Architect at ESAL during 2001 to 2003. The resulting framework was presented as a conceptual overview by Donald Baldwin at the OMG Technical Meeting in November 2001 ( Dublin, Ireland) as a two-dimensional gap analysis (transitional and comparative) framework for comparing different Platform Specific Models (PSM’s) based on a common PIM. Within this framework, Transitional Gap (TG) Analysis is the “traditional definition of Gap Analysis” where a starting benchmark is defined and a target, or ending state, is also defined in order to develop a PIM based on the resulting differences between the benchmark and the target. Comparative Gap (CG) Analysis adds a new dimension by comparing different potential PSM solutions where each candidate (or potential) PSM can be mapped to meet the PIM requirements. A core concept in CG Analysis is that each PSM is symmetrically mapped to the PIM (i.e. the transition point from the PIM to the PSM uses an identical model structure for each view – the PSM is “marked up” to reflect specific technology and component implementation mappings). Donald Baldwin refers to this transition mechanism as a Proxy Component PIM (PC-PIM).

Continuing product development is currently managed by Aurenav Research Institute at its Enterprise Systems Architecture Laboratory (ESAL) facilities located in Seattle, Washington, USA and in Stockholm, Sweden.

Aurenav offers productized versions of the DNEAF as described above, training on the DNEAF, mentoring services on the DNEAF, and project management consulting on applying the DNEAF in Transitional and Comparative Gap Analysis.