1. Setting up architecture team: For example, it is important to have a formal, dedicated architecture team directly reporting to an executive sponsor, even if the team is physically distributed. To ensure efficiency, certain roles should be independent of the outsourcing contractor, such as program managers, investment control, and chief architects / technologists. The enterprise should have knowledgeable professionals on its staff to provide essential checks and balances on outsourced work.
2. Selection of a common / customized EA framework for the distributed team that is matched to the enterprise needs. It may be necessary to have multiple framework profiles to address the needs of complex enterprises, e.g. diverse conglomerate corporations.
3. Identify specific types of artifacts for the framework, and maintain documented modeling conventions. The artifacts should particularly address communications across distributed team boundaries. For example, a richer set of specification types for communicating requirements from onsite business analysts and user interface designers, than for communications within a co-located offshore team. Achieving clear communications is a fundamental challenge in distributed teams.
4. Effectively using modeling languages for architecture specifications. Use of modeling languages such as the OMG UML and BPMN should be the basis for communicating architecture as well as technical designs. New standards such as the Business Motivation Model (BMM), Semantics of Business Vocabulary and Business Rules (SVBR) and the UML 2.0 extensions are available to formalize additional elements of architecture views and specifications.
5. Setting up Architecture Repository. An artifacts should be available via a secure, version controlled, distributed repository. The repository helps assure that the global team has a common view of the project's specifications and is working from the appropriate artifact versions.
6. Architecture Methodology. It is recommended that the EA team review, approve, and standardize the methodology for translating specifications to designs and implementations to avoid loss of information.
7. Realizing MDA & SOA for enterprise & systems. The OMG Model Driven Architecture (MDA) is a guideline defining explicit stages of model translation. MDA defines four stages of elaboration, the Computation Independent Model, Platform Independent Model, Platform Specific Model and code. MDA also defines standards for transforming the models and defining the linkages between the translated forms. For example, Figure shows a distributed EA and implementation project with onsite and offshore model transformations and linkages in an architecture-centric development methodology.
8. Architecture Views & Translation. There is a need to establish well defined transformations between views of the enterprise architecture, the solution architecture and the technical architecture of the system ensuring traceability of architecture constraints and requirements to implementations. EA processes should ensure that each project aligns with the IT vision of the enterprise, adhering to architecture governance guidelines and metrics.
9. Architecture Governance. This is especially important in distributed projects due to increased opportunities for miscommunication and misalignment. Not having architecture governance structure is analogous to system development plan without a testing phase. The governance should apply consistent compliance guidelines for both onsite and offshore activities. Use of techniques based on "metrics" can help ensure that IT systems are in sync with the enterprise architecture and vision.