BRIDGING THE GAP: BUSINESS AND SOFTWARE ARCHITECTURE, PART 1

by Raphael Malveau

Business is business. Software architecture is one of the many, many things that support a business. How important is software architecture to business? One telling perspective is the frequency with which software architecture is mentioned in the annual reports of Fortune 500 corporations. For those who may not get the chance to read very many annual reports, the actual frequency is surprisingly low -- low enough to count on one hand without using any fingers. Could this be a fatal oversight that every major US corporation has overlooked? Not hardly. There is a place for software architecture, however, it is far removed from the boardroom. How far is usually organization- and business-specific, however. An examination of the dynamics of business strategy, technical strategy, and how they interact will illustrate general principles active in most organizations.

This series of articles will help close the gap between software architecture and business concerns. The first article will discuss the divide that exists between business strategy and technical strategy and how they ought to work together in an organization. The second article will discuss a powerful tool in tying business and software concerns together. The third will explain the use of traditional enterprise architecture tools and techniques in a productive and effective manner in the corporate environment. The fourth article will provide a method of quantifying the effects of software architectural decisions on the business. The fifth and final article will discuss additional benefits of this approach.

Business Strategy

The executives of a company are responsible for making strategic decisions about the company's growth, production levels, and targeted markets. These decisions are supported by high-level business plans that include company objectives and metrics that become targets for other parts of the organization. An important part of the decisionmaking process is the recognition and ability to capitalize on opportunities. Opportunities are often tough to recognize and are maddeningly short on duration but represent the greatest potential for corporate gain.

Now here is the simple truth that IT professionals may find difficult. These crucial high-level business decisions should not be constrained by technical concerns. There is a place in business for technical input; however, it is not on the strategic business decision- and deal-making front lines. On the front lines, business strategists create the challenges that may be addressed by technical solutions but they are not created out of technology needs nor the concerns of an organization's technical staff. It is a sincere hope that people realize that business strategy is outwardly focused on customers (incoming money), markets (incoming money), and business relationships (incoming money), and not on networks (outgoing money), tools (outgoing money), and equipment (outgoing money). First and foremost, business concerns drive the enterprise.

Technical Strategy

Now that the business strategic planning meeting has wrapped up, it is time to implement the business objectives. The role of the technical staff is to ensure that the enterprise is positioned to support the needs of the business. The technical staff will need to work with members of the business staff to translate growth targets and anticipated production levels into specific technical challenges of capacity planning, improved automation, and product support. The IT group takes the "what" detailed in the business strategy and subsequent meetings, translates it into the "how," and produces alternatives for "how much," "how long," and "how impacted." Together with some input from the business strategist, IT groups collaborate and decide on the IT plan that the technical groups are charged to implement.

For example, if the business strategists direct the IT group to cut costs, the IT group should not unilaterally take steps to reduce its operating costs in ways that could constrain future business choices. Rather, the IT group should do some investigation and research and come back with a number of alternatives to cut costs, an explanation of the implications of the alternatives and discuss how the current business strategy as a whole will be affected. This will keep the cost- cutting decisions from appearing as a choice of the IT group rather than as a business decision that has impact on the organization as a whole. By presenting IT decisions in business terms, it eliminates the requirement that business decisionmakers need also become technologists and puts the burden on understanding the implications of technology on the business squarely on the IT group that is best equipped to make the determination.

The next Advisor in this series will discuss a key tool in bridging the gap between business and technical concerns in an organization.

-- Raphael Malveau