The term "architecture group" is a heavily loaded one. I've run into different scenarios at the various clients that have engaged us for consulting on their architecture strategy. In some cases, we have been asked to help seed and grow such a group. In other cases, we've been asked to put together plans to define the organization of an architecture group. And sometimes, we just supplement the existing architecture group.

The SOA and Web services arena is fairly new, and one that warrants the formation of a well defined horizontal group that includes several functions under it. Architecture governance is an area that has always been the charter of architecture bodies in large organizations, but with the advent of SOA, architecture governance has become a much more formalized function. This is because the basic entity of an SOA - the service - has formally defined contracts and service-level agreements (SLA); hence, the formation of the architecture that provides services requires strict practices to ensure that the SLAs are met.

I went through an interesting discussion with a colleague on the nature of an architecture group. One view of the architecture group is that the charter of the group is only to define the architecture and to produce the artifacts that support the architecture definition and usage in the form of best practices, architecture and design patterns, and guidelines. This may also include direction on the approved list of vendor products (and versions) that should be used for application development throughout the organization. Another view of an architecture group is that the charter of the architecture groups includes the development of a reference architecture, common components, and other reusable services that supplement the features provided by the third-party products that make up the reference architecture platform. An architecture group also acts as a consulting body that assists projects through mentoring, review, and sometimes also in the development of the application.

I am a firm believer in the second model. To me, documenting architecture is just a function of the group. Other functions include the development and maintenance of actual components and services that are shared across applications. This allows the group to function more efficiently, provide greater value, and not be perceived as an "elitist" group that is aloof from the application portfolios.

As companies adopt SOA, to succeed in the long run it is imperative for them to create an appropriate architecture group that focuses on the best practices for adopting the various facts of service enablement. Some of the key issues that need to be tackled by the SOA architecture group include adoption of new technologies and products, definition of basic components and services, definition and promotion of SOA standards, setting up of an efficient process for application development, review, governance, and so on. One of the main responsibilities is also to align with the business to define the IT strategy for SOA and to provide an implementation roadmap, including the migration of existing applications towards a service-oriented paradigm. To achieve all of these objectives, the architecture group has to be steeped into the practical aspects through creation of reusable components and collaborative interaction with the application portfolios to march toward a common goal.