Business-IT Alignment: Time for a Paradigm Shift

by Fred Cummins on 02-18-2009 11:30 AM

The vision of business-IT alignment has been pursued by the industry since at least the 1960's, as noted by Brian Dooley in his 2008 Cutter Consortium article entitled "Business-IT Alignment (Again)". Dooley sees this as a problem of processes and communications.  He questions whether the term "alignment" is still relevant. In "Business/IT Alignment ‘Is Dead'-What's Next?" Bob Evans proposes that IT cannot bring significant business and customer value without a new approach, because "Alignment Is Dead". He supports this viewpoint in his review of a recent book by Peter Hinssen entitled Business/IT Fusion: How to Move Beyond Alignment and Transform IT in Your Organization, in which Hinssen asserts that it is time to rethink IT. Hinssen asserts that the nature of IT and its relationship to business has changed, and what is needed is a fusion of business and IT-a "blending of IT with the business to focus on technology-enabled innovation". Tom Lodahl and Kay Redditt in their article, "Business/IT Alignment Redux", claim that the change should be a diffusion in which IT people are scattered throughout the business organization and blend into the organizations they support. I agree that it is time for a paradigm shift and that alignment does not capture the essence of the needed change, but neither do new processes, fusion nor diffusion.

Alignment suggests the need for a discipline to get business and IT people marching to the same drummer. The fundamental problem is that business and IT people have different perspectives, and the enterprise needs a balance between business and IT perspectives. Art Jahnke, in his 2004 article entitled, "Sound Off - Why is Business-IT Alignment So Difficult?", sees business executives making IT decisions with little knowledge of IT, while their IT organizations are technology-driven and don't understand the needs of the business. This difference of perspective cannot be resolved with a discipline or formal negotiation, it requires collaboration.

In the early days of IT, collaboration was not so difficult. The goal was automation of tasks, and the business and IT people could collaborate on the design of an automated solution. However, over time, the solutions and projects became bigger, more people and organizations were involved, the effects of solutions rippled across the enterprise, and collaboration became unmanageable. The typical solution has been to formalize the relationships with processes and documents. The result is reduced flexibility, limited exchange of ideas and difficulty developing and maintaining a consensus. Agile development methods are an attempt to re-introduce flexibility and collaboration, but agile methods do not scale to large projects-they work for small, multidisciplinary teams.

The needed paradigm shift should be based on Service Oriented Architecture (SOA). As an approach to design of the business, SOA provides a basis for new relationships between business and IT. These relationships support collaboration in a number of well-defined contexts, so small teams of business and IT people can collaborate to address specific needs of the business. The contextual structure is determined by a shared understanding of the structure of the business and the systems that support it.

The fundamental building block of SOA is a service unit. A service unit is an organizational unit that manages a distinct capability (potentially people, resources, facilities, applications and intellectual capital), and applies that capability in the form of services that meet the needs of external customers or other units within the enterprise. The requirements-the scope and interface-of each service unit are defined such that the service unit is a relatively stable enterprise component that can be engaged to apply its capability in multiple contexts, typically to meet the needs of different lines of business. The scope of a service unit defines the scope of its business processes and computer applications. The implementation of the service unit may change over time, while the interface to the service unit remains the same-providing access to the same business capability. The design of the enterprise becomes a composition of service units to meet business needs.

Business architects design the requirements of service units in the context of the lines of business and supporting services that meet the needs of the enterprise. The business architects must understand the business capabilities represented by the service units, and the operating characteristics that affect enterprise performance, but they do not need to know how each service unit is actually implemented. Business architects must also define the information needs for management of the enterprise, and define the responsibilities of each service unit to provide access to information needed by other service activities.

The IT organization provides supporting services to each of the service units-both application development and operations. The IT people and the business people collaborate to optimize the implementation of the service unit with appropriate leveraging of IT capabilities. The IT organization maintains the various technical capabilities as services to meet the service unit technology needs. This ensures that enterprise technical capabilities are maintained and enables economies of scale in the maintenance and utilization of these capabilities.

IT architects collaborate with the business architects to design the structure of the business with an understanding of how information technology can be exploited to optimize the enterprise design. Together, they can assess the potential business value of the application of new technology to individual service units, and they can provide input to management decisions regarding technology investments. In some cases, old technology may be adequate as long as the service unit can be appropriately integrated with other service units that use it or that it uses.

IT is also responsible for managing technical resources to optimize the use of information technology for the enterprise as a whole. IT is responsible for optimization of the shared technical infrastructure. Optimization includes restricting technical diversity to achieve economies of scale in technical resources-both in development and operations. This means the definition of technical standards, is including computer and communications hardware and software as well as an enterprise logical data model and security mechanisms. This is equivalent to the Human Resource Management responsibility for consistency in the management of human resources, and the Finance and Accounting responsibility for consistency in the management and reporting of financial resources. IT must collaborate with top management to establish and enforce technical standards for the enterprise, and to waive standards when that is a good business decision.

IT is also responsible for supporting enterprise intelligence-making information accessible regarding the enterprise and it's ecosystem. This involves the capture, integration and aggregation of data from various sources to provide a timely and consistent view of the state of the enterprise as well as relevant events and trends.

The fusion proposed by Hinssen does not address the need for an architecture that enables agility nor the need for IT to drive optimization in the use of technology at an enterprise level. The diffusion of Lodahl and Redditt, provides no better solution for enterprise architecture and loses any opportunity to achieve enterprise-level economies of scale in the utilization of IT resources.

The SOA paradigm shift enables IT to take responsibility for optimization of technical resources at an enterprise level, while it enables localized innovation and collaboration in the implementation and automation of service units. Decisions about technology investments as well as other capability improvements can be made from an enterprise perspective, with the understanding of how these capabilities affect the delivery of customer value. IT, represented by the CIO, should become an equal partner in the management of the business with responsibility to develop and enforce standards, support automation and integration, and optimize the utilization of technical resources.

For more on SOA as a business architecture and the transformation of both business and IT, see my book, Building the Agile Enterprise with SOA, BPM and MBM.

We encourage you to share your comments on this post. Comments are moderated and will be reviewed and posted as promptly as possible during regular business hours.

To ensure your comment is published, please follow our community guidelines.

Comments
by Anonymous(anon) on 02-25-2009 06:36 AM

'agile methods do not scale to large projects-they work for small, multidisciplinary teams'

This is really broad sweeping generalization. 'Agile methods' covers a LARGE scope of practices, and although I'll grant that some of these 'agile-labelled' proactices may not apply in a simple manner to larger projects (hm, pair-programming comes to mind, although that is frankly misunderstood and lesser-practiced anyway), others (test-driven development, scrums a.k.a. short-cycle iterative development just JIT requirements validation) absolutely scale to larger projects. I am speaking from direct experience (20+ years sw development, large projects with and without agile practices).

If you can't decompose your 'larger' project into units applicable to JIT requirement validation (the best part of scrum), then you've lost, period. And isn't that actually what you're saying when you talk about SOA-service unit decomposition and alignment? I think you're esposing some of the core agile-methodology values while pandering to agile-backlash...

by Anonymous(anon) on 02-26-2009 06:09 AM

Dave,

I guess I over-generalized about agile methods.  However, there are many who have been unable to realize the benefits of agile menthods, and this should be an opportunity for some of them.  This is a bit more than just decomposing the larger project into smaller units, it involves alignment of business and IT on the scope of a well-defined business and IT component that is loosely coupled to the rest of the enterprise and relatively autonomous in implementation and operation.

Fred

Post a Comment
Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.

Find HP in Social Media

Facebook Twitter YouTube SlideShare Flickr
About the Author
Labels