One of the most challenging transitions in a developer’s career is the move from developing applets, desktop, or client/ server applications, architected around a single or two tiers to distributed, enterprise application development.

Two overriding problems face enterprise developers. First, the scope of large scale development and maintenance dictates that developers cannot produce and maintain separate code which providing the same services to multiple applications in an enterprise. Applications must be modular enough that simple changes in business logic do not require modifications to multiple applications. Second, applications must be easily integrated and must be able to readily share data and business logic. Today even small organizations need to distribute services across application and geographic boundaries because they play in global markets or because they need to integrate with the systems of parent companies, suppliers or customers. As developers progress in their careers or as their organization grows, they frequently encounter problems with building and scaling distributed transactional applications.

Managing increasingly complex systems entails reuse of business logic in a range of applications often on a number of platforms. The enterprise architect must figure out how to solve the business problems while still being able to manage code so that modifying or updating business logic doesn’t require touching all those applications. Another need is to provide some standards that allow third party developers of tools to create tools and components to a predictable architecture.

A number of vendors have created frameworks to aid in building scalable, distributed applications. Microsoft with its DNA (Distributed Network Architecture) and .NET Framework have componentization models to address these issues using COM, DCOM and COM+. These will be addressed in other articles.