Previous    Next

Goals of an Enterprise Architecture

Before we begin to examine specific issues in J2EE architecture, let's consider what we're trying to achieve. A well-designed J2EE app should meet the following goals. Note that while we're focusing on J2EE-based solutions, these goals apply to all enterprise apps:

• Be robust
  Enterprise software is important to an organization. Its users expect it to be reliable and bug-free. Hence we must understand and take advantage of those parts of J2EE that can help us build robust solutions and must ensure that we write quality code.

• Be performant and scalable
  Enterprise apps must meet the performance expectations of their users. They must also exhibit sufficient scalability - the potential for an app to support increased load, given appropriate hardware. Scalability is a particularly important consideration for Internet apps, for which it is difficult to predict user numbers and behavior. Understanding the J2EE infrastructure is essential for meeting both these goals. Scalability will typically require deploying multiple server instances in a cluster. Clustering is a complex problem requiring sophisticated app server functionality. We must ensure that our apps are designed so that operation in a cluster is efficient.
• Take advantage of OO design principles
  OO design principles offer proven benefits for complex systems. Good OO design practice is promoted by the use of proven design patterns - recurring solutions to common problems. The concept of design patterns was popularized in OO software development by the classic tutorial Design Patterns: Elements of Reusable Object-Oriented Software from Oracle, (), which describes 23 design patterns with wide applicability. These patterns are not technology-specific or language-specific.
  It's vital that we use J2EE to implement OO designs, rather than let our use of J2EE dictate object design. Today there's a whole "J2EE patterns" industry. While many "J2EE patterns" are valuable, classic (non-technology-specific) design patterns are more so, and still highly relevant to J2EE.
• Avoid unnecessary complexity
  Practitioners of Extreme Programming (XP) advocate doing "the simplest thing that could possibly work". We should be wary of excessive complexity that may indicate that an app architecture isn't working. Due to the range of components on offer, it's tempting to over-engineer J2EE solutions, accepting greater complexity for capabilities irrelevant to the business requirements. Complexity adds to costs throughout the software lifecycle and thus can be a serious problem. On the other hand, thorough analysis must ensure that we don't have a naïve and simplistic view of requirements.
• Be maintainable and extensible
  Maintenance is by far the most expensive phase of the software lifecycle. It's particularly important to consider maintainability when designing J2EE solutions, because adopting J2EE is a strategic choice. J2EE apps are likely to be a key part of an organization's software mix for years, and must be able to accommodate new business needs.
  Maintainability and extensibility depend largely on clean design. We need to ensure that each component of the app has a clear responsibility, and that maintenance is not hindered by tightly-coupled components.
• Be delivered on time
  Productivity is a vital consideration, which is too often neglected when approaching J2EE.
• Be easy to test
  Testing is an essential activity throughout the software lifecycle. We should consider the implications of design decisions for ease of testing.
• Promote reuse
  Enterprise software must fit into an organization's long term strategy. Thus it's important to foster reuse, so that code duplication is minimized (within and across projects) and investment leveraged to the full. Code reuse usually results from good OO design practice, while we should also consistently use valuable infrastructure provided by the app server where it simplifies app code.

Depending on an app's business requirements, we may also need to meet the following goals:

• Support for multiple client types
  There's an implicit assumption that J2EE apps always need to support multiple J2EE-technology client types, such as web apps, standalone Java GUIs using Swing or other windowing systems or Java applets. However, such support is often unnecessary, as "thin" web interfaces are being more and more widely used, even for apps intended for use within an organization (ease of deployment is one of the major reasons for this).

• Portability
  How important is portability between resources, such as databases used by a J2EE app? How important is portability between app servers? Portability is not an automatic goal of J2EE apps. It's a business requirement of some apps, which J2EE helps us to achieve.

Previous    Next