Enterprise Solution Architecture

Gartner’s research paper “Enterprise Solution Architecture: An Overview” brings a different and interesting concept. By studying TOGAF we know that enterprise architecture and solution architecture have their own concentration. Enterprise architecture works on a high level and creates architecture building block (ABB), solutions architecture creates solution building block (SBB). ABB is high level and abstractive, ABB is vendor independent, while SBB is an individual solution and a detailed design of a specific solution, SBB is vendor specific.

Enterprise architecture is to create solution space, create an architecture to guide a detailed solution design. As an enterprise architect I have created several solution space or enterprise architecture. Our job is to gather business requirements, working together from data, application and technology perspective to create an architecture to address business concerns and needs. Output of our work is to produce architecture definition documents (ADD), a blueprint and transformation road map. We continue to work with solution architects to design a detailed solution. The output of solution architecture is to create solution definition document (SDD). SDD includes a detailed description of the solution, implementation and operation details as well. As pointed out by Gartner “A solution is an implemented system that solves a business problem. A solution is much more than any application software it may incorporate: It includes infrastructure, people and any other aspects necessary for a business problem to be solved. A solution is delivered to the enterprise, and then altered, upgraded or retired through change projects. Each solution has its own separate solution architecture — that is, the description of how it is built and the capabilities it provides.”

Now it comes an Enterprise Solution Architecture. This concept addresses concerns what Gartner described as key findings in the article.

·       Many EA teams struggle to define the relationship of their EA deliverables and guidance to individual solutions and solution delivery projects, as well as portfolio management.

·       ESA provides that link, yet this is typically the least understood and least mature aspect of EA.

·       EA must provide or directly support project-centric solution architecture work.

“An ESA describes how all the separate EA viewpoints come together or are integrated into implemented systems or solutions. It includes each individual solution architecture, separately defined. The ESA defines how different views are leveraged within each individual solution and within whole sets or portfolios of solutions. It also includes repeatable rules for how to implement solutions in more repeatable or reusable ways — such as solution patterns, which leverage patterns and other models within separate viewpoints.”

ESA is composed of requirements, principles and models, but in the case of the ESA, these artifacts guide enterprise architects and solution architects in composing and reconciling the artifacts found in the independently developed viewpoints.

Often time different domains within enterprise architecture organization work on their own architecture and look at their own viewpoint, different architecture work are not truly integrated and linked. More or less each architecture or solution space is to address an individual business problem rather to address business challenge as a whole, some sort of separation and isolation exist within EA domains. ESA concept is useful to consolidate and unify architecture definition from different architecture domains to create an integrated and reusable architecture for the organization.