Face it. Most information technology (IT) shops must deal with internal development. It's not that we aren't happy with commercially available products; it's that everybody is happier when things are custom made just for them. Whether your shop is small, medium-sized, or very large, chances are you have some custom tools in place that have been developed exclusively for your organization. Custom development can be as simple as the minor modification of a commercial solution, or it can go as far as the complete development of core code that provides functionality that only your organization requires. In most cases, these custom tools provide mission-critical services and are often the main reason for the existence of the IT shop.
Given this mission-critical goal for IT, it's surprising to see how few organizations have taken the time to properly design an IT infrastructure that can fully support internal development. Technologies such as Microsoft® Windows® XP and the various flavors of Linux™ include many features you can use to create support infrastructures for developers, even if systems are locked down -- perhaps especially if systems have been locked down.
Several reasons exist for locking down computers in corporate environments -- system protection, control over which applications are installed, control over standard system configurations -- but locking the system, especially through a "hard lock," is not the ideal solution for every type of user. With IT shops increasingly concerned about security, people have finally started using recommended practices for system operation -- for example, using a user account with minimal rights for all production operations and requesting an elevation of privilege from the system only when special administrative operations are performed. For typical users, this means no elevation of privilege ever. For developers, this kind of situation can be a nightmare. Developers require special access rights: the right to install software, to uninstall it, to create shares, to modify databases, and so on. If they don't have these access rights, they can't do their jobs. So IT must maintain a balance between locked-down systems and developer requirements, a balance that maintains system security while making it easy for developers to work. The solution is to create and design a proper development architecture.
Identifying development requirements
In the past, IT has provided a series of solutions that have left much to be desired. For example, the use of two-system partitions -- one in which developers are only users and one in which they are administrators -- doesn't really provide a good mechanism for development. Other IT groups have provided two complete systems with interchangeable hard disks; once again, this solution lacks finesse, to say the least. The problem with both of these approaches is that neither the developer nor IT is happy. IT cannot control a partition if it isn't turned on, so two partitions don't work. Developers can reboot from one partition to the other depending on whether they want to check e-mail or write code. Not a pretty story. This type of situation leads only to dissatisfaction on both IT and the developers' parts.
A real answer must be found -- one that meets developers' requirements and the IT mission. The nature of this answer is the basis for the development architecture.
Designing the development architecture
As you've seen in previous articles in this series, each architecture must contain at least 10 specific elements. These elements are the same for each architecture, but you'll find that you tend to concentrate on different aspects of these elements depending on the architecture you're working on. In the case of the development architecture, the most important aspects are:
- Driving principles for the architecture
- Defining principal actors in the architecture, specifically the development clients
- Outlining architecture policies
Figure 1 outlines the most important aspects of the architecture for this portion of the enterprise architecture.
Figure 1. Key steps toward a development architecture
An important factor in the development architecture is the underlying technologies that have been selected and outlined in the infrastructure architecture. For example, you would not choose to rely on Microsoft development tools if your entire infrastructure relies on Linux technologies. In fact, the tools and technologies you choose to build your development center must be closely aligned with the tools and technologies that run your infrastructure; otherwise, you will forever be at odds with it, and the solutions you create won't be cost-effective or even appropriate for your environment. In short, it doesn't matter whether you decide to use the Microsoft .NET Framework or Java™ Enterprise Edition (JEE) technology as long as the foundation platform you choose to work with is the same foundation platform your infrastructure counterparts have selected. That, of course, is for internal development. The beauty of today's development platforms is that they are based on standards -- standards that easily allow you to create components internally or reuse external components that have been designed by others but that are made commercially available on an as-needed basis. This is the foundation of the service-oriented architecture (SOA), an architecture that consists of components so that each object can act as a building block in an overall solution.
OK, so you need to overhaul (if it exists) or create (if it doesn't) your development architecture as part of your new enterprise architecture. One common error most organizations make in creating the development architecture is the mistaken identification of the principle clients that make up internal development. In most cases, this architecture has three main clients:
- Internal, corporate developers
- External, consultant developers
- Internal, noncorporate developers
The first two clients are the most common. Internal developers are really the main client for any development architecture, and they commonly draw on outside resources when projects become too large or complex for internal resources to handle by themselves. Both of these clients require guidelines and structure for any development project. After all, you don't want to have either internal or external developers include unapproved or unauthorized snippets in your code.
You'll learn more about this later, but one client that is most often forgotten in development architectures is the internal, noncorporate or ad hoc developer. This "user" developer often operates in a complete void, lacking any official support from the organization. Yet, the products that these developers release -- word-processing or spreadsheet macros, personal database applications, and so on -- often become critical tools that a large majority of the organization's users employ. What's worse, because these "development" projects are rarely officially funded, they are often difficult to upgrade as older productivity suites are replaced with newer versions. A proper development architecture ensures that all clients are covered and that the organization profits from any internal development project, be it produced by "real" or user developers. This insurance typically translates into an architecture that covers two aspects: official n-tier development and user-driven development projects.
Both aspects of the architecture must include the same components. Both must rely on centralized strategies, and both require a stringent set of standards and the proper tool set. (For an example of a user development strategy, see the sidebar, User development strategies.) These strategies tend to be less formal than n-tier strategies and, although they require the same type of support at a smaller scale, they do need to be official.
Implementing development architecture policies
The best thing about modern professional development tools is that they fully support the implementation of standards. For example, experienced developers can use these tools to create templates from which junior developers can produce code. Using these templates, you can determine which features will be available to your development team for any particular project. They also ensure that only those code snippets and add-ons that are officially approved are allowed in your code. In addition, they can be designed to include workflows so that the code each programmer develops runs through a proper approval and validation process. You can use templates such as these to support junior programmers who operate in-house, but you can also use them to ensure that external developers rely on the same standards and approaches that you do when they work for you.
However, before you can use these tools to create templates, you must determine which architectural policies you want to rely on in your development projects. For one thing, make sure that everyone is producing secure code (see Resources). For another, make sure that everyone is documenting their code, including data references, impersonation values, methods used, and procedures. You want developers to create code based on a life cycle that includes the proper generation of models before any line of code is generated. You also want to make sure that all coding projects have properly defined requirements -- requirements that are drawn from and rely on the business and information architectures. Finally, make sure that all the tools and tool kits on which the development architecture is based are related to and tie into the infrastructure architecture.
Granting proper corporate citizenship to developers
Development or solutions architectures are probably the best documented architectures on the Web, but one thing lacking in most of these architectures is the link that ties them back to all the other architectures, especially the infrastructure architecture. We'll cover much of this in the last two articles in this series (on the integration and operations architectures, respectively). For now, it is important to ensure that your development architecture includes the principles that will allow your developers to work unhindered but still within secure corporate boundaries. Locked-down systems make life difficult for developers, but this doesn't have to be the case.
The advent of virtual machines (VMs) -- especially free technologies that support VMs from manufacturers such as VMware, Microsoft, and Xen (see Resources) -- go a long way toward providing the proper level of freedom for developers while keeping corporate systems secure. Within these VMs, developers can have full administrative rights and run their production systems as normal users. You can also rely on these VMs to provide copies to external developers, automatically ensuring that they follow the standards you set out in the architecture.
In addition, shops that rely on directory services such as Microsoft Active Directory directory service or IBM® Tivoli® Directory Server should construct their directory structures in such a way as to create proper realms for development resources. These realms can provide freedom to developers while ensuring that production environments remain secure. Once again, this type of approach helps grant the proper access rights to developers but continues to protect all production systems (as shown in Figure 2).
Figure 2. Developers are hosted within a development realm and use universal groups to access production data and systems
Whichever strategy you use -- individual VMs, complete development environments based on VMs, or independent realms based on directory services -- one thing is clear: As you work through the development architecture, keep in mind that it is only one aspect of the enterprise architecture. This is the only way that you will be able to grant developers proper corporate citizenship within your organization.
Most organizations do not want to allow installation rights to user developers, and rightly so. But, organizations must make the most of all the custom development that their staff members perform. This means that user-developed applications or solutions must be inventoried to ensure that no one is performing the same development twice. How many times have you found out that you now have seven different time sheets, ten different expense claims, and numerous electronic copies of the corporate letterhead? Inventories solve the duplication issue.
Next, you need a central repository to make sure that everyone knows that any development is corporate development and to let all your user developers know that they are part of a community -- a community that has central resources it can draw upon. The repository should list all the approved applications and include the ability to search for existing code. This way, when a user developer wants to create something new, he or she can start from existing work. Finally, include a deployment mechanism that allows user developers to distribute their solutions without requiring installation rights on any system.
The latter is simple: Just make sure that any tool you decide to support for user development includes a run-time edition. By making these run times part of your basic system image, you ensure that any application designed to rely on them automatically runs. The second advantage of including run times is that because they are already installed, loading any application that relies on them onto a system means just that: copying the files from one location to another.
Your UDS must have another caveat, though: User developers must design applications based on run times, not on the actual application. For this, you may need to provide some form of training. Guidelines and standards in the development architecture are often all that is required.
Now, organize the repository. It should really be nothing more than a file share with a standard structure. Each user application should include six standard folders. The name of the master folder for each application should be in the form of an asset number. (Typically, a four-digit number is sufficient.) The six folders should be:
- Clients: All files to be copied to the local computer
- Documents: The application’s documentation
- Icons: The icon of the application in picture format
- Shortcut: A special script that controls deploying and launching the application
- Source data: The data source if the application requires it
- UserGroups: A folder that includes a file called USERS.txt, which lists the names of authorized users of the application
Every application uses the same folder structure. Users have read and execute permissions to these folders, while user developers have write access as well, at least to the folders of the applications they’re responsible for. This folder structure should be searchable and linked to an intranet page listing all applications.
The crux of the UDS system is a custom script -- a script that is ideally code-signed and that performs a system verification before opening the application. Verifications include:
- Is the user authorized? Reads the USERS.txt file to verify that the user’s name is on the list
- Is the application on the user’s system? Verifies that the application components are on the local system
- Is the application up to date? Compares a date file for the application on the local system with the date file for the application in the repository
That's it. If the user is unauthorized, the application displays an error message. If the application is not on the local system, the script must download it. If the application is not up to date, the script must update it. For this process to work, the script must run through these questions each time the application is started. If everything is okay, the script launches only the application. If not, the script performs its job. This process is illustrated in Figure 3.
Figure 3. The UDS application "installation" process
Deployment is simple. Make sure that the user's name appears in the USERS.txt file, make sure that the script points to the right folder structure, and then send the script to the user.
When working on your development architecture, make sure you address the needs of every developer in your network. Too many organizations fail to tap into their user developer resources and lose this valuable asset -- or worse, waste it with duplicate effort. You won't regret putting a UDS in place, and doing so is simple: Inventory all the user applications you own, move them to a centralized repository, implement some standards for these applications moving forward, teach your user developers new tricks, and keep your systems locked! In this way, you control all the development assets you have in your organization and make your user developers a lot happier. That's worth a little effort, right?
Learn
-
Stay current with
developerWorks
technical events and webcasts.
-
For more information about enterprise architecture frameworks, read
"Let's talk: Build
your enterprise architecture using communication and the right framework," by Danielle
Ruest and Nelson Ruest (developerWorks, June 2006).
-
Learn more about the governance model in enterprise architecture: Read
"Manage the
unmanageable," by Danielle Ruest and Nelson Ruest (developerWorks, May 2006).
-
Get more information about
developerWorks IT architecture.
-
Check out other installments in the series
Exploring
IT architecture disciplines, by Nelson Ruest and Nelson Ruest.
-
Read the white paper, Best
Practices for Secure Web Development, by Razvan Peteanu.
-
For more information about coding best practices, see the MSDN presentation,
"Writing
Secure Code -- Best Practices from Microsoft."
-
Search for related books at Safari Bookshelf.
Get products and technologies
-
Build your next development project with
IBM trial software, available for download directly from developerWorks.
- Download Xen Source virtual machine.
-
Download Microsoft
Virtual Server 2005.
-
Download VMware Server and
VMware Player.
Discuss
- Participate in the discussion forum.
-
Participate in developerWorks blogs
and get involved in the developerWorks community.
Danielle Ruest is a senior enterprise IT architect (EITA) focused on people and organizational issues for large IT projects. Danielle has been involved in the design and support of complex collaboration implementations, including deployment of technologies for e-mail, team sharing, and secure instant messaging. With her partner Nelson Ruest, she is the author of Preparing for .NET Enterprise Technologies, (Addison Wesley, 2001). and Windows Server 2003: Best Practices for Enterprise Deployments (McGraw-Hill Osborne, 2003) and participates in many webcasts and conferences. You can reach Danielle at architectures@reso-net.com
Nelson Ruest is a senior enterprise IT architect (EITA) with more than 20 years of experience in migration planning and network, computer, server, and overall solution design (including MCSE, MCT, Microsoft MVP Windows Server). He has been a computer operator, a systems administrator, a trainer, a help desk operator, a support engineer, an IT manager, a project manager, and now, an IT architect. He was recently named a Microsoft Most Valuable Professional for the Windows Server product line. You can reach Nelson at architectures@reso-net.com.
