Solution Architecture is sometimes also referred to as System Architecture or Project Architecture. It differs from Enterprise Architecture both in scope and the level of detail. Generally, Solution Architectures are also more narrowly focused (sometimes on a single system or system component scope) and are usually more detailed in regards to both implementation and configuration. People often view Enterprise Architecture as more strategic and Solution Architecture as more tactical in nature, but in real life this boundary is often blurred.
Solution Architecture is also much less agnostic in nature - in other words, it is more likely that Solution Architecture will contain a great deal of product or specification detail. If we view EA as more Conceptual or Logical in nature - Solution Architecture falls somewhere between Logical and Physical description.
 |
| This illustration represents an example of Solution Architecture... |
Architectures working at the solution level might have to deal with only one major technology (lets say, PeopleSoft, which in itself is somewhat complex) or as many as a dozen. The context of the work is the boundary of the solution. If the solution or project is focused on securing PII customer data the scope may include all the databases that hold such information, an ESB tool for data movement and an identity management suite for authentication and authorization.
There is a wide diversity of opinion in regards to how Solution Architecture should be practiced or scoped. There is also a relative lack of industry guidance as to how organizations ought to align Solution Architecture with Enterprise Architecture. We will explore these issues in greater depth in future posts.
copyright 2014, Stephen Lahanas
#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc
0 comments :
Post a Comment