Microsoft Commits to ALM
You might be focused on code today, but get ready for the coming shift to application lifecycle management. The tools are evolving already and will affect your job.
by Don Kiely

Enterprise Application Lifecycle Management 2003

Microsoft's lifecycle tool development has been a long time coming, but that should be no surprise. Software development has long been a seat-of-the-pants activity, following the idiosyncrasies of developers who were focused on the coding itself. The developers made up processes on an ad hoc basis as they went along. Tool vendors followed suit by focusing on coding tools. Development of tools and techniques for managing the overall process has been far more random.

However, as organizations struggle with reduced budgets and increased demands for quality applications, many IT teams are starting to take a holistic approach to managing the process—without squashing innovation. This has given rise to application lifecycle management (ALM), which marshals the tools and techniques used to develop software from first conception of an idea to deployment and lifetime maintenance.

Microsoft typifies this evolution. It has nudged its way into the enterprise application tools space over the last several years, taking two approaches to providing lifecycle management tools. It's providing its own tools for much of the application lifecycle, centered on the Visual Studio .NET suite of development languages. It helps provide what's missing by including hooks throughout VS.NET to let third-party and custom tools integrate with the development environment. Microsoft also works closely with third-party vendors to help implement both competitive and complementary ALM tools.

Application lifecycle management is one of those terms that takes the software industry by storm every few years (remember the Year of the LAN?). Suddenly every big vendor is rolling out a framework to explain how its products provide a complete ALM solution. But it all boils down to the logical steps any software-producing organization must take to conceive, create, and deploy robust, capable applications (see the sidebar, "Set Goals for Managing the Application Lifecycle").

ALM still leaves wiggle room for the needs of particular organizations. Every organization seems to define the software lifecycle a little differently, using different terms, but ALM generally consists of about six groups of tasks: architecture, development, testing, deployment, maintenance, and management (see Figure 1).

None of this mandates the process used to implement all these tasks. The industry has seen sophisticated attempts at defining useful processes, such as the Rational Unified Process from IBM's Rational unit. However, each organization must adopt its processes to fit its own personality and the kinds of applications it develops.

ALM begins with architecture: This comprises everything that goes into conceiving and designing the application, including developing requirements and defining the infrastructure necessary to run it upon deployment. This planning stage typically produces complex, detailed system documentation used during later stages, including data, component, and business process modeling. You can subdivide architecture into various other groups, such as planning, analysis, and design. New philosophies such as Extreme and Agile Programming are causing organizations to rethink this heavy, up-front design step, but have yet to make much headway into most organizations.

ALM Still Centers on Coding
Architecture can't instruct a computer, of course. Sooner or later you must turn to development: the collection of tasks that get the code written, turning those detailed application designs into the executables and other resources that comprise an application. Here's where developers pay the most attention traditionally, and where you'll find the most mature tools. However, turning inadequate architecture into beautiful code is a recipe for the worst sort of disaster.

Likewise, inadequate testing can lay low even well-planned and executed applications. Testing is all too often an afterthought, a step you rush through when the development schedule slips. But testing serves to eliminate bugs in both coding and design; to find and eliminate performance bottlenecks; and to provide proof that an application meets its requirements. Testing functions should start with test designs during the architecture phase and continue through an application's maintenance cycle.

Deployment gets the finished application out to its ultimate users. Sometimes you simply install the application on a single Web server, hooking it into its final Web address. But other times you'll be using complex strategies to deploy it to thousands of workstations, with hundreds of configurations and millions of individual variations in installed software. Deployment strategies must consider how to hook into the resources used by an application, along with the needed security authentication and authorizations.

Maintenance tasks keep the application running over its useful life, even if it never receives a major overhaul. Users and hardware change over time, and a useful application must adapt and adjust to these changes. An application that requires significant attention from administrators or developers will be a burden to every constituent.

Finally, management keeps everything coordinated. It is arguably the most important and most fluid of all the elements of the application lifecycle.

Development teams and managers typically have used ad hoc tools and techniques to manage the application lifecycle. But applications are getting increasingly complex, forcing teams to turn to tools that automate lifecycle management—without getting in the way of how a team performs its processes. Vendors have rushed to provide integrated suites of tools for lifecycle management, each presenting a unique story about how its products achieve the various goals of lifecycle management. Microsoft is no exception (see Table 1).

That said, Microsoft has yet to promulgate a cogent, coherent strategy to the development community. As a result, it isn't easy to discern the company's ALM vision, beyond repeated assertions that Visual Studio .NET provides "comprehensive ALM support"—as long as you have either the Enterprise Developer or Enterprise Architect editions, that is. And Microsoft's new licensing policy is just as fuzzy, by the way (see the sidebar, "The Large Print Giveth—The Small Print Taketh Away").

