Information Technology Reference
In-Depth Information
Remain Agile and Flexible
Modifying architecture in production is much like trying to change tires
on a moving car or performing brain surgery on oneself. Elements of the
operating network environment, from data stores to authentication and
Web services, may already be operating at or above optimal capacity or
may be tied to divergent technologies that do not integrate well. The lead
architect must be wary of pitfalls such as planning the reallocation of a
database server that also happens to have an active Web-facing reporting
utility, or a Web server that hosts small yet vital resources not identified
in the initial review. Flexibility is necessary when making plans, to ensure
that service disruption is minimized. This must be tempered by formal
project management procedures and a firm change management process
in order to avoid employing too much flexibility.
Maintaining flexibility becomes more complex during long-term
planning operations, as the driving factors change from year to year
as technology and regulatory mandates evolve. While wireless connec-
tivity and mobile communication might remain a hot topic from one
year to the next, issues of security or application development might
swap places in terms of organizational priority as a result of a newly
emergent threat or programming style. Because data and voice-over-IP
(VoIP) telephony compete for the same bandwidth, network infrastruc-
ture upgrades might move ahead of technology modernization projects
to ensure that adequate bandwidth is available before the new and shiny
gear is connected.
Avoid Too Much Good
Enterprise architects perform a constant juggling act to balance expendi-
tures, resources, and requirements. Surprisingly, too much of a good thing
can be as bad as lack of interest. A new SOA-based Web service coupled
to an existing tried-and-true application can rapidly overrun available
capacity and connectivity, if the demand exceeds the throughput of any
element in the chain. New portal deployments often suffer from overly
enthusiastic user interest, because users find sudden need for expanded
access to their whole team or operation as soon as the potential is demon-
strated. Jumping too far, too fast can lead to problems in storage overrun,
load balancing, and service availability. New technology projects should
