The Role of Web Services in Enterprise Architecture
Web services make or break an enterprise architecture.
by Peter Varhol
February 23, 2007
As large organizations find increasing difficulty in merging many complex, mission-critical software systems into their established and evolving computing infrastructures, the role of the enterprise architect becomes more important. The growing depending on software means that everything supporting the software also has to work right, both now and in the future.
The enterprise architect ensures that these applications, and their associated data, are ready to serve the needs of the organization. This is a broad mandate. It can potentially include infrastructure such as networks and telecommunications, servers and operating systems, packaged applications, and application development and deployment strategies.
Web services and their associated services-oriented architecture (SOA) are tools use entirely as a software strategy, or more correctly, an enterprise application strategy. This strategy assumes that common and repeatable logic elements exist across enterprise applications, and they can be compartmentalized, coded, and packaged as services. Creating services makes it possible to more easily update and enhance applications, and mix and match services for rapid production of new applications, built in response to new business requirements.
The Role of the Enterprise Architect
What ties enterprise architecture (EA) and Web services together? Web services are a set of building blocks for the enterprise architect. These blocks can be assembled in response to business needs. The enterprise architect doesn't typically build but determines what kind of blocks are produced and maintained. If the enterprise architect can design a set of blocks that meet future application needs, then the business can respond more quickly and completely to opportunities and changes in business conditions.
The enterprise architect also has to make sure that the overall IT infrastructure matches the future needs of the enterprise. The IT infrastructure encompasses Web services, along with communications, systems, and an operating platform. Completing this task requires a rare combination of common sense, foresight, planning, research, and sometimes a bit of luck.
Take, for example, a government construction project at Oak Ridge National Laboratory many years ago. A contractor designed and constructed a building to house a new wind tunnel, which was being built simultaneously by another contractor. While the completed building was large enough in surface area to house the machinery, it became clear when the wind tunnel arrived that the contractor had not allowed a way for workers to move the bulky tunnel into the new building. Because of this oversight on the part of the contractor, the building had to be demolished, and a new one was built in its place.
This example illustrates the obstacles and opportunities faced by the enterprise architect. The enterprise architect is first and foremost responsible for keeping applications and databases running efficiently on a day-to-day basis. Certainly much of the actual effort falls to the IT support staff, but the enterprise architect is continually involved in decisions and actions to maintain working software and systems.
The enterprise architect's least visible, but perhaps most important, responsibility is to ensure that applications needed several years down the road can run efficiently and help the business keep up with the changing market. The enterprise architect is most likely to take the blame if an opportunity today is precluded by decisions made years ago.
The enterprise architect has a difficult, and sometimes thankless, job. If the right decisions are made and implemented properly today, then in three years time every new application and server will work at an optimum level, and the business will be able to easily adapt to changing opportunities.
On the other hand, if the wrong decisions are made today, then they can manifest themselves in expensive projects, difficult to change systems, and a high-failure rate on implementations in the future. It may not be clear that past decisions surrounding the EA are to blame, but it is clear that moving forward will be increasingly difficult. An organization in this position must rip out large parts of its computing infrastructure and replace networks, systems, and platforms in order to implement a specific application set or workflow.
Implementing Web Services
The enterprise architect plays the role of a matchmaker, choosing among many different infrastructure designs, and many different kinds of applications that can use these infrastructures. Most of these infrastructures and applications have been proven in practice. But not all combinations of infrastructures and applications are a match. To use an extreme example, you don't want a videoconferencing application running on 10 mbps of enterprise Ethernet backbone. If that videoconferencing application is mission-critical, then the business will not be able to respond effectively when the application is required.
Back to top