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?
