Interrelated initiatives that involve enterprise architecture (EA), business process improvement and service-oriented delivery of applications require increased collaboration across organizational roles and technologies.

• To be successful, service-oriented architecture (SOA) and business process management (BPM) initiatives require greater degrees of abstraction using models and sharing metadata, making these initiatives more complex than traditional applications.
• SOA and BPM initiatives also require greater degrees of collaboration across business and IT roles. Although current technologies fall short, new collaborative platforms are on the horizon.

• Establish a strategy for creating a model-driven future solution architecture (FSA).
• Assign the collaborative roles and responsibilities that are needed to deliver the FSA and enhance it as needed.
• Decide on the best way to move forward from the established architecture using collaborative projects that employ model-driven and metadata-driven approaches that are based on the organization's business drivers and level of architectural maturity.

Most organizations that have implemented SOAs have done so to be more agile and responsive to business process improvement changes — a trend that requires more collaboration with the business units. At the same time, business units are implementing BPM methods and tools to further business process improvement initiatives, requiring greater collaboration with enterprise architects, IT architects and analysts, as well as other business units, to implement new cross-organizational, end-to-end processes. Because SOAs and BPM come with increased sharing of services and metadata, as compared with previous approaches, organizations are turning to model-driven methods and tools to understand, reuse and automate the delivery of services and their metadata in a collaborative manner.

Wikipedia defines a model as "a pattern, plan, representation (especially in miniature) or description designed to show the main object or workings of an object, system or concept." Therefore, it should come as no surprise that modeling frequently occurs at abstracted levels of detail, involving managers and architects. Figure 1 depicts a typical top-down set of models that is delivered by enterprise architects working with an organization's executive management.

The deliverable from this modeling process is the enterprise management's business vision and the context into which the rest of the organization must move to support the FSA, while developing the solution architecture. Accomplishing this requires collaboration from enterprise, technology, business, application and data architects, as depicted in Figure 2.

In some organizations, the business context and vision from executive management may come in the form of models, and in other organizations, sparingly, in writing or verbally. Regardless of the form they take, as a best practice, a long-term (perhaps five-year) visionary FSA is needed to help steer the six- to 12-month decisions of architects as they move forward from the application portfolio, business processes and technical architecture. Because a lack of planning results in a default "unplanned architecture," the choice is between making informed versus uninformed architectural decisions.

Organizations can choose to staff all meaningful architecture roles with different job positions and individuals, or they can staff these roles based on size and budget, with multiple roles filled by individuals. For example, the EA team may include one or more solution architects who develop the FSA without other architects involved. In other organizations, there may be no EAs, with technology, application, data and business architects developing the solution architecture as a team — or some hybrid of the two, as illustrated in Figure 2.

There is a nexus in needing to share models, policies, requirements and rules in collaboration among architects across organizational lines to establish the FSA and ensure that plans to enhance the solution architecture are coordinated and supported across architecture boundaries. However, other collaborative roles also exist at the solution architecture nexus.

For example, collaboration with those who are responsible for portfolio management, requirements management and governance, risk and compliance is needed as well.

The nexus includes the interface between the architects and analysts who, as part of development and composition projects, will bring the models from the level of architectural abstraction down to greater levels of detail in analysis, design, implementation, ongoing operations and improvement, as depicted in Figure 3.

Whether involving build, buy or assembly of services and composition of process, SOA and business process improvement projects require the collaboration of more types of roles than at the level of the solution architecture. Several levels of collaboration are required to create an architected solution and to leverage new techniques:

