Contribution 34 - Revision history

Rmonson at 19:07, 13 July 2008

Rmonson — Sun, 13 Jul 2008 19:07:53 GMT

←Older revision		Revision as of 19:07, 13 July 2008
Line 7:		Line 7:
	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 towards "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 morning, fly off to your work destination, and return Friday to drive back home. Understanding such industry trends enable 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 their business model.		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 towards "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 morning, fly off to your work destination, and return Friday to drive back home. Understanding such industry trends enable 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 their business model.

-	Understanding the specific goals of the business also helps you design an effective architecture. For example, do the goals of the particular business you are working for include non-organic growth through heavy mergers and acquisitions? The answer to this question may ~~heavily~~ 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 working with, and validate that the architecture can support these goals.	+	Understanding the specific goals of the business also helps you design an effective architecture. For example, do the goals of the particular business you are working for include non-organic growth through heavy mergers and acquisitions? 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 working 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 architect to better understand the problems, issues, goals, data, and processes, which are all key factors when designing an effective enterprise architecture.		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 architect to better understand the problems, issues, goals, data, and processes, which are all key factors when designing an effective enterprise architecture.

-	(RMH Edited 7/2/2008)	+	(RMH Edited 7/13/2008)

	By [[Mark Richards]]		By [[Mark Richards]]

Rmonson at 20:57, 2 July 2008

Rmonson — Wed, 02 Jul 2008 20:57:12 GMT

←Older revision		Revision as of 20:57, 2 July 2008
Line 1:		Line 1:
	== Understand The Business Domain ==		== Understand The Business Domain ==

-	To be a software architect you have to have a good deal of technical knowledge in a variety of platforms and technologies. However, having a great deal of technical knowledge is only one piece of the puzzle. The other piece of the puzzle is having a good deal of knowledge about the business domain you are working in. Effective software architects understand both the technology solutions that are applicable to the problem space as well as the business domain. 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.	+	Effective software architects understand both the technology solutions that are applicable to the problem space as well as the business domain. 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 those requirements. 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 towards a workflow-based architecture approach. Knowing the domain helps you decide which architecture pattern may work best to satisfy the specific needs of the organization.		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 those requirements. 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 towards a workflow-based architecture approach. Knowing the domain helps you decide which architecture pattern may work best to satisfy the specific needs of the organization.
Line 10:		Line 10:

	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 architect to better understand the problems, issues, goals, data, and processes, which are all key factors when designing an effective enterprise architecture.		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 architect to better understand the problems, issues, goals, data, and processes, which are all key factors when designing an effective enterprise architecture.
		+
		+	(RMH Edited 7/2/2008)

	By [[Mark Richards]]		By [[Mark Richards]]

Wmr513: /* Understand The Business */

Wmr513 — Fri, 06 Jun 2008 22:46:34 GMT

Understand The Business

←Older revision		Revision as of 22:46, 6 June 2008
Line 1:		Line 1:
-	== Understand The Business ==	+	== Understand The Business Domain ==

	To be a software architect you have to have a good deal of technical knowledge in a variety of platforms and technologies. However, having a great deal of technical knowledge is only one piece of the puzzle. The other piece of the puzzle is having a good deal of knowledge about the business domain you are working in. Effective software architects understand both the technology solutions that are applicable to the problem space as well as the business domain. 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.		To be a software architect you have to have a good deal of technical knowledge in a variety of platforms and technologies. However, having a great deal of technical knowledge is only one piece of the puzzle. The other piece of the puzzle is having a good deal of knowledge about the business domain you are working in. Effective software architects understand both the technology solutions that are applicable to the problem space as well as the business domain. 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.

Wmr513: /* Understand The Business */

Wmr513 — Thu, 29 May 2008 20:37:31 GMT

Understand The Business

←Older revision		Revision as of 20:37, 29 May 2008
Line 9:		Line 9:
	Understanding the specific goals of the business also helps you design an effective architecture. For example, do the goals of the particular business you are working for include non-organic growth through heavy mergers and acquisitions? The answer to this question may heavily 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 working with, and validate that the architecture can support these goals.		Understanding the specific goals of the business also helps you design an effective architecture. For example, do the goals of the particular business you are working for include non-organic growth through heavy mergers and acquisitions? The answer to this question may heavily 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 working 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 architect to better understand the problems, issues, goals, data, and processes, which are all key to designing an effective enterprise architecture.	+	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 architect to better understand the problems, issues, goals, data, and processes, which are all key factors when designing an effective enterprise architecture.

	By [[Mark Richards]]		By [[Mark Richards]]

Wmr513: New page: == Understand The Business == To be a software architect you have to have a good deal of technical knowledge in a variety of platforms and technologies. However, having a great deal of te...

Wmr513 — Thu, 29 May 2008 20:35:42 GMT

New page: == Understand The Business == To be a software architect you have to have a good deal of technical knowledge in a variety of platforms and technologies. However, having a great deal of te...

New page

== Understand The Business ==

To be a software architect you have to have a good deal of technical knowledge in a variety of platforms and technologies. However, having a great deal of technical knowledge is only one piece of the puzzle. The other piece of the puzzle is having a good deal of knowledge about the business domain you are working in. Effective software architects understand both the technology solutions that are applicable to the problem space as well as the business domain. 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 those requirements. 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 towards a workflow-based architecture approach. Knowing the domain helps you decide which architecture pattern 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 towards "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 morning, fly off to your work destination, and return Friday to drive back home. Understanding such industry trends enable 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 their business model.

Understanding the specific goals of the business also helps you design an effective architecture. For example, do the goals of the particular business you are working for include non-organic growth through heavy mergers and acquisitions? The answer to this question may heavily 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 working 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 architect to better understand the problems, issues, goals, data, and processes, which are all key to designing an effective enterprise architecture.

By [[Mark Richards]]

This work is licensed under a
[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]

Back to [[97 Things Every Software Architect Should Know]] home page