From stove-piped projects to unified enterprise architecture

Strategic considerations for e-authentication service development

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 architectureApplication architectureTechnology 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.

Figure 1. An MDA development process (Source: Meta Group and the OMG, 2002)

Value propositions beyond an enterprise

A well-designed e-authentication service can service applications beyond those you list in your enterprise architecture. If your project is successful, other interested organizations can reuse your service. You might even become an authentication service provider. On the other hand, if you cannot make it work, somebody else will. In that case, you might become the customer of someone else's authentication service.

Fund and manage interdependent projects

Even if you have the world's greatest idea, you will not achieve much success without an IT project that is properly funded, managed, and delivered. Well-coordinated IT projects drive the move from "as is" to "to be" architectures. Depending on your ambitions, an e-authentication project could cost from thousands to millions of dollars. Most complex organizations conduct some form of business strategic planning, often coordinated through a strategy committee or planning organization that identifies threats and opportunities and recommends appropriate organization responses and investments. For the federal government sector, this process is called capital planning and investment control (CPIC). These recommendations become part of the company's plans and budgets. Figure 2 shows how projects are established in an enterprise.

Figure 2. Interactions between enterprise architecture, CPIC, and project management (Source: Department of Veterans Affairs, 2001)

Someone must convince decision makers that your e-authentication project aligns well with the enterprise architecture and its value proposition is well worth the capital investment. It's equally important that all other projects that require authentication be carefully evaluated to avoid the development of their own stove-piped authentication modules. As we move from stove-piped projects to a unified enterprise architecture, complex dependencies among projects will arise. Depending on the SSO project's scope, it might take a few months or several years to develop in parallel all projects dependent on the SSO project for authentication and/or authorization. Clear interfaces must be well defined so that each project can efficiently proceed.

Complications can of course creep in. Your authentication project might not have enough financial and management support. Or you might decide to branch off your project to develop a generic SSO solution. For the Department of Energy, I was the technical lead and architect for multiple projects, and they all required authentication and some common functionality. Our team developed the SSO solution as well as many other projects that also required authentication service.

The E-Grants project, one of 24 e-government initiatives, provides a good example for interproject dependency analysis. The US federal government awards more than 00 billion in grants each year to state, local, and tribal governments, universities, and nonprofit organizations. These grants are managed and awarded through 26 major "grant-making" agencies in more than 500 programs. The E-Grants initiative allows potential grantees to apply for all types of grants online through a unified Website, which obviously requires user authentication and authorization. Figure 3 shows a high-level diagram for user authentication.

Figure 3. The E-Grants project user authentication diagram (Source: E-Grants, 2002)

The e-Authentication project is another e-government initiative intended to provide authentication service to the 24 e-government initiatives and eliminate the need for each initiative to develop a redundant solution. The e-Authentication project is scheduled to go into full production in October 2003; whether it will go live on time and actually provide satifactory service to the E-Grants project is still up in the air. To mitigate this risk, the E-Grants project plans to initially use its own username/password-based authentication but will be prepared to use e-Authentication when it's ready.

Type of applications to support

Another important factor to consider in your e-authentication project is what type of applications you expect to support. Typical applications include HTML-based Web applications (JavaServer Pages (JSP), Active Server Pages (ASP)), applet-based applications, Web services, and wireless applications. The applications we discussed in my last article are mostly J2EE or ASP HTML-based applications. But your customers might demand that you also support applet-based or even client/server-based applications. Should you just ignore this business opportunity? Or should you adapt your solution to win new customers? Or even better, should you have a well-constructed solution that expects this kind of situation?

Oracle's e-business applications offer a good example. Oracle's E-Business Suite consists of dozens of applications. An applet is used at the infrastructure level so that legacy Oracle forms applications can deploy as Web-based instead of client/server-based applications. What a sleek idea! Oracle developed an applet and a huge number of Oracle forms applications that can now be upgraded to Web-based applications without a major rewrite. Given that you have no source code or even documentation about how this Oracle applet works, don't you think it's quite a challenge for your SSO service to support this scenario? Plus, you would need serious financial backing. A few weeks ago, I learned that one government agency has committed to migrate its stove-piped projects to Oracle Financials, and it is a 00 million, six-year project.

If things seem difficult already, think about supporting Web services, wireless devices, and other types of clients. As most enterprise information portals support some sort of SSO, you need to decide whether you should expand your e-authentication to cover portals or just use the commercial off-the-shelf (COTS) SSO provided as the baseline and then expand.

Levels of authentication

One of e-authentication's key objectives is to establish trust, and trust exists at different levels. The ability to provide a range of authentication services is valuable. Password authentication might be sufficient for many business scenarios such as online shopping, but additional security may be required for other scenarios. A public key infrastructure (PKI)-based solution can offer many different levels of identity assurance. At the first level, the user presents some unique personal information such as address and social security number to verify his identity on the Internet to get an instant certificate. At the next level, a user may be required to show up in person with identification like a driver license. A minimum background check or even a security clearance may be required to issue a certificate with very high-level security. Smart cards combined with PKI are quite promising. Biometrics authentication (face recognition, finger printing, or iris scanning) can also come into play. An authentication service with potential to become the de facto standard will need comprehensive coverage of multilevel authentication.

1 2 3 Page
Join the discussion
Be the first to comment on this article. Our Commenting Policies
See more