1. Architectural principles and practices — a common understanding of the principles and practices is required across the scope of the solution to ensure that the entire effort is based on a common understanding of the priorities and constraints.
2. Architectural goals and objectives — a common understanding of the business goals is critical to ensuring that all activities in the solution development process are value-added and that they contribute to achieving the goals. Having a shared information set that represents these goals is necessary to manage the development of the solution.
3. Implementation strategy and practices — implementation teams must share information effectively to keep their segments of the project track, to identify and resolve cross-domain issues quickly and efficiently, and to facilitate the creation and use of shared artifacts. A key emerging role in the design of reusable software and data services is that of the application architect or analyst.
4. Developer collaboration — distributed development teams require collaboration resources to enable them to work efficiently. In addition, the added requirement to share assets across domains demands the involvement of the development teams.
5. Enterprise information — information assets and flows of information are at the heart of any SOA system, and collaboration mechanisms are a vital tool in ensuring that the use and value of information is maintained as it is leveraged in the solution.

Gartner has published extensive research on the topic of the evolving nature of model-driven approaches to application development, composition and package purchase.

The ability to share and reuse models and metadata from levels of architectural abstraction down to the operational environment across roles and life cycle phases is a huge advantage in quality, consistency, productivity and agility. However, this sharing requires addressing governance, compliance and risk issues, which many organizations are not prepared to do. In a collaborative environment, where models and metadata are shared, the issues of who "owns" the models and metadata, who can change them and the rights of the nonowners who use them all become paramount for success.

Moreover, for EA, business process improvement and service-oriented development initiatives to be successful, other types of metadata also must be properly governed, and key organizational roles, such as repository administration, are needed. These are beyond the scope of this research.

Although enterprises should have collaborative architects in roles where they can create modeled FSAs, most organizations lack the maturity/sophistication to effectively support this. Most organizations are at a corporate maturity model level of about 1.8 — slightly above using ad hoc methods, but below following formally repeatable standard processes.

Even organizations at advanced levels of architectural maturity should not use robust analysis, design and modeling approaches on all projects. For example, the business may need to "work with" a subset of the total solution before it can provide adequate requirements for analysis. Or, there may be a business opportunity to tactically use a "less than optimal" solution for competitive advantage which might not be possible if a great deal of time is spent in analysis. Therefore, organizations must consider whether to use a robust modeling approach to architectural planning and development, and composition projects based on a variety of factors, including business drivers for cost and time-to-market.

Most organizations buy application packages for commoditized aspects of their business — which should come with models and a customized, model-driven implementation and with maintenance capabilities — and, for other application needs, should evolve their architecture from the bottom up, through agile rapid application development and composition projects.

As indicated in Figure 4, we are in the midst of an evolution in model-driven collaborative technologies.

The "Magic Quadrant for Enterprise Architecture Tools" shows the vendors that support the enterprise business model and high-level aspects of the solution architecture, including the management of models and metadata at that level of abstraction. Not surprisingly, many of these vendors offer business process analysis (BPA) modeling tools — although other vendors focus on the BPA market from a business architect and analysis perspective.

At the same time, most vendors in the BPA tool market have SOA object-oriented analysis and design-modeling tools and/or data-modeling and database design tools that interface or integrate with each other at the solution architecture level and below. Some have bridges to application life cycle management tools, including SOA development tools, system and security management suites, configuration management database suites, database management suites and BPM suites.

As indicated in Figure 4, from 2009 to 2012, we expect to see the evolution of a repository-based collaborative solution architecture platform that brings together all architects to work using shared models and metadata. Users of this platform must be at a comparatively advanced level of maturity. It is unclear whether the solution architecture and EA tools will converge into a single platform, but, initially, we expect an overlap of offerings.

We also expect the evolution of a more guided, self-service, model-driven and metadata-driven application development and composition platform for use by most less-sophisticated organizations and SOA and BPM projects. Examples include IBM's Jazz platform and Microsoft's Oslo platform. Buy and "rent" alternatives, such as model-driven application packages and hosted solutions (some as part of cloud computing), will interface with or be integrated into these platforms, as will the solution architecture platform.

Collaborative solution architecture and development/composition platforms are likely to evolve at incremental rather than breakthrough rates — so organizations must plan for their adoption, along with other aspects of the FSA. However, in using model-driven and metadata-driven approaches to application solutions, the need for collaboration with the current technology remains.