Analysis of Current Applications

In looking at how you want to implement Active Directory in your organization, one of the greatest impacts is how your applications use Active Directory. In reviewing this, you look at the applications in your organization based on the use of the application. The point of this section is to help devise a reasonable methodology for breaking down the application effort and coming up with not only a scope, but an insight into the reality of what can be done within the time and risk parameters that you have set for your project.

Enterprise-Wide Applications

One of the greatest benefits of Active Directory is the integration with applications that span the organization. A directory service is an enterprise resource; therefore, it comes as no surprise that enterprise applications can make good use of an enterprise source of information. I don't know how many times I have used the phone list for the group I worked in as the starting point for keeping track of everything from who has completed what training, to who is bringing what to the company picnic. Similarly, planning a trip on the open road requires a map, and on that map, one typically chooses from the key points of interest when deciding the path to take. With this Active Directory scoping, look at the horizon with a focus on those objectives (applications) that will have the greatest impact on the desired destination or goal.

The applications that have an immediate use of an Active Directory are those that view the organization as a whole. Human Resource (HR) applications typically have a view of all the users in the organization. One can imagine the need for sending information automatically to a group of users based on their time of service or their time with their current employer. By creating an attribute for all employees that has start date, a simple query would return all those employees that started before July 1, 1982, for example. Another possible use would be for users to authenticate to Active Directory. Based on who you are, you would be authorized access to personal HR information like benefit spending account information or 401K asset accruals. The result is better service and reduced impact to the HR organization.

These examples represent benefits and possible scenarios, but in moving forward with defining a scope for the project, a planner for Active Directory needs to identify those applications that will be affected during the "Phase 1" implementation. The Phase 1 implementation is the set of features that have been defined as being supported in the initial implementation. It is rare that a new product is implemented to include all the features of the product. The implementation is divided into phases that gradually increase the production functionality of the product.

The first step is to determine which of your applications are enterprise applications. In a small company this can take a few minutes, and in a large company this can take 12 months. Regardless of the size of the company, a few key applications come to mind. These are the applications that that run the business. They are typically the financial applications or HR applications. In a manufacturing organization, they are the production control system. In a retail environment, it would be the point-of-sale and inventory systems. With this list of applications in hand, do some research on the complexity of the applications. For example, is it a package from another third-party or is it a custom application?

With third-party applications, you can research what the plans are for the integration with and the use of Active Directory. After this is determined, you can evaluate whether the release of the new product, or feature upgrade, fits into the window of your release. As you work through this, you should be getting some feel for the magnitude of the effort. Some questions that help determine the effort include

  • What is the complexity of the application? What is the complexity of the use of Active Directory?

  • Is the application going to use Active Directory to validate whether resources are available, or is it going to modify the directory entries?

A more complex undertaking would be to modify the directory. Modifying the directory means modifying the schema by adding new classes or attributes.

To help organize the findings, a simple table has been created to start scoping the effort involved in implementing Active Directory. Throughout this chapter, additional estimating parameters are added to create a final estimate. Using Wadeware as a test, Table 5.1 is created to develop an initial scope for five applications.

The first application is a custom HR application that keeps track of communications with employees, which is based on region. The employee's regional information was maintained within the application, but with the use of Active Directory, this information can be retrieved and maintained as part of the directory.

The second application is a legacy application that has been through many maintenance and enhancement changes. The result is complex code, which is fragile when changed. There is risk in modifying it, and the effort required to make the changes is undetermined.

The third application is a financial application developed outside the company as a packaged solution. This is a relatively new application in the organization. The application currently has its own directory for all current and past employees to track benefits information. Because of the recent release and installation of the product, integration with Active Directory is not available in time for Phase 1 participation.

The fourth application is a complex financial and operational application that uses project-scheduling information provided by project managers and project members coupled with standardized costs to create project scheduling and Profit/Loss statements. This application requires moderate changes for integration with Active Directory. Timing is critical for participation in Phase 1.

The fifth application is an Excel spreadsheet coupled with a process. This application keeps track of different classes of users and administrators. This information, contained in the spreadsheet, is used to set rights to resources throughout the network. When individuals change roles, the spreadsheet is updated, and then the changes are made to the network resources. This process is error-prone and does not provide any logging capability. Based on the simplicity of the technology component in place, some parts of the application can be put in place using Active Directory.

Table 5.1. Summary of Wadeware Enterprise Applications
Application Complexity of Application Complexity of Using Active Directory Effort Phase 1 Future Features
HR Application 1Simple: VB application with a single interface.Moderate: Email status based on the location in directory.Moderate.Yes. 
HR Application 2Complex: C, Legacy application.Simple: Create. The call to AD is focused in one part of the application, and it only needs to create users in AD.Undetermined.No.Possible.
Financial Application 1Third Party.Update directory with benefits information.Just released. Future integration with AD is considered.No.Possible. Promote with vendor.
Financial Application 2/ OperationsComplex: VB application.Moderate: Use directory information and calendar information to determine project costs.Moderate.Considered. Timing is critical.Potential.
OperationsExcel spreadsheet coupled with undocumented complex processes. Company resource security is managed by a variety of administrators.Moderate: Use of directory supplied roles. Apply to predetermined directory scheme.Undetermined.Partial implementation.Further implementation.

