System Transformation Portal

By William Ulrich

IT architectures continue to grow in sophistication and complexity. The diversity of development and management platforms, standards and technologies creates challenging decision and implementation scenarios for the most sophisticated IT organization. Efficient and effective selection, deployment and integration of IT architectures requires an IT architecture team.

The term "IT architecture" means many things to many people. IT architecture can be divided into two major categories. A technology architecture defines the operating environments, standards and software products, along with the roles and relationships among those environments and products, within your IT environment. An information architecture on the other hand defines how application and business functionality and data is distributed and integrated across this technical architecture.

Because these architectural sub-categories are highly interdependent, architecture deployment and management must be highly coordinated. In the absence of this type of coordination, individual technology teams, business units and application areas will be left on their own to stumble through a series of trial and error technology selection and abandonment scenarios. While lost productivity, wasted resources and misuse of funds are enough to justify an architecture team, cross-functional coordination presents an even a stronger case for such a team.

The uncoordinated propagation of technologies, applications and data creates an environment that stymies cross-functional integration � an essential component in virtually every e-busines and business-to-business initiative. If business units wonder why systems cannot communicate, why user requests take so long and why Web-based applications cannot communicate with legacy systems � the answer lies in poorly coordinated technical and information architectures.

Achieving architectural "synergy" can be accomplished by creating an empowered architecture team. This team should be comprised of IT area leaders, representatives from each major business unit and third parties where appropriate. If, for example, application service providers or outsourcing firms are essential to the delivery of information services, they should be on the architecture team.

Initially, this team should meet to define a common purpose and set of guiding operating principles. A purpose should not be confused with a platitude-laden mission statement. For example, an architecture team�s purpose may be to "Create an environment where all business applications, data and users can readily and effectively communicate with related applications, data and users." Such a purpose embodies the needs and desires of all relevant and affected parties.

Operating principles define how architecture team participants will act in pursuit of the team�s purpose. A principle may state, for example, that "Technologies counter to the architecture team�s recommendations can be adopted if they do not run counter to the architecture team�s purpose." Principles provide a degree of latitude for participants because they describe an end result and never tell people how to do their jobs.

Creating and deploying an architecture team will likely meet political resistance. If the team has proper representation, a commonly shared and accepted purpose, and a clear set of operating principles, the odds of their success will increase dramatically. Considering the importance of IT architectures, it is worth the effort to form a team that can fulfill these requirements.