BRIDGING THE GAP: BUSINESS AND SOFTWARE ARCHITECTURE, PART 4

by Raphael Malveau

In order to understand how software concerns can be quantified to business strategists it helps to have some experience with traditional risk management approaches. Risk management attempts to minimize project or business problems by using a systematic process to make risks visible, assess their probability and impact, and to coordinate and take action to mitigate their potential negative effects. A risk assessment process has procedures in place to identify potential risks, to perform risk analysis in order to determine the probability of a risk occurring, estimating its potential impact or expected cost to the business, and to develop a risk mitigation or contingency plan. A risk mitigation or contingency plan for an identified risk contains proactive approaches to take to either avoid a risk, reduce its impact, or develop procedures for handling a risk if it occurs. Often, the value that software architecture provides is not in a concrete assessment of return on investment or additional business opportunity but in providing an effect within a risk management framework.

Software Architecture -- Business Risk Mitigation

How do you quantify the business value of software architecture? Same as any other risk mitigation factor. The risk is in not being able to adequately support business growth plans and strategic initiatives. The cost of the risk is a combination of not being able to expand plus the price failure may cost in the existing business adjusted by the probability of the risk occurring. For example, if a business that is currently running its customer service operations off of a Microsoft Access database deployed on a LAN at a single site during EST business hours plans an initiative to expand and provide 24/7 customer service across six sites, then IT has to decide how to support this initiative. They could attempt a low-cost, minimal investment in software architecture approach to replicate their single site approach to six locations every morning and have one of the sites reconcile the various databases every evening. If the goal is to survive on minimal expenditures for six months or so, then this could be a barely passable solution.

A moderate approach could be to link together six databases with a client server solution to have each database replicate its changes to the other five databases in near real time. This solution should work well for the planned workload but may need further upgrades if rapid business growth continues.

A third solution would be to provide Web front ends to a centralized database that is replicated at other sites to provide fault tolerance and disaster recovery capabilities. This may be the most expensive development option but it may have lower maintenance costs than the second option and is likely to support future expansion better than the other solutions. In this example, software architecture is an investment in risk mitigation where an organization has to decide whether the costs of not having completely up to date customer service information and not being able to support some future growth scenario is acceptable in order to save on investing in a more architecturally sound IT solution.

In order to quantify the value of software architecture, the technical personnel need a vehicle understandable to the business personnel to convey IT's impact on business growth, plans, and strategic initiative.

From the last two segments of this series ("Bridging the Gap: Business and Software Architecture, Parts 2 and 3," 3 February 2004 and 24 February 2004), it should be obvious that this vehicle is organization's enterprise architecture, since its primary purpose is to bridge the gap between the technical and business groups by providing a common point of communication about the effect on business and IT decisions on the overall enterprise. Even if an architectural change does not have an immediate impact, it is reasonable to expect an explanation of the type of business decisions that could be supported in the future if the change was made in the more immediate term. For example, a tenfold increase in bandwidth and the adoption of a more modern transmission standard may enable the organization to support VOIP or XML-centric solutions going forward that would otherwise be problematic if the current baseline architecture was maintained for the foreseeable future. Without an enterprise architecture, such a suggestion may appear to be purely an IT enhancement since it lacks an immediate business benefit; however, in the large context of the enterprise architecture its long-term value could justify a more immediate investment.

The final article in this series will address some additional benefits of this approach and provide some concluding guidance in combining technical and business concerns.

-- Raphael Malveau