Making app dev and infrastructure platforms get along

In my column last month, I described one scenario of operating system chaos where a company had one platform for application development and another for infrastructure operations (e-mail, file and print, and the like) (see column).

With the impending launch of Windows Server 2003, it seems appropriate to expand on that scenario, given that a company with a commitment to the Java platform might find compelling reasons to introduce Windows Server 2003 or vice versa.

It's easy to imagine how different operating systems for two major enterprise functions might give rise to data and functional isolation, not to mention administrative problems. Like the architecture of a building, the blueprint for each system, from plumbing to electricity, must be integrated so that the completed house is safe, functional and comfortable.

Nevertheless, I find that it's common for customers to introduce a new application development environment without much thought for the supporting infrastructure. Many companies even have implemented separate infrastructure and application directories built on incompatible technologies. This creates redundancy and can require significant integration work.

That's not to say that companies must standardize on one operating system. In application integration projects, for example, programmers can make the disparate environments connect at the application layer. Yet programmers must also support infrastructure functions such as accounts, security and management. Many applications end up defining their own infrastructure even when a shared service infrastructure is available. A project team may duplicate systems that already exist. This approach reduces staff availability, extends implementation time and may result in rigid architecture that constrains flexibility and undermines business value down the road.

Fortunately, there is an alternative that bears out two important principles:

  1. Streamlining, consolidating and sharing IT services is a good idea, even when two different operating systems are involved.

  2. Achieving benefits requires architecture, communication and coordination of shared functions.

1pixclear.gif
Christopher Burry is technology infrastructure practice director and a fellow at Avanade
1pixclear.gif
Christopher Burry is technology infrastructure practice director and a fellow at Avanade, an integrator for Microsoft technology that's a joint venture between Accenture and Microsoft. Ace Swerling is an MCSE within the Technology Infrastructure Practice. Readers are invited to send comments or questions to Burry at Christopher.Burry@avanade.com.
Application development and infrastructure platforms share the need for technology to enable communication; namely, security, identity and directories. Directory technology represents the user, the systems and the data to be accessed; verifies that the user is valid; and authorizes access. So it makes sense to integrate application development and infrastructure platforms at the directory level: Then it's possible to take advantage of infrastructure functions from the application environment, reduce application development costs and create a simpler and more powerful operating platform.

Though this approach seems sensible, be aware that not every directory supports it. For example, many directory services don't perform the authorization or binding itself. Traditional metadirectories enable authentication against a Lightweight Directory Access Protocol (LDAP) directory, but they don't typically represent resources. This makes the crucial step of authorization more difficult.

Also, directory infrastructure and security are inextricably linked. Consequently, I often provide the following guidance to customers embarking on directory-level integration.

  1. Look for directory technology with security built in, to minimize the customization and coding required.

  2. If possible, store identity information in a single directory that is authoritative for your enterprise. It should include a flexible security mechanism that natively supports security protocols of disparate platforms, i.e., Unix, RACF, Windows, LDAP, etc. Linking simple LDAP directories with directory synchronization is the traditional approach. But it is more complex and typically complicates security integration.

  3. Directly link application account information with the common directory. This defines a more robust and less complex security infrastructure, which reduces cost while facilitating application integration.

  4. Define and publish guidance for application integration architecture. New applications should be implemented to support the highest practical level of integration.

  5. Make sure externally published applications support an integrated identity and security system just like internal applications. Internal and external information should reside in different directories that are linked to preserve security.

  6. Proceed, while recognizing that this level of integration is not always possible. This is particularly true for existing applications. Do your best to create a high level of integration between application environments and the infrastructure. If that isn't possible, don't arbitrarily introduce complexity by pursuing an exclusively nonintegrated approach. Try to get the tightest identity, security and manageability integration that you can.

Deploying and managing a new application development platform requires oversight and vision. Infrastructure teams may not be thinking about the security and operations functions that could benefit application development environments as well. Similarly, the application development staff may not think about how their charge fits into the existing environment or how it can take advantage of systems and technology already in place.

IT departments, like architecture firms, need a master planner. This master planner should have a view to business needs and deep technical skills to ensure the highest impact and most efficient environment. The CTO can coordinate new and existing technology to extract the most value and use from both, as well as ensure the best use of staff time.

Special Report

Users in the OS Slow Lane

Stories in this report:

Copyright © 2003 IDG Communications, Inc.

Bing’s AI chatbot came to work for me. I had to fire it.
Shop Tech Products at Amazon