A call for an IT architecture
- By George Brundage
- Mar 01, 2000
Since the early 1980s, information technology managers have witnessed the
spread of chaotic incompatibility among systems scattered throughout agencies.
Managers increasingly have wanted greater control of systems, particularly
when strategic concerns have been negatively affected.
On one hand, IT has given users power, allowing them to enter data and
get better access to the data. And IT and business organizations now share
responsibility for data, applications and technology. On the other hand,
we have encouraged the spread of incompatible databases, applications and
technology. It is no longer a question of whether we have the political
will to correct the situation because action is being forced on us by the
public's increasing expectations for government services.
World Wide Web technology has had an effect on the government's business.
The Web is forcing us to review the link between processes within line and
support functions and to include in those processes our suppliers, partnerships
and customers. It is forcing us to revise processes and systems.
But we are unable to share information, resulting in increased costs.
Without standards and guidelines, agencies will continue to have difficulty
sharing information and providing high-quality data. Our information is
incomplete, and instead of doing something about it, we make excuses. Our
systems often produce contradictory answers to the same questions. As long
as there are multiple sources of data entry, with multiple databases serving
the same goals, there is little hope of solving our quality problems.
Architecture provides a systematic way to prevent inconsistent system
designs and development decisions that result in costly systems that do
not perform as well as they should. Without an architecture, we will continue
to have slow response to change. For example, the Year 2000 computer problem
would have benefited greatly from having a documented architecture. Why
do we keep recreating the wheel, that is, re-engineering our documentation,
whenever we want to change our systems?
An architecture includes explicit and understood terms for communication,
provides an organizing mechanism for collaboration and support for more
effective IT investment planning and decision-making.
If you have ever built an addition onto your home, you know how important
building codes, blueprints and building inspections are to the successful
completion of the project. IT architecture is very similar. An architecture
framework is the building code. The architecture description is similar
to blueprints, and IT governance bodies and procedures are similar to building
inspectors.
Included in the framework must be the data that the architect expects
to receive from all of the project managers. The architect will need this
data to determine architecture alignment. The required data is usually dependent
on the purpose of the architecture. If interoperability at all levels of
the architecture (business, data, applications and technology) is the purpose,
then the architect will want to gather data at the appropriate level of
detail (which will probably result in a lot of data).
However, an architect does not need to know everything. After all, the
architect is not the software developer who will want to go to the lowest
level of detail.
To make an architecture work, there must be a partnership between the
business and IT communities because architecture cannot be a success without
the cooperation of both communities. The business community is just as concerned
about the potential of technology as the IT community. Both communities
should work together to realize the value of technology. The business community
must help the IT community overcome impediments to the effective implementation
of technology.
— Brundage is a senior program analyst at the General Services Administration's
Emerging IT Policies Division and chairman of GSA's ArchitecturePlus program.