Microsoft's ALM functionality starts with its architectural solution: a special version of Visio only available as part of VS.NET's Enterprise Architect edition. This tool builds on its familiar visual and graphic design interface to support architectural modeling.

VS.NET's Server Explorer also provides some database-specific design tools. These will suffice for altering an existing database, saving you the trouble of having to fire up SQL Server's Enterprise Manager.

Do Basic Design With Visio
Visio, which you use to model and design databases, supports both Entity-Relationship (ER) and Object Role Modeling (ORM) source diagrams, plus other supporting diagrams with different notations. Visio can generate the scripts needed to create a database, or reverse-engineer an existing one to produce a model. Visio also can do basic model error checking, keep a model and deployed database in sync, and produce copious design reports.

You can model software with UML 1.2 diagrams using Visio. It lets you start from scratch or reverse-engineer from existing Visual Studio 6.0 and .NET classes. It generates VB.NET, C#, and C++ classes from the design and does basic model error checking. Its support for shapes and automation enables it to handle repetitive chores during design.

However, force-fitting various design paradigms into a single environment can cause problems. For example, logical and physical database design might contain hundreds of entities that overflow Visio's page view. You can break a single design into multiple submodels, but Visio doesn't always succeed in automating the components back into a single model. Visio's general-purpose interface doesn't compete with dedicated, standalone design products such as Embarcadero Technologies' ER/Studio or Computer Associates' ERwin products. But you don't always need such high-octane tools.

VS.NET's Enterprise editions include various project templates. You can use these to set up the shells of all kinds of Windows applications. The Enterprise Templates are a collection of base templates you can customize to provide the foundation for enterprise applications. You can include standard project files containing your organization's standard property settings and common code. You can also set policies that encourage developers to structure apps in standard, architect-defined ways.

Of course, VS.NET anchors Microsoft support for development. Much of VS.NET's capability comes from its reliance on the .NET Framework and the Common Language Runtime. All managed code relies on these foundations, enabling Microsoft at last to build its tools around standard code execution. This lets you integrate application components written in any .NET language, and debug and test applications.

The VS.NET IDE's myriad windows and tools encapsulate the features of various command-line utilities included with the framework. For example, the Solution Explorer lets you access all of a solution's resources. The Server Explorer lets you access server services and write code against encapsulating objects. The Class View helps you find and examine classes throughout the solution. Other facilities include support for team development. As you might expect, VS.NET is central to Microsoft's ALM offerings.

Testing, however, is anything but. It's the poor stepchild of Microsoft ALM. This reflects the fact that the development community doesn't take testing seriously. It always gets plenty of lip service early in a project—then gets cut the minute the schedule slips. Maybe that's why Microsoft sold off its automated testing tools long ago. On the other hand, VS.NET does support developer testing. The IDE provides comprehensive debugging features, and the .NET Framework supports assertions and other design-time analysis of code execution. John Robbins' 700-page book about debugging with VS.NET testifies to the abundance of its debugging features (see Additional Resources).

Testing, Testing, Testing …
Visual Studio Analyzer helps you do performance testing. It records information about an application as it runs and allows analysis of the resulting data. VSA helps you find out whether any performance bottlenecks impact the application, how the components in the application interact, and how the application impacts the overall system on which it runs. It provides a high-level view of application execution so you can narrow down your search for a problem, then use other lower-level tools for further analysis. This solves one of the hardest aspects of creating distributed applications, due to the components executing on different machines.

VS.NET's Application Center Test (ACT) suite provides tools for testing a Web app's functionality and performance under different loads. It works by simulating a group of users who hit an application all at once to perform a variety of tasks. ACT lets you examine how the server and application work under stress. It also supports programmatic dynamic tests useful for unit testing.

VS.NET's current testing tools focus more on developer tests—especially performance testing—as opposed to tests performed by an external testing staff. However, Microsoft helps integrate third-party automated test suites into .NET applications and VS.NET.

As for deployment, Microsoft Installer (MSI) comes with recent versions of Windows and helps relieve the difficulties of deploying custom Windows applications. COM's design and the way Windows loads and executes DLLs have long made it tough to install an app reliably on every machine configuration in an enterprise. DLL Hell has been the Windows development industry's worst nightmare for years.

MSI helps by providing an infrastructure for application deployment within the operating system, improving reliability, and reducing the infrastructure deployment packages need as part of their distributables. MSI records installations internally on a machine and caches the deployment packages, making applications self-healing when users delete a critical application component. Users don't even have to know a problem occurred. Also, an MSI database takes care of system configuration tasks such as Registry updates and modifying permissions on a resource.

