Failed projects can happen for a multitude of reasons. One of the most common sources of failure is altering the project schedule in midstream without proper planning. This kind of failure is avoidable, but it can require major effort on the part of multiple people. Adjusting the time line or increasing resources on a project are not normally of concern.
A good architect should lead by example, he (or she) should be able to fulfill any of the positions within his team from wiring the network, and configuring the build process to writing the unit tests and running benchmarks. Without a good understanding of the full range of technology an architect is little more than a project manager. It is perfectly acceptable for team members to have more in-depth knowledge in their specific areas but it's difficult to imagine how team members can have confidence in their architect if the architect doesn't understand the technology.
A common problem in component frameworks, class libraries, foundation services, and other infrastructure code is that many are designed to be general purpose without reference to concrete applications. This leads to a dizzying array of options and possibilities that are often unused, misused, or just not useful. Most developers work on specific systems: the quest for unbounded generality rarely serves them well (if at all).
In the context of business enterprise application development, an Architect must act as a bridge between the business and technology communities of an organization, representing and protecting the interests of each party to the other, often mediating between the two, but allowing the business to drive. The business organization's objectives and operating realities should be the light in which an Architect leads technology-oriented decision making.
It seems to be a never–ending source of surprise and distress to system builders that one data model, one message format, one message transport—in fact, exactly one of any major architectural component, policy or stance—won't serve all parts of the business equally well. Of course: an enterprise ( "enterprise" is red flag #1) big enough to worry about how many different "Account" tables will impact system building next decade is most likely too big and diverse for one "Account" table to do the job anyway.
Application architecture determines application performance. That might seem rather obvious, but real-word experience shows that its not. For example, software architects frequently believe that simply switching from one brand of software infrastructure to another will be sufficient to solve an application‘s performance challenges.
However, if you aren't looking at performance until late in the project cycle, you have lost an incredible amount of information as to when performance changed. If performance is going to be an important architectural and design criterion, then performance testing should begin as soon as possible. If you are using an Agile methodology based on two week iterations, I'd say performance testing should be included in the process no later than the third iteration.
- What is the PHP Programming Innovation Award?
- How does the award work?
- Sponsors and prizes
- Current nominees and voting Winners