Solution Architecture
The term "solution architecture" is used to describe the process of developing, documenting, and reviewing with relevant stakeholders a multi-dimensional architecture construct that enables a specific business or operational outcome. The target architecture that enables this outcome is defined within the context of all impacted and applicable architecture domains such as business, data, application, technology, integration, security, etc. A solution architecture document will elaborate and further decompose the target architecture into architecture deliverables for each architecture domain. For example, the solution architecture for a loan application digital channel at a fictional bank to allow bank’s customers to apply for a loan online will require an impact assessment of each architecture domain. Each domain will address the needs and concerns of the impacted stakeholders who are bound by that domain such as business, technology, operational, risk, legal, etc…
Let’s try to segregate some of these concerns into specific architecture domains:
- Business Architecture: How does a customer apply for a loan online?
- Data Architecture: What information is needed to enable loan risk assessment and processing? How to manage customer info with maximum security, integrity and optimal cost, performance, reliability, consistency?
- Application Architecture: What UX, process management, and functional system components/services are needed to enable customer loan application via mobile and web devices?
- Integration Architecture: How will the distributed application component and services talk to each other?
- Security Architecture: How to properly verify and authenticate customer identity? How to ensure that customer data is secure in a distributed environment? How to prevent unauthorized data access and data theft over the wire?
- Technology Architecture: How to configure supporting infrastructure for high availability and recoverability in case of system or facility failure?
- DevOps Architecture: How to enable rapid product delivery and continuous maintenance?
The solution architecture that best addresses these concerns will be derived by applying a formal architecture development process and incorporating established organization’s architecture principles and reference architecture in order to define the most optimal technology solution that delivers the desired business outcome. The solution architecture must be well documented and presented to the project and architecture review boards to ensure that it satisfies the project constraints and technology standards established by the enterprise/chief architect.
The figure above is a sample of a few common solution architecture diagrams for a loan application use case. Please note that the actual solution architecture document will also contain a detail description of each domain target architecture and gaps. Other architecture artifacts such as catalogs and matrices may be used.
Software Architecture
Once the solution architecture is defined, reviewed, and approved, software architecture can now be developed as part of the Design or Architectural Runway SDLC phase. The primary focus of software architecture is to define and document software structure and behavior in order to enable software engineering and delivery based on known functional and non-functional requirements. This is quite different from the goal of solution architecture, which is to define app, data, infra architecture building blocks, dependencies, and address all relevant stakeholders’ concerns. Software architect, usually also a technology SME, will use architecture styles, object oriented analysis and software design patterns to design client and server side software components that implement the web/mobile customer experience (CX), process management, functional and data management application architecture blocks defined in the solution architecture document. As I mentioned, the focus of software architecture is to enable application development and delivery. The software engineering diagrams that I found most useful in my days as a software architect are the domain object model class, service component, sequence, and deployment diagrams.
- Domain Object Model Class Diagram is essential in defining a consistent data format for information management, persistence, and sharing.
- Services Component Diagram breaks down system functional services into self-contained API components that can be implemented as microservices
- Sequence Diagram demonstrates how software modules and distributed components integrate with one another in a context of each use case.
- Deployment Diagram is necessary to demonstrate software deployment on compute and middleware infrastructure in order to engineer a DevOps pipeline, manage software/infrastructure dependencies, and design for performance and failure
No comments:
Post a Comment