Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Enterprise Edition >

From stove-piped projects to unified enterprise architecture

Strategic considerations for e-authentication service development

By Jian Zhong, JavaWorld.com, 03/21/03

In the last decade, many large organizations have developed numerous information systems but often times with very little coordination. As a result, information systems can be redundant and cannot interoperate, and data is repetitive and inconsistent (stove-piped information systems). In fact, one of the greatest challenges facing large organizations, such as the US federal government, is the failure of information systems to interoperate and effectively share business-critical data. Although it isn't easy, you can establish a unified enterprise architecture (EA), align projects with that enterprise architecture, and carefully plan and control your investments. I first discuss the enterprise architecture approach to an e-authentication project and then concentrate on some technical considerations.

Align the authentication service project to the enterprise architecture

First, consider how to align the e-authentication project to business objectives within an enterprise architecture. As enterprise architecture is a relatively new topic, let's discuss what an enterprise is and what it involves. According to the US Department of the Treasury's Treasury Enterprise Architecture Framework (TEAF) definition, an enterprise is an organization supporting a defined business scope and mission (see Resources). An enterprise comprises interdependent resources that should coordinate their functions and share information in support of a common mission. Enterprise architecture includes a strategic information asset base, which defines the business, information necessary to operate the business, technologies necessary to support the information systems, and the transitional processes necessary for implementing new technologies in response to changing business needs.

Enterprise architecture involves a top-down, business strategic-driven process that coordinates the development of a business architecture, an information architecture, and a technology architecture that support individual applications as well as the entire enterprise application portfolio. It represents the holistic view of the enterprise's key business, information, application, and technology strategies and their impact on business functions and processes. Since enterprise architecture development itself can be a very lengthy process, I select a small piece of an enterprise architecture closely related to application authentication for further discussion. The table below represents an enterprise architecture from 10,000-foot level. Let's use this as the starting point to talk about unification strategies.

The slice of enterprise architecture for e-authentication

  Business architecture Application architecture Technology architecture
As is (baseline) List of business processes; each has its own authentication. List of information systems that support those business processes; different application architectures for authentication. Applications are hosted on different locations, different hardware, different operating systems, and different Web and application servers.
To be (target) List of business processes; all share a common authentication process. All information systems will use the authentication service. Relatively centralized date centers with high capacity of hardware, software, and network systems.


Migration from "as is" to "to be" via service-oriented architecture and model-driven architecture

An enterprise architecture needs a detailed sequencing plan to evolve the baseline architecture to the target architecture. The plan's major elements include program/business improvement IT projects and major infrastructure and technology upgrades. The IT projects include the e-authentication project and all other projects that use the e-authentication service. The best strategy for migration involves service-oriented architecture (SOA): e-authentication will provide authentication service to all other applications that require authentication. The goal is to build a service that offers value and creates standard profiles in the enterprise architecture repository to avoid redundant development efforts.

What is SOA? It is a way of designing a software system to provide services to either end-user applications or other services through published and discoverable interfaces. In many cases, services offer a better way to expose discrete business functions, and therefore, an excellent way to develop applications that support business processes. In my opinion, SOA differs from component-based architecture (CBA). SOA is CBA, but the reverse is not necessarily true. Let's use Web services and Enterprise JavaBeans (EJB) as an example. Web services is obviously an SOA. The EJB model is a CBA, but it may or may not be an SOA depending on how the EJB components are deployed. For example, if one vendor develops and sells the user management components to many customers, this model could be considered a CBA. In that case, all the customers should consider application architecture issues such as how the EJB components will be deployed and technology architecture issues like the necessary hardware and software to support EJB deployment. If a company uses SOA, the user management EJB components and related databases will be centrally hosted and made accessible enterprisewide. Only EJB clients—the calling stubs—will be distributed to projects that need to access user management functionality.

SOA requires well-defined interfaces. And this in turn requires a model-driven architecture (MDA). The most important ideas behind the Object Management Group (OMG)'s MDA are the concepts of the platform-independent model (PIM) and the platform-specific model (PSM). PIM is independent of any actual implementation details, while PSM can be converted into language code designed for a specific platform. If you read my article "Step Into the J2EE Architecture and Process," you perhaps will notice that PIM and PSM resemble the object-oriented analysis and design concepts I proposed about two years ago. MDA raises the level of abstraction and helps to unify the enterprise by maximizing reuse and promoting information sharing across different technology stacks like Java 2 Platform, Enterprise Edition (J2EE) and .Net. Figure 1 shows the MDA development process.

Resources