Understand the Business Domain



Understand the Business Domain

Mark Richards

EFFECTivE SoFTWARE ARCHiTECTS understand not only technology but also the business domain of a problem space. Without business domain knowl- edge, it is difficult to understand the business problem, goals, and require- ments, 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 more toward a workflow-based architec- ture approach. Knowing the domain helps you decide which architecture pat- tern may work best to satisfy the specific needs of the organization.

Knowing the industry trends of a specific domain can also help a software architect in designing an effective architecture. For example, in the insurance domain, there is an increasing trend toward “on-demand” auto insurance, where you only pay for auto insurance when you actually drive your car. This type of insurance is great if you park your car at the airport on Monday morn- ing, fly off to your work destination, and return Friday to drive back home.



Understanding such industry trends enables you as a software architect to plan for these trends in the architecture, even if the company you are working with hasn’t planned for them yet as part of its business model.

Understanding the specific goals of the business also helps you design an effec- tive architecture. For example, do the goals of the particular business you are working for include non-organic growth through heavy mergers and acqui- sitions?

The answer to this question may influence the type of architecture you design. If the answer is yes, the architecture might include many layers of abstraction to facilitate the merging of business components. If the goals of the business include increased market share through a heavy online presence, then high availability is most likely going to be a very important attribute. As a software architect, always understand the goals of the company you are work- ing with, and validate that the architecture can support these goals.

The most successful architects I know are those who have broad hands-on technical knowledge coupled with a strong knowledge of a particular domain. These software architects are able to communicate with C-level executives and business users using the domain language that these folks know and understand. This in turn creates a strong level of confidence that the software architect knows what he or she is doing. Knowing the business domain allows a software archi- tect to better understand the problems, issues, goals, data, and processes, all of which are key factors when designing an effective enterprise architecture.

Author bio available on page 11.

Collective Wisdom from the Experts 61





Programming.Is. an.Act.of.Design Einar Landre

KRiSTEn nygAARd, FATHER oF oBjECT-oRiEnTEd pRogRAMMing and the Simula programming language, used to say programming is learning. Accepting the fact that programming—or more precisely, software develop- ment—is a processes of discovery and learning, not a process of engineer- ing and construction, is fundamental to bringing software practices forward. Applying the concepts of traditional engineering and construction on software development does not work. The problems have been documented and com- mented upon by leading software thinkers for more than 30 years. As an exam- ple, in 1987 Fredric Brooks, Jr., stated in the “Report of the Defense Science Board Task Force on Military Software” that the document-driven, specify- then-build approach lies at the heart of many software problems.

So where should the software industry look to improve its practices? What about the industries involved in production of sophisticated mass-market products such as cars, pharmaceutical drugs, or semiconductors?

Let’s take a look at the car industry. When planning a new model, the first thing is to choose a concept or archetype. It’s primarily an architectural positioning mechanism. The BMW X6 is an example of a new concept that combines the properties of an SUV and a coupe into what BMW calls a sports activity coupe. Before you can purchase a new X6, BMW has invested thousands of hours and millions of dollars in both its vehicle and manufacturing design. When BMW receives your order, one of its assembly lines will kick in and produce your customized version of the X6.