BRIDGING THE GAP: BUSINESS AND SOFTWARE ARCHITECTURE, PART 5

by Raphael Malveau

[This is the final installment in a five-part series of Cutter Edge articles on closing the gap between software architecture and business concerns (see "Bridging the Gap: Business and Software Architecture, Parts 1, 2, 3, and 4," 13 January 2004, 3 February 2004, 24 February 2004, and 16 March 2004).]

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.

-- Raphael Malveau