On projects where both the business functionality and the technology are well understood, the project team will be best served by adopting an existing architecture, with minor modifications where needed. If the system is small enough, the architecture may not need to be specified in much detail. For example, a system may be simply defined as being web-based: this implies a host of technical decisions, as will be illustrated in later chapters.
Of course, if some element is absent from the architecture needed for a project, the team may be free to add it. This increases the risk and the cost, since no support will be available from the system architect and her team.
Where a new development project is driven by business innovation, it is best to adopt an existing, robust architecture. This reduces the development risks by not adding technical risks to the business risks.
On projects driven by technology – when someone has had a novel idea for applying technology in a way that hasn’t been done before – you may well need a new architecture altogether. This architecture must at least be designed before the requirements process goes too far. In most cases, it will need to be developed and tested on a pilot project, to verify that the technology is workable and will help solve the business problem.
Finally, note that most of the systems “development” activity of existing IS departments is in fact maintenance. Maintenance requests very rarely have an impact on the system architecture.
In summary, in most cases, the system architecture will be given at the outset of a development project, or at least in its very early stages – certainly before requirements gathering is complete and before design has gone very far.
- 瀏覽次數：1310
