Whether you're a developer writing code, a manager guiding a project, or a customer giving requirements, you're familiar with the steps needed to successfully create a business application. Often referred to as the application-development life cycle, these steps typically involve gathering requirements, and designing, developing, testing, and deploying the application. Sound easy?
Anyone with any application experience knows that the application development process is fraught with unknowns. In the networked applications space, the unknowns can be even more extreme when it comes to the gap between the technical infrastructure - application servers - and the actual business requirements. More specifically, the architectural issues alone in the "developing the application" stage are often left to the developer or distributed to architectural teams. Several pitfalls can arise in the critical architectural stage:
Developers don't know where to start when building an application.
Often a developer allows the user interface (UI) to drive the business requirements and begins to code. A typical mistake is that the UI developer goes too far when extending the presentation logic with actual business functionality. It then becomes difficult to decouple the functionality and share it across the application, or the developer gets backed into a corner when faced with more difficult issues like data persistence.
Developers have difficulty with the steps needed to successfully build an application.
Even if a development team has been sufficiently trained in the infrastructure technology, such as WebLogic or Microsoft DCOM, they're still left a blank slate when development begins. This opens up questions like "Where do I start?" "How does all of this technology - EJBs or JMS or DCOM or .NET - help me with what I'm building?" "How do I glue it all together to get to my end application?" Infrastructure technology often leaves the developer with more options than answers.
Many developers are solving the same technical problems.
Take, for example, an e-commerce site. How are decisions such as how to maintain a catalog applied across a project? If the tasks are split up, a developer focused on just one aspect of the application has his or her own deadlines and likely won't have the time or inclination to share this information with others. From a technical perspective, this evolves into more critical decisions, such as how to manage data persistence or validation. For example, "How do I manage input from an HTML form or data type validation?" "What does my validation routine look like?" "What is a valid address?" "How do I call an EJB and what are the steps to do this?" It's easy to see how the development team quickly focuses on nitty-gritty details, not on the application itself. Not only are developers trying to solve the same problems, they're also not sharing these decisions.
Project managers don't know what to expect from developers.
Take, for example, a developer who tells his or her manager that it will take two months to develop the "user flow experience." How does the project manager judge this answer when he or she doesn't have insight into the technical decisions to a working application?
Project managers can't easily assign work based on developers' skills, as the delineation of work is often nebulous.
How do you separate tasks such as business logic from the user interface or from integration? How do you make sure the user interface doesn't extend too far into the business code? This often forces a developer to tackle more issues than he or she needs to, such as addressing security and distribution. Developers start dealing with not just one class but 10 classes equaling thousands of lines of code and often don't have the domain expertise sets to do the work.
The application is hard to maintain and extend.
Applications built without architecture are extremely difficult to update, extend, and modify for basic bug fixes and modifications, as well as for more robust overhauls, to meet changing business requirements. Developers tasked with updating applications spend a majority of their time locating the specific areas they have to change and carefully modifying those areas so as not to break another part of the application.
The delineation between the technical details and business logic or functionality of the application is not clear.
This is most often found when handling persistence in the application, such as how to interact with the data store. Do you use EJBs to interact with the data store or data access objects? Are you directly calling your EJBs or using Session Facade for this interaction? If your development team's not careful, they've coupled those decisions to the application. Often, trouble is not uncovered until the testing phase. At this point, the cost of overhauling the application is very high.
The bottom line is that the architectural issues behind developing enterprise applications are significant. Without a structure in place, developers are left with undocumented procedures or a verbal design philosophy to guide their development. On top of this, anything ambiguous is left to the team to work out. The nature of the beast in application delivery is that deadlines are looming. The end result is the application, not the document, so teams will cut corners where they need to.
The Importance of Application Architecture
The Role of Application Architecture
Where are the above issues most appropriately addressed? This is the role of application architecture - a very critical step in the application-development process. Unfortunately, this step is often lumped with "develop the application." The application architecture determines how the application is developed and its rules.
Sometimes the infrastructure provided by J2EE application servers or the technical plumbing provided by a collection of third-party class libraries is confused with application architecture. Infrastructure components are required for an application, but their role in a distributed application is to provide some "technology feature" such as transaction management, thread management, or distribution. The infrastructure, however, stops short of determining how the application needs to behave.
Application architecture gives development teams the structure for the application and eliminates a significant amount of the coding effort. This structure shields the developer from common development mistakes by providing a better format that eliminates redundancy and inconsistent code and by bringing the actual development closer to the business requirements. Application architecture is reusable across projects allowing:
In the not so distant past, a developer's productivity was measured by how much code he or she wrote. Today, in a world of increasing development complexity and time demands, less is more. Less code means less to create, less to maintain, and less to execute.
- Developer resources to be transferable between projects
- Lower costs due to not reinventing the wheel
- Lower maintenance costs due to a uniform approach
- Lower training costs
Application Architecture Approaches: Ignore It, Build It, or ???
In the long history of enterprise applications, there are two answers when approaching application architecture issues: "don't have one" or "build one." By definition, architecture is the structure of an application. If you have an application, you have an application architecture.
If you chose the "don't have one" approach, what actually occurs is architecture that "just happens." Developers make critical application decisions in isolation or don't apply decisions consistently across the application.
If you chose "build one", whether it's your first, second, or third application, the architectural issues you need to address are significant.
How are development teams reusing the architecture? How is it being implemented?
How is it documented? How do I train development teams to use it?
Is it current? How will you port the architecture as the underlying infrastructure technology changes?
How do you plan to maintain the current architecture? How do you plan for continually changing resources? How do you take advantage of emerging technologies, such as Web services, if your original resources on the project left?
What if consultants don't want to work with the current framework because of "spaghetti code" syndrome and are proposing a new approach?
This is just the beginning. Given that development teams are measured on the delivery of the application, not on the "purity" of the architecture, this results in either paper-based or poorly documented implementations that only get used by a single programmer or single project. If problems do arise as a result of the architecture, there's little chance to correct it. As development teams generally need to move on to the next project, there's little time allocated to perfecting it. If the application is functioning, the "if it ain't broke, don't fix it" mantra rings true when it comes to architecture.
Problems with Building Architecture
Revisiting where architecture typically fits in the application development life cycle, it's easy to see why time is a problem. The architecture is usually squeezed between design and development. The customer of the application probably doesn't care about the architecture and very likely wouldn't understand it. Because architecture is an intermediate result, quite often it's not given the proper attention it deserves. The architecture is usually the first thing to give way when there's a schedule crunch. Typically, the design stage runs over and the final deadline isn't flexible. Architecture usually suffers first.
The skills required to build a quality architecture are in short supply, making the cost to build it prohibitive. Recent studies show that firms need to budget as much as $3,500 a day for one architect in the J2EE arena (Forrester Research, "Putting J2EE to Work," July 2001). One firm claimed that it would take them 12 months just to build the development framework needed to support the application. Architecture marries the business application to the technology infrastructure, and requires the architecture builder to be intimately familiar with application building and the technical infrastructure.
The last problem encountered when building an architecture is the need for iterative development. Consider the evolution of the application development life cycle. Not too long ago, the waterfall approach was very popular. This approach broke the work into large chunks (requirements, design, development, etc.) that were done sequentially over a long period of time. The current trend in application development is to use an iterative approach. The steps taken are similar to the old process (e.g., requirements, design, development, etc.) but they're executed in an iterative fashion over short periods of time. Using small iterations means results are seen sooner and feedback is incorporated more often, resulting in a better product. This same approach is required for a high-quality architecture. Iterations are required to refine the architecture and prove its validity. However, architecture iterations are close to impossible to incorporate into an application development life cycle because of the logistics involved. The developer training, application rewrites, and delivery schedule hinder incorporating architecture iterations.
Results of Building - The 3 Ps
The building process results in three types of architecture: a paper one, one that a single programmer uses, or one that a single project uses - paper, programmer, project - the 3Ps.
The paper architecture is actually not an architecture; that is, it isn't physical code, therefore it leaves the developer at square one when it comes time to build it. Paper architectures usually result when there's a central think-tank group that determines the overall technical direction. While important architectural decisions are made, the actual code still needs to be written for the architecture.
The programmer architecture involves an individual programmer who builds the application architecture. More than likely other programmers on the same team are solving the same problems in their parts of the application. So you have a single project with little or no consistency across developers.
The project architect is the best possible outcome in a build situation. The need for an architecture has been recognized, but the architecture is likely limited to the project for which it was built. Because the architecture was made to solve the problems of one project, it probably won't be reusable across other projects. Since the architecture wasn't a tangible goal of the project, it likely won't be documented nor will it continue to evolve. In short, it starts and ends with the project.
Buying Application Architecture
Why do companies historically build architectures? Usually, there's no alternative. If the infrastructure technology used by a company is unique, then it's not likely that they would find a commercially available architecture to support the infrastructure. However, with infrastructure standardizing around platforms like J2EE and .NET, buying an application architecture is a viable alternative. It not only eliminates the build challenges discussed earlier, it also provides many benefits such as best practices, future-proofing of the application, significant costs savings, and quicker time-to-market.
Best practices for application architecture include those for developing code as well as for solving the architectural problems. Becoming familiar with these best practices is done through experience and shared industry expertise. In the world of enterprise applications, an increasingly important source of this industry expertise is design patterns, such as the J2EE Blueprints or object-oriented patterns. Design patterns capture a problem definition and a possible solution in a textual format, allowing people to share their experiences with others to avoid similar problems. Implementing these patterns while staying on top of best practices requires constant attention that only a vendor who is providing the solution can realistically afford.
A good application architecture will provide a longer life for your application. Incorporated as a product, the architecture allows the application to easily adopt new functionality and isolates the application from technology changes whether it's upgrading to a new version of a J2EE application server or taking advantage of emerging Web services functionality.
Less Time and Lower Cost
A very immediate benefit of purchasing an application architecture is lowering the cost of building the application and accelerating the application creation. Many companies are realizing that it's taking 12 months just to get their development framework or application architecture implemented. That's not even taking into account the actual construction of the business application itself.
A good application architecture product needs:
Just as in the early days of object-oriented, Java, and Web application development, many companies attempted to build their own distributed services (load balancing, security, dynamic page generation, and scripting) to support their applications. Tackling this in-house was cost-prohibitive, in terms of time-to-market and maintenance, and opened a door for an application server market in which lead vendors assumed the role of providing this infrastructure (BEA, IBM, and others). Can you imagine having a conversation with your CIO about wanting to build your own application server?
- To be tested, proven, and built on industry best practices
- To have extensive documentation
- To be supported by a company that's focused on providing architecture and that will continue to maintain and extend the offering
- To provide formal training to get the application team up to speed quickly
As companies build more sophisticated enterprise applications, proceeding without a proven architecture will be folly. How you approach application architecture and address its considerations across the application, as well as across future applications, is increasingly critical to your overall success.
Application architecture is critical to the initial success of an application and the ongoing success of maintaining and extending it. Companies have historically built their own development frameworks with varying degrees of success. With no other options available, development teams were left to poorly documented, unrepeatable application architectures.
As standard technical infrastructures such as J2EE and .NET continue to mature over time, development teams will gather more enterprise experience grappling with how best to divide up work tasks, utilize the infrastructure technology, and deliver applications on time. With growing industry acceptance of these infrastructures, vendors are delivering tools and frameworks to ease the next level of application development for many project teams, allowing them to focus on the business requirements at hand and obviating the need to deal with what will soon become mundane development tasks. Nowhere will this be more apparent than in the area of application architecture.
Walter Hurst is the CTO and cofounder of Wakesoft, a provider of prebuilt application
architecture and frameworks for J2EE. He received a BS in computer engineering from the University of Michigan. [email protected]
Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.