After some analysis of the enterprise applications, Wadeware is prepared to have some participation of enterprise applications in Phase 1 of the Active Directory migration. This provides a solid foundation for additional leverage in the future in two ways: the current applications that migrate are likely candidates to take advantage of additional information in Active Directory; the applications that are migrated also serve as an example for new and existing applications to take advantage of Active Directory.

Workgroup Applications

Workgroup applications are those applications that only affect a specific workgroup, from both a user and span of influence position. This differs from some of the previous applications in that most have only a small user community, but the application has an impact on the entire enterprise's staff.

It is anticipated that Wadeware will have many workgroup level applications. They might be Access databases, Excel spreadsheets, or shrink-wrapped solutions. With the effort of modifying these applications to use Active Directory, you want to identify some groups that have flexibility and provide an enthusiastic interest in making the change. This might be difficult, but finding a group that is interested in a better way of computing goes a long way toward overcoming any challenges that the migration might create. Remember, it is not how bumpy the road but how soft the seat you're sitting on, and a cooperative and enthusiastic team can make the seat softer.

Wadeware has identified two applications for consideration. The first application is used in the marketing department to keep track of resources used for events. The current application is used by a small group of event coordinators to identify resource availability and to match that with a team of event presenters. The objective is to make sure that all the resources are available, and if not, external vendors can be used to lease equipment.

The second application is in the product distribution department. This application keeps track of supplier orders for a specific line of products only manufactured at the Miami location. Two shipping department personnel and three resource planners in the manufacturing department use this application. Currently, they shuffle paper around, which is entered in a simple Microsoft Access database with all the customers' names and addresses in it. This database replicates the information in the billing applications used by the finance department.

Both of these applications are candidates for integration with Active Directory. These applications have a small group using the product, and they affect a small number of contacts internally. Each of the groups using their new application has an interest in simplifying their workflow, and they are enthusiastic about the potential to simplify their already busy schedules with an easier interface and more accurate reporting. By leveraging Active Directory in both of these applications, the maintenance of the directory information is passed on to another organization, rather than being replicated with each user community. In addition, the information becomes more reliable because changes in addresses go directly from Human Resources (HR) to Active Directory. In this example, using Active Directory reduces your total cost of ownership.

A first attempt at the estimates for making some improvements that use Active Directory are that they can be made in time for Phase 1. Wadeware now has four applications: three from the Enterprise pool and one from the workgroup pool, that are part of Phase 1 of the Active Directory implementation. Expecting that at least one, and possibly two, applications will still not make the deadline leaves two applications for a success story. This is important. There is the opportunity for a success even with minor setbacks. A failure to get any applications using Active Directory as part of the implementation plan is not leveraging the full value of Active Directory. Yet, having too many applications involved during the onset is too ambitious.

Stand-Alone Applications

Stand-alone applications are applications that are used by a single user. The output from the application is typically input for another application or for use by a single user. The application developer might even be the user. In the initial phase, it might be best to see if you can find an application that is totally controlled by a single user; both the input and the output are in the total control of the user of the application.

Wadeware has an application that is used as a card catalog for the internal library. The librarian is the only person that uses this application. The librarian uses the application to update which books are checked out to whom. This application currently does not have any contact information except for the name of the borrower, and this is manually cross-referenced with a phone list by the librarian. The enhancement to this application is to have it automatically query Active Directory for information about the individuals who have checked out books. Several different enhancements are targeted. First, if a person were approaching a deadline, the application would create a mailing list to send a reminder. The application would also notice any users who were removed from the system, and it would create a notice for HR about the books checked out.

After determining those applications that you are prepared to integrate with Active Directory, you can create an application roadmap for your Active Directory implementation. This is important because as you scope your project, you need to expose the dependencies of your project and the impact it has on the entire organization.

With Wadeware, we have identified several applications; some are part of Phase 1, and some are not. Tables 5.1 and 5.2 document the disposition of each application for modification in Phase 1.

Wadeware has an application in each category, enterprise, workgroup, and stand-alone. Depending on the size of the organization and the policies for application maintenance, it might not be practical in every organization to get an application in each category; although it does provide an excellent footing for future applications integration. In the first phase of implementation, you need to make a decision. Is it more important to take on the additional risk of combining some application integration with the initial implementation? In some cases, you might need the application to get the sponsorship for the project. This is a scenario where the only reason you are migrating to Active Directory is the opportunity to leverage the directory's information.

In any case, the set of applications that you decide to embrace and move forward with provides the scope of the effort required and a reading of the risk involved the project. A table, like that shown in Table 5.2, helps to quantify the scope of the project.

Table 5.2. Phase 1 Application Summary
Application Complexity of Application Complexity of Using Active Directory Effort Phase 1 Future Features
HR Application 1Simple: VB application with a single interface.Moderate: Email status based on the location in the directory.ModerateYes; 12 weeks effort —16 weeks duration. 
OperationsExcel spreadsheet coupled with undocumented complex processes; company resource security is managed by a variety of administrators.Moderate: Use of directory-supplied roles; apply to predetermined directory scheme.UndeterminedPartial implementation; 8 weeks effort; 10 weeks duration.Further implementation
Event TrackingAccess with some processes.Simple to moderate.Simple to moderateYes; 6 weeks effort; 8 weeks duration. 
Shipping DepartmentNone in existence.Simple.SimpleYes; 4 weeks effort; 6 weeks duration. 
Library Check-outAccess.Simple.SimpleYes; 4 weeks effort; 6 weeks duration. 

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.147.84.157