Information Technology Reference
In-Depth Information
constantly changing spectrum of offerings that must be addressed in
today's marketplace. Before project management became a formal part
of the enterprise, a single application could take many years in succes-
sive attempts, only to be discarded ultimately because the need no longer
existed or some other alternative was found in the meantime. The ugly
term “feature creep” is a constant enemy to progress in any technology
endeavor. When user expectations meet regulatory requirements and
operational mandates, clear objectives and scoped guidelines must be in
place to allow the steering committee to hold onto the project's original
purpose. It is far too easy to attempt to take a simple calculator applica-
tion and try to shoehorn in e-mail, calendaring, human resource training,
NASA image galleries, and the kitchen sink when programmers and users
are set free to do as they please.
A technology architect must possess both business acumen and tech-
nological savvy in order to filter through user requirements and sift out
“need” from “want,” while also seeing past the technobabble jargon that
technologists are wont to use even when dealing with normal mortals who
struggle with their VCRs. The architect must identify future technol-
ogy trends, emerging opportunities, and evolving security requirements.
Between the thousands of new viruses created each year and the increas-
ing complexity of regulatory requirements, architects are kept very busy
just honing the skills of their trade before they can begin its practice.
Opportunity Costs
Economists know that when a purchase is made, it is made at the expense
of other selections that might have been purchased instead. The oppor-
tunity cost of a technology selection can be very significant when money
is spent to obtain needed skills, implement new solutions, and train users
in their operation. Selection of an application platform or code base may
later affect the ability of the business to react in an agile manner to chang-
ing requirements. A decision on the standard programming style that
will be used, such as J2EE or .NET, can affect the options available for
authentication platform or provider selections.
Figure 1.1 presents an example of one such common technology
project—the selection of a new e-mail platform. This need might arise in
response to a consolidation of business units or merger, as a result of new
purchasing mandates, or as a part of a technology modernization effort.
