It is an unfortunate but well-documented fact that many IT projects never make it into production. Some are like kudzu, continually growing in scope as they consume time and resources but never produce a usable result. Others make it to user acceptance testing only to get a "That's not what I wanted!" reaction from the user community.

Even systems that do make it into production often do not provide the full benefit that was expected. Some provide only marginal benefit, while others provide the benefit but have overrun their cost and schedule to the point where the benefits do not actually justify the expenditure.

Projects such as these are detrimental both to the business as a whole and to the IT organization. Those that never make it into production or provide only marginal benefits are unwise investments on the part of the business. Not only do they not give the expected return on their investment, but they carry an opportunity cost as well, as they expend resources that might have been applied towards other projects achieving other goals that would have provided a better return on their investment.

When embarking on a new SOA intiative or any other major enterprise IT project, therefore, it's critical to address these three fundamental questions:

   What is the measurable business benefit expected of the project?

   What business process changes are required to achieve the benefit?

   Which requirements will present a challenge to the architecture?

The early stages of many projects focus almost exclusively on satisfying a particular set of functional requirements. With an eye toward quickly demonstrating results, such projects rapidly assemble a system with this functional focus. In these initial efforts, little attention is paid to non-func¬tional requirements such as performance and work management - their goal is to demonstrate how the system will help a worker in his or her tasks.

In such projects, it is not until the system has been developed sufficiently to demon¬strate this functional support that the full set of non-functional requirements needed for actual production usage is considered. Unfortunately, in many cases, it is discovered at this point that a major re-architecting of the system will be required in order to accommodate these requirements. Much of the development work will have to be substantially modified to accommodate the re-architecting of the system. The estimated cost and schedule to complete now skyrocket beyond initial budgetary expectations. The credibility of the project team and its new estimates is questioned in light of this lack of foresight. Very often, the project is cancelled due to the lack of confidence in the team and its estimates.

Solving difficult technical problems does not make a project successful. In order to be successful, a project must deliver measurable business benefits under real business conditions. To deliver these benefits, the business process changes required to achieve these benefits and the circumstances under which those business processes are supposed to execute must be clearly understood. Only then can a system be built that is capable of delivering the expected benefits.

(Note: This article is abstracted from a chapter in Paul Brown's upcoming book, Total Architecture, which will be published in Spring 2007 by Addison-Wesley.)