However, MSI doesn't eliminate the need for deployment tools. MSI's low-level API is inefficient to use directly for every deployment package. Companies such as InstallShield and Wise Solutions have built the latest versions of their deployment tools on top of MSI, while still providing significant value in automating and simplifying package development.

Microsoft includes basic setup and deployment package projects within VS.NET. These help build basic deployment packages for various kinds of apps. The end result can be a standalone setup executable, an MSI file, or a compressed CAB file for installation across the Internet. .NET also supports xcopy deployment. Here you copy an app and its directories and run the app, because basic apps require no registration on destination machines.

Another part of the deployment story is what Microsoft used to call its .NET Server products before it worked the .NET name to death. These servers provide important application infrastructure support for .NET distributed applications. For example, SQL Server 2000 provides data services; Exchange Server supports e-mail and other collaboration features; and Internet Information Server (IIS) serves up Web pages.

Microsoft Has Trouble Maintaining
Developers typically spend two-thirds of their time maintaining apps. Yet maintenance support (or the lack thereof) might well amount to the weakest link in Microsoft's ALM toolset. VS.NET includes nothing in the way of bug- or feature-tracking software, or any sort of maintenance analysis tools. You can certainly use tools such as SharePoint Portal Server or Microsoft Excel to roll your own, but that can take a lot of time and work to implement. Beyond other ALM tools such as Visual SourceSafe and VS.NET's team development features, this is a major area where Microsoft needs to expand its offerings if it wants to lay claim to providing a complete ALM solution.

Microsoft also falls short in the area of development management support, though not as badly as maintenance support. The company provides two kinds of tools that generally fit this category: project management software and some administrative tools that support distributed applications.

Its project management software, of course, is the popular Microsoft Project. Project bristles with every feature you're likely to need to manage a complex development project. It includes collaboration tools for gathering and reporting project status. Various project templates help you get started, including templates for infrastructure deployment, application deployment scenarios, and software development. Project does lack integration with other lifecycle tools, though this might not be a significant weakness.

Visual SourceSafe provides source code and project resource versioning, plus a central, shared repository for project artifacts. It provides many of the basic features of such systems, but it hasn't received a significant upgrade in years. Other third-party tools provide much better solutions. On the other hand, Microsoft built hooks into VS.NET that any third-party vendor can use to integrate version control with the IDE, making other products feel like they're built into VS.NET.

Microsoft also provides numerous administrative tools for managing almost every aspect of distributed applications. In particular, you can set rigid security policies for both applications and users to control development and deployment.

Microsoft's ALM offerings include hits, misses, and in-betweens, making it prudent for VS.NET-based teams to look at competitors' .NET ALM offerings. For example, both Borland and IBM/Rational have pledged support for .NET with their ALM tools. Recent months have seen some market consolidation, such as Borland acquiring TogetherSoft and IBM buying Rational. These and other companies take full advantage of the hooks Microsoft placed in .NET to integrate lifecycle tools.

Borland Gives Good .NET ALM
Borland is probably the most aggressive of the lot in targeting .NET applications without focusing on them exclusively. Borland is extending its own development tools to do so, along with its TogetherSoft team collaboration tools. Borland now provides a comprehensive ALM package supporting .NET, Java, Oracle, and more. Microsoft promotes Borland's ALM tools almost as aggressively as Borland, even though some of them compete directly with Microsoft offerings.

IBM's Rational unit lacks Microsoft's and Borland's range of development tools, but compensates with sophisticated support for other parts of the lifecycle. The company has a version of its XDE "extended development experience" tool that integrates into Visual Studio .NET. Rational historically dominated the architecture portion of the lifecycle with its Rational Unified Process and its pioneering work in UML for modeling applications and components. When IBM bought Rational, the companies' merger produced a comprehensive set of ALM products.

Many other companies provide tools that support subsets of the application lifecycle. I think you'll continue to see more consolidation in this part of the software industry as both vendors and customers realize the synergy of using integrated toolsets to manage the increasing complexity of software development.

When your team commits itself to a set of integrated ALM tools, it has made a major decision—one that will affect how you approach projects and your success with them. A bad decision force-fits your team to a process or methodology incompatible with the team's personality. This might result in failed projects or at least will stress team cohesion. But the right decision can smooth everyone's work and make it fun again. Microsoft is clearly working to provide the integrated tools to help you survive ALM. Best of all, Microsoft recognizes the holes in its product line and has enabled ISVs to fill in the gaps, so you can assemble a true ALM solution well suited to your people and projects.

About the Author
Don Kiely, MCSD, MCP, MDE, is a senior technology consultant. When he isn't writing software, he's writing about it, speaking about it at conferences, or training developers in it. Reach him at .