97 Things Every Software Architect Should Know

Chapter 30. Understand the Business Domain

Mark Richards is a director and senior solutions architect at Collaborative Consulting, LLC, where he is involved in the architecture and design of large-scale service-oriented architectures in J2EE and other technologies, primarily in the financial services industry. He has been involved in the software industry since 1984, and has significant experience in J2EE architecture and development, object-oriented design and development, and systems integration.

—Mark Richards

EFFECTIVE SOFTWARE ARCHITECTS understand not only technology but also the business domain of a problem space. Without business domain knowledge, it is difficult to understand the business problem, goals, and requirements, and therefore difficult to design an effective architecture to meet the requirements of the business.

It is the role of the software architect to understand the business problem, business goals, and business requirements and translate those requirements into a technical architecture solution capable of meeting them. Knowing the business domain helps an architect decide which patterns to apply, how to plan for future extensibility, and how to prepare for ongoing industry trends. For example, some business domains (e.g., insurance) lend themselves well to a service-oriented architecture approach where as other business domains (e.g., financial markets) lend themselves ...