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. Enterprise Solutions Architecture 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.
There are different kinds of solutions. At least three kinds are increasingly common:
■ Application solutions
■ Service-oriented architecture (SOA) service solutions
■ Shared infrastructure solutions
Over time, most organizations define separate solution portfolio approaches to manage change and investments in each of these types of assets.
In addition to research on technologies and approaches critical to the architecture, there is often a review of patterns that might be useful to the architecture. Patterns are previously described and validated approaches that can be used to create portions of the solution. Patterns are released through research and can come from places such as Microsoft’s software development libraries. Reviewing the pattern allows the architect to refresh their memory on the details of the pattern and to evaluate what additional guidance they will have to provide if they choose to use the pattern. The final component to the role of solution architect is the motivation and guidance of the development leads. Development leaders need to buy into and accept the architecture, to know how the pieces will fit together at a high level. They must also see the art portion of the architecture to get an appreciation of the subtle nuances of their portion of the architecture. It’s the art portion of the architecture that makes it elegant. That elegance helps to maintain cohesion between various parts of the design and encourages simplicity. It is necessary for the lower level design and approach to match the higher-level architecture for the solution to be cohesive. Once the development leader has internalized their portion of the architecture the SA must continuously motivate and reinforce the good work that is being done. They must continue to motivate the Developer Lead(s) to push through tough issues and create the solution.