What is Solution Architecture?
The most widely accepted definition of solution architecture comes from work done by the Software Architecture group of the Software Engineering Institute (SEI) at Carnegie-Mellon University in Pittsburgh:
An architectural element (or just element) is a fundamental piece from which a system can be considered to be constructed. It is often referred to as components or modules. The nature of an architectural element depends very much on the type of system and the context you are considering. Programming libraries, subsystems, deployable software units (e.g., Enterprise Java Beans and Active X controls), hardware components (e.g., firewalls, proxy servers, routers…), reusable software products (e.g., database management systems), or entire applications may form architectural elements in an information system, depending on the system being built. Architectural elements are often known informally as components or modules, but these terms are already widely used with established specific meaning. For this reason, we deliberately use the term element to avoid confusion.
The external visible properties of an architectural element are a set of properties that owned solely by the element and identify the element. Often these properties are expressed as interfaces, contracts, specifications (functional and non-functional) of an element (component or module).
The inter-element relationships indicate how the elements are connected to each other. The most common relationships are expressed as connectivity, dependencies, ownerships, extensions, compositions, aggregations, usages, communications and/or constraints.
Distinct Types of Solution Architecture
There are different flavors within the solution architecture approach, depending on the type of architecture we are describing. We can divide these different types into three different groups as shown in the illustration. Oracle uses a similar approach to architecture by calling these categories perspectives, although they only make the distinction between a technical and an industry perspective.
A technical architecture is an architecture where the concepts and best practices of the architecture are predominantly determined by the technology behind them. Examples of this category are Service Oriented Architectures, Event Driven Architectures, and the like. Industry architectures are the other side of the coin, and are almost completely dominated by how the industry to which they apply is structured. We have for example telecom architectures, financial architectures, public sector architectures, and so on. The final category are the alignment architectures, and these are the architectures that although they still have strong technological ties, they likewise incorporate industry concepts. These are the BPM architectures, the CRM architectures, the ERP architectures…
It is very unlikely that a single architecture type will be able to cover all requirements set out for any solution. Most solutions have several applicable architecture types. In these cases, it is imperative that a hierarchy be made clear between these choices, as indicated in the chapter about design constraints. This way it will become easier later on to decide which best practice to follow, should the best practices of the applicable architecture contradict each other.