Decisions Required vs. Decisions Made: Connecting Enterprise Architects and Solution Architects via Guidance Models

Introduction

A key objective of enterprise architects is to align the existing and the future IT systems with the business model and the strategic direction of an enterprise. Architecture frameworks support enterprise architects when they inventory the existing (as-is) and when they specify the future (to-be) architecture landscapes; they also help them to establish governance processes and architectural principles. However, solution architects that work on specific implementation projects expect mature frameworks not only to express such fundamental design constraints, but also to provide concrete and tangible guidance how to comply with framework building blocks, processes, and principles. In other words, a route planner is needed in addition to maps of destinations.

In practice, we have come across the following collaboration issues between enterprise architects and solution architects that call for such a route planner:

• 1.

  Availability Issues: Experienced, knowledgeable enterprise architects have been appointed, who managed to define to-be architectures and to release enterprise-wide architectural principles. However, they did not find the time yet to author additional documentation how to adhere to these principles and they are slow to respond to requests for reviews and/or project participation. Consequently, the enterprise architecture artifacts are ignored by projects teams or, even worse, “pseudo-compliance” is declared at an early stage, but never really strived for and, consequently, never actually reached.

• 2.

  Consumability Issues: To-be architectures and/or architectural principles are documented, but difficult to understand and to relate to design concerns on projects. Such issues are often caused by inadequate levels of abstraction and detail: if specified on rather high levels, enterprise architecture artifacts run the risk of being perceived to be full of obvious truisms and/or trivial; on the contrary, rather detailed specifications take a long time to create, comprehend, and maintain; they might also be impossible to implement under economic constraints.

• 3.

  Enforcement and Acceptance Issues: Workable enterprise architecture guidelines are in place, as well as a governance process. However, the guidelines established by the enterprise architects (for the benefit of the whole enterprise) are not followed properly because project teams do not fully appreciate their value; due to their narrower design scope, they view these guidelines as unwelcome additional design constraints. In practice, we also observed that solution architectures often pass formal quality reviews with certain obligations; e.g., architectural smells are reported and refactorings are suggested to reduce technical debt (Brown, Nord, & Ozkaya, 2011). However, such obligations are not always followed up upon. In such settings, solution architects can expect to “get away” with violations of architectural principles, which typically are justified by short term business priorities and stakeholder pressure.

These issues are further complicated when third parties such as external consulting firms and outsourcing providers with different goals and concerns get involved; this is often the case in practice today.

Examples of architecture design issues that often require the attention of enterprise architects are: