By: Douglas Hubbard
Hot Issue: How does one make a business case for an enterprise architecture (EA) program?
Smart Summary
SmartAdvice
One of the most important objectives of the business case is to inform the EA team which areas of the business case are the highest payoff for the business. The business case can, for example, make a separate valuation by each of the following items or any combination of them:
1. Business Area or Business Function: Some parts of the business will probably benefit more than others from EA.
2. EA Output Type: The value of models for process, data, applications, hardware, etc. are not equal for every area of business. Different levels of detail may be required for each.
3. Level of Detail: Models can be conceptual or highly detailed. The level of detail affects which benefits the EA can claim.
This SmartTip makes recommendations about when to initiate a business case, how to collect some of the data, which benefits should be modeled, and overall recommendations for the approach to business case modeling.
Develop Business Case Based on EA Conceptual Model
A convincing business case will require some input from the EA team. Therefore, you should proceed with the highest-level conceptual model and, as the picture of the organization forms, use that model to inform the business case for further, more detailed analysis in each business area. The high-level EA conceptual modeling will be the least time-intensive for participants, and these meetings can also be used to get input for the business case for more detailed efforts in each area.
Although you will not be able to finish this business case until most of the conceptual modeling is complete, planning for the business case should begin as soon as possible. This will help identify and coordinate information for the business case that needs to be gathered during the conceptual EA development. Some key questions for the business participants at this stage are:
1. What are the major known, upcoming projects in IT in each area? What are the frequency and size of new projects? Since the EA business case must look a few years into the future, major projects it will affect may not even have been formally proposed yet, but will be identified as a candidate project by those in the business area.
2. Is there any obstacle to the adoption of EA as a guide for development? Perhaps adoption of any such standardization initiatives has been historically high or low.
3. Are there resource and time constraints within each business area that may affect the chance of successful completion of the EA in that area? If the EA cannot be completed for a particular business area, it is unlikely it will have any effect and, therefore, unlikely to have any benefit.
4. Are there currently development efforts in a particular business area to retroactively integrate previously developed systems? Since EA should reduce such efforts, this will have bearing on the benefits of EA.
5. Are there completed business cases for proposed systems? This will have bearing on the value of another of the benefits of EA (accelerating the delivery of business systems).
Four Types of EA Benefits
Each of the following items may, at first, seem difficult to estimate. But it is important to remember that everything listed here is a problem or issue that already occurs in an enterprise with some regular frequency. Lacking information to the contrary, past experience is a valid benchmark for each of these quantities.
The benefits of EA fall into four broad categories:
1. Reduced development effort
2. Accelerated delivery times for systems
3. Improved data quality
4. Improved security
Each of these is a result of specific avoided costs (see below) or accelerated benefits. Each of these is expected to be improved by some percentage (probably not 100%) by EA.
Throughout the entire business case, the adoption of EA by the business areas will affect the benefits of EA. Adoption rate is expressed as a percentage where a value of 100% means that the adoption of the EA and all expected benefits will be realized. This is a highly unlikely value and will probably vary across each of the business areas within the EA. Identified benefits are multiplied by the adoption rate for each business area.
This adoption rate will probably also change with time. Ideally, the adoption rate will start out high and, by diligent enforcement of the EA, it will continue to be high. However, it is more likely that adoption rate will decrease over time and that that adoption can only be increased again by another major "EA modernization" initiative (which would be subject to its own business case).
Reduced Development Effort
Organizations that fail to use EA to guide development in multiple concurrent projects (both new and maintenance) will have three sources of additional effort:
- First, such environments tend to spend more time integrating systems that have been developed independently.
- Second, depending on how much project-specific requirements modeling and planning was done previously by IT, there may be a significant increase in defects both at the requirements level and technical level.
- Third, without an EA view, it is likely that separate projects may develop redundant modules and data structures.
For each business area, you can estimate effort spent in integration, fixing defects, and redundant development during the lifecycle of new projects. For each of these, you can then estimate a reduction in effort assuming full use of the EA. These values should be adjusted for adoption rate unique to each business area.
Accelerated Development Effort
Some of the effort reductions listed above would be on critical paths to the delivery of new systems. Time saved on a critical path item not only reduces effort but accelerates the delivery date. For each of the future projects estimate the following items:
- Expected project duration in months
- Estimated reduction in development effort
- Estimated percent of activities on a critical path
- Monthly benefit of the project once implemented
To keep it simple, for each future project, the business case would show a one-time benefit of:
Project duration (months) x effort reduction (%) x critical path (%) x monthly benefit ($/month)
Depending on the benefits of future projects, this benefit could easily be the largest single benefit of EA.
Data Quality
EA should help create consistent data across the enterprise. Multiple occurrences of the same data in different formats, field structures and showing different changes across time (old vs. new versions of data) cause multiple types of recurring problems. Inconsistent data causes one or more of the following problems:
- Redundant entry efforts
- Additional manual efforts to "synchronize" data
- Decision errors caused in key business processes
For each business function the frequency and cost of each of these events can be estimated. Remember, these events are already occurring, so some current observations or historical data can give provide a benchmark. As with other benefits, these are multiplied by an expected reduction of these costs due to the EA and multiplied by an adoption rate.
Improved Security
Virus attacks and unauthorized accesses happen with regular frequency at some level in most organizations. One of the claimed benefits of the ideal EA is that security could be more consistently enforced across the enterprise through better requirements modeling.
TAC SmartGrid
Alignment
Since the benefits of an EA to the business are indirect, the challenge of the business case is to clearly illustrate those benefits in business terms. The approach described here will enable one to do so.
Organization
The greatest challenge to implementing an EA is getting a distributed organization to comply with it. A business case constructed as described here will, at least, demonstrate to the organization the benefits of compliance.
Cost Reduction
As described above, a successfully implemented EA can significantly reduce IT's application development, maintenance and support costs.
Technology
The long-term technical benefits of an EA are well understood by most IT professionals. The trade-off, of course, is with the perceived expediency of non-compliant "throw away" applications which never get thrown away.
SmartActions
Recommended Business Case Approach
1. Even a detailed business case is a much smaller effort than the EA: However, the business case will have a critical impact on the priorities, value realization and acceptance of the EA effort. An EA effort is often large enough to justify a fairly deliberate business case analysis. Keep in mind that this analysis will not just be a formality to maintain support for EA, but can also guide the EA team to focus on the highest payoff areas of the EA. The benefits of EA will likely vary by business area, EA output type (data, process, etc.), and level of detail generated by the EA. The size and duration of the EA effort means that an analysis of benefits, even at this level of detail, is likely to have significant contributions to the prioritization of EA efforts.
2. Use empirical data: As previously stated, each of the costs that EA can reduce are something that has already been occurring in your enterprise. If you can't get historical figures, at least use historical examples to justify subjective estimates.
3. Don't use "scores": Creating "scoring systems" to evaluate each of these is a step in the wrong direction. This refers to any valuation method that depends on someone picking a number on a an arbitrary scale (say, 1-5) for a set of factors, weighting them, then adding them up. There is no scientific, objective evidence that the time IT teams have spent creating scoring methods has improved decisions. There is no measurement problem where you will be better off by attempting to represent it as a score.
4. Consider more quantitative approaches: An EA project is often large enough to justify an effort to measure uncertainty, risk and value in a way that is more like what an actuary or economist would compute. This type of analysis will produce surprising results that would never have been discovered otherwise, and the value of EA could be greatly improved. Plenty of professional resources exist to assist in all the relevant quantitative methods. While the cost of these methods would probably be in the tens of thousands of dollars, the benefits from better EA management and prioritization could be worth many millions. Even if more quantitative methods are used, it will cost less than 1% of the lifetime costs of the EA project itself. The quantitative methods could include:
1. Uncertainty and risk are routinely modeled using Monte Carlo simulations. It will be impossible to know the exact quantities of the benefits but, fortunately, the uncertainty about these can be quantified so that risk can be calculated.
2. Other methods can be used to compute the economic value of information about EA so that measurement efforts are rationally allocated (most managers will choose to spend time on unproductive measurements when not guided by information value calculations).
3. Finally, treat the EA as a portfolio that needs to be optimized. The ideal EA portfolio focuses on the perfect combination of detail by business area. Powerful (in fact, Nobel Prize winning) portfolio optimization methods can be applied, but only if you are fully using the previously mentioned methods for quantifying uncertainty and risk.