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.
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.
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.
In order for a technical team to be successful, it must be aware of the organization's business strategy. Ideally, both business and technical staff are working off the same piece of paper to reduce difficulties introduced due to differing interpretations. Conversely, business people need to be informed about the technical strategy. They need to verify that plans and projects exist to support expected growth and corporate direction. Equally important, business staff should know the implications of cost-cutting decisions on the ability to support future growth.
The development and use of an organization's enterprise architecture is key to bridging the communication gap between the business strategy level that needs information for strategic planning and the technical level that needs to continually develop tactics to keep an organization functioning and support new and continuously changing directives. The use of the term enterprise architecture is taken from the US federal government work in the past several years [1, 2, 3], which has been mostly derived from the Zachman Framework first published in 1987 in the IBM Systems Journal article "A Framework for Information Systems Architecture" [4].
The purpose of the enterprise architecture is to provide a high-level view of an enterprise that is understood by everyone in an organization and that both enables stakeholders to drill down and obtain increasingly detailed information to support decisionmaking processes and for designers and implementors of specific system components to align their efforts with the business processes documented in the planner and owner levels of the enterprise architecture.
An enterprise architecture is a set of documents designed to communicate how IT components fit together to satisfy the higher- level business objectives. Attempts to develop enterprise methodologies have ranged from documenting every aspect of organizations and systems in extreme detail to providing simple, generic models of system components across entire classes of systems. The primary lesson learned from efforts to date is that any enterprise architecture needs to be tailored toward the audience that will use it for business decisionmaking. In retrospect, this makes excellent sense because the decisionmakers are making the investment in the system and need ongoing education into the alternatives, risks, and tradeoffs involved in how they make such decisions. Without either an enterprise architecture to communicate this information in terms others can understand or the people affected by their decisions, decisionmakers are forced to rely on blind faith in their IT staff or risk undermining efforts that may already be aligned to aid in accomplishing their business goals.
Natural languages such as English are adequate for planning discussions and setting high-level priorities. However, because natural languages are imprecise and can be interpreted in multiple ways, lower-level models and shared design artifacts require more specialized notations. While a detailed discussion of the contents of a database would drive most of the non-technical members of an organization from the room in the first hour, defining the various data types, expected field lengths, and semantic meanings of the fields and relationships is absolutely essential for understanding how data is manipulated and potentially shared throughout the enterprise. The key in making an enterprise architecture valuable throughout the enterprise is not to provide detailed information that can be viewed from a higher level, but rather to make the contents of the lower levels of an enterprise architecture understandable to decisionmakers and link to the more detailed descriptions that are needed to actually specify and build the needed software components. Typically, this requires ample high-level synopses of system and technology components. Fortunately, such information is likely to change far less frequently than the underlying specifications and details used by the design and development teams.
The enterprise architecture defines the roadmap and how the various models at different levels of the enterprise are related. This description needs to be understandable across the enterprise, even if the individual models themselves have a more limited audience. A balance needs to be struck in developing artifacts that can simultaneously be used to provide technical information to business users and enough information to derive consistent technical guidance for development teams. An immediate benefit from having an enterprise architecture is that it allows everyone within an organization to communicate using a common set of documents. This provides an organizational alignment and allows everyone at different levels of the organization to understand the impact of both IT decisions and investments.
For example, if a business group needed management information reports from different lines of business, then it should be possible to use the enterprise architecture to trace through what business areas generate the required data and what IT systems are impacted and to perform a quick assessment of where additional analysis would be required to produce a feasibility study. Furthermore, if a project is scoped out and approved, the technical people can use the same enterprise architecture as a starting point for their high-level design. Having the same information available as input into business decisionmaking and technical analysis increases the chance for project success [5].
An organization will use the enterprise architecture process to generate a baseline architecture describing the current system environment, a target architecture defining the environment desired within a specified timeframe, and a sequencing plan for moving from the baseline environment to the target environment. The process is continuous with both the baseline and target environments being updated to account for successful implementation of steps in the sequencing plan and changes in target environment based on both organizational and external changes in the IT industry [6].
An important step in developing an enterprise architecture is obtaining and documenting the current business environment. Some organizations may already have this. Others may have slanted their business plans and strategy documents for external marketing or financial purposes. The business-level components in an enterprise architecture are for the organization's internal use and work may be needed to make the organization's plan and strategy more complete and actionable. One bit of caution in documenting the enterprise achitecture: it would be a mistake to adopt a "bottom-up" approach, placing pre-existing technical artifacts into an enterprise architecture before obtaining a shared understanding with business users as to how they are linked to strategic business objectives. When technical artifacts are included in the enterprise architecture, they should be targeted to the business users. This does not mean that the more technical documentation customized for system designers, coders, and testers should not exist elsewhere in the organization. It does, however, mean that some effort is needed to package and convey essential information in a manner that is suitable for presentation to a non-technical audience.
Once an organization has an enterprise architecture, its IT decisionmaking processes must be changed to make use of the additional information it provides. Business decisionmakers are expected to use the EA to guide and ultimately constrain their business decisions. Typically, this transformation occurs from having the IT group being well equipped to discuss the impact of business directives on the technical environment (see "Bridging the Gap: Business and Software Architecture, Part 1," 13 January 2004). The enterprise architecture becomes the common language where business decisions can follow the impact of business strategy changes on the business processes down through to the systems that support the business processes. Now the alternatives can be discussed, not in terms of changes to the technical infrastructure, but in terms of how an alternative will impact other business processes and future alternatives. With an enterprise architecture, information is available to identify redundacies, trace impacts, and align alternative solutions in a manner comprehensive to both business and technical stakeholders.
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.
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.
Like everything else in the IT industry, the "devil is in the details." At least by using enterprise architecture as a shared point of discussion between business and technical parts of an organization, efforts can be directed at the detailed level in a way to achieve meaningful results. For example, when technical staff need to justify why a particular infrastructure component or set of features is needed, they can present the preferred choice as the best alternative based on the current business strategy. The recommendation must be based on a thorough understanding of the business as well as technical risks. For example, the need to invest in a content management application to facilitate the maintenance of an organization's Web pages should not be presented in purely technical terms of more process improvement and more efficient document creation. Rather, it should be targeted to the business sections of the enterprise architecture and presented in terms of supporting existing business growth plans and the need to support partnerships by using XML and Web services to automate business processes across organizations.
In most organizations with experienced management, it is not difficult to convince businesspeople of the importance of software architecture, especially when placed in terms of investment and risk mitigation. However, while architecture is always important, it is not always affordable. The technical staff needs to be reminded that software architecture always has a cost and the business goals may sometimes require that software architectural improvements take a back seat to other investments of corporate resources.
When are standards important? They are important when business plans discuss access to new customers, new suppliers, new partnerships, and so on. Then, the likelihood of the technical people proposing standards as part of an alternative to meet business needs should increase. Standards should never be introduced for their own sake. Rather, they need to provide a coherent business benefit and be based on future growth plans and eventual business benefit. The benefit might not always be quantified in terms of dollars and cents, but it still should have a definable value.
As the industry continues to move toward maturity, the technical staff will need to be aware of more than short-term technology issues in order to provide significant value to the business units that they support. There will be an increasing need for the technical staff to understand how the business operates and the interconnections between the business, its customers, its suppliers, and other partners in order to properly gauge the risk and value IT brings to an organization on projects both large and small. The enterprise architecture will be a key tool in serving as a shared repository for this knowledge and as a common information base for discussing the linkage and alignment of IT concerns to the processes supporting the business -- both currently and in the future. By failing to embrace the current direction of the IT industry in this regard, technical staff put themselves at risk of not being recognized for the business value their IT projects add to an organization and of potentially devoting resources to areas not aligned with the overall business direction set by the corporate leaders.
The bad news of this series is that all of the technical staff now realize that they are not solely responsible for the business and retreat back to their cubicles. However, if the message has been properly received, they will take with them the corporate business plans and enterprise architecture documentation. Rather than scoff at the lack of technical knowledge possessed by their pointy-haired executive management, they will learn the language of the enterprise and work on presenting their technical solutions in terms of achieving business objectives or mitigating business risk. With luck, the ensuing dialogue will lead to a far richer organization and greater overall success, something that everyone in the organization can agree on.
1. CIO Council, Federal Enterprise Architecture Framework, version 1.1, September 1999.
2. CIO Council, A Practical Guide to Federal Enterprise Architecture, Vol. 1.1, February 2001.
3. Federal Enterprise Architecture Program Management Office, "The Business Reference Model version 2.0: A Foundation for Government-wide Improvement," June 2003.
4. Zachman, J.A., "The Framework for Information Systems Architecture", IBM Systems Journal, Vol. 26(3), 1987 (see http://www.zifa.com/framework.html).
5. Malveau, Raphael and Thomas Mowbray, Software Architect Bootcamp, 2nd edition, pp. 24-25.
6. CIO Council, A Practical Guide to Federal Enterprise Architecture, Vol 1.1, February 2001.