EA Articles / Reference

Executive Summary

For over four decades, IT strategy has been about the alignment of technology with the needs of the business. Many factors have affected the business-IT relationship over the years, including the increased focus on accounting compliance support, high-profile failures of IT initiatives, disappointing returns on IT investment, the cyclic centralization and decentralization of what constitutes the “best practices” of IT, and the perception that technology is no longer a strategic corporate advantage and is best available through cloud service providers. Less obvious is the rise of the IT vendor community and the effects on both IT practitioners and the business users. Certification to vendor solutions has commanded the loyalty of the IT technical personnel, making them more able to change jobs but less dependent upon companies where they work. The specialization of the vendors to develop and market a world class application to support a discreet business process, optimizing part of the business at the expense of the whole, has often thrust business management into the role of matchmaker between IT vendors and the internal IT department(s) who serve the company.

Some matchmakers are better than others, producing long lived relationships which benefit both the business and the vendor; while other relationships end in divorce, sometimes played out in the eye of the public. To succeed, the business needs its matchmakers to understand the context of the enterprise and avoid the temptation to focus only on the discrete business process while ignoring the rest of the organization. The gap between user acceptance and non-acceptance, between the successful and unsuccessful IT solutions, between IT alignment and misalignment may be a gap in requirements between the specific functional need and the larger organizational need.  Understanding and addressing this gap is the difference between the successful and unsuccessful matches, and the tools to accomplish this are essential to the next generation of both business and IT executive management.

Introduction

“Alignment, alignment, my kingdom for alignment” summarizes the IT priorities from all the surveys of the Society of Information Management (SIM) for the past 20 years (Kappelman, McLean, Johnson, & Gerhart, 2014). Technology advancement, changes to business requirements, and the evolution of business management practices have not changed the need (and, by extension, the failure) of internal IT organization to align with the business.

And yet with this obsession over alignment, IT departments seem less a core competency of the organization than ever before. Many believe information technology no longer provides a lasting strategic advantage (Carr, 2003). Application implementation approaches and methods emphasize changing the process to match the software product. Our teachings, our research, and our professional practices have devolved to achieving the “alignment of the moment”, as quickly and cost effectively as possible. University students recognize this as a sure ticket into a career subject to the perils of outsourcing; continuously chasing the next tool, process, or vendor initiative that will provide a momentary technical advantage over the hordes of application developers willing to work for lower wages. The growth of global outsourcing and cloud services has led many to suggest that the role of the CIO will disappear (Smith & McKeen, 2006).

More of the responsibility of IT alignment falls to the traditional business leaders, to whom the corporate technology experts report (Ross, Weill, & Robertson, 2006). Business leadership of IT priorities, investment, and spending is managed by committees for the enterprise as a whole using governance models to identify stakeholders and incorporate their input through various arrangements (Weill, 2004). This committee’s understanding of how the enterprise functions is limited to their own understanding of the process models of their divisions or departments, and is often inadequate to effectively govern the IT function.

This limited vision of the enterprise has provided an opportunity for the vendor community to pressure the business to select an application that best supports the process they are wishing to automate (or re-automate), regardless of the overall impact to the enterprise. These are technically good tools, providing more features, fewer defects, and better matching the general process specifications than ever before (Jones, Subramanyam, & Bonsignour, 2011). Requirements analysis and design and software engineering maturity have both improved over the last 10 years. The internal IT departments view external vendors as an opportunity for the staff to augment their collection of certifications or systems they have had experience, increasing the market value for their skills. Responsibility for IT success has further transferred to the business, with IT staff’s loyalty to their skill set influencing their objective opinion on the appropriateness of the application “fit” to the overall needs of the business. Novell would have never survived for as long as it did but for the thousands of Certified Network Engineers (CNE’s) trained, tested, and supported by the company.

Highly decentralized organizations tend to optimize departmental performance at the expense of the overall organizational effectiveness, and technology applications selected based upon process alignment tend to exacerbate these silos. It is the limitation of the IT management process which has led to poor matches between the holistic business needs and the vendor capabilities. This “matchmaking” is further compounded by the vendor perspective that more IT is better. Does the vendor care if the old and new business applications and processes do not interact? Does not the lack of interoperability, flexibility, or alignment create a greater requirement of vendor resources? What is apparent from an enterprise perspective is not easily communicated to the IT steering committee through value scorecards, project management updates, or non-functional requirement specifications. 

To transform IT back into a strategic advantage, an enterprise executive applying a definition and measurement tool for IT alignment must be empowered, with IT performance evaluated against the overall enterprise strategy. Several dynamics mask this leverage point, misleading leaders to misinterpret results and conclude that information technology is a commodity. This has greatly benefited the vendors and further strengthening the natural silos of the organization.

The Vendor Community

It is the rise of the vendor community which has altered the relationship between management and the internal IT department. Vendor certifications in infrastructure, applications, databases, and operating systems have come to dominate the technology industry. Many IT job postings require applicants to hold specific vendor certifications, and all postings at every level ask the applicant to be able to demonstrate experience with the technologies the firm has invested. Surveys of future skills needed by IT practitioners further reflect this focus on technical skills, which has the effect of transforming academic instruction of IT from the conceptual to a trade focused on tool training (Kappelman, McLean, Luftman, & Johnson, 2013).

Consequently, IT has evolved into a discipline of “journeymen tradesmen” who can and will leave one industry for another as economic conditions change. In turn, this has led the business to view IT as an extension of the vendors, being more loyal to their skills than to the organizations that employ them. Thus, IT has and is still often viewed as not being “part of the business”, but rather an internal supplier of services not directly connected to the function of the enterprise (McKeen & Smith, 2008). Vendors now target the business managers as much or more than the corporate IT departments, knowing that this is where accountability for technology decisions has shifted. The business professionals have had to become more proficient in the application of technology, using their understanding of the business process to select the “best fit” between the business and the vendor, often without any consideration of the “fit” to the technological and process infrastructure for the rest of the enterprise.

A universal listing of common business processes by industry could be tabularized to a periodic table of opportunity for the software vendor community. Where a discreet business process can be identified (payroll, personnel reviews, point of sale, customer relationship management) there are specific arrays of vendor solutions to support it. Industry specific versions and adaptations further segment the market. Some of these are rolled into a multi-faceted software solution (such as an ERP, which themselves may be a collection of acquisitions by a vendor and integrated into a whole), but many are specifically designed to support an identified business process by industry (dispatch management for a utility company). Even the smallest IT departments support dozens of process-specific applications, often selected by the department process owner to perform a specific silo function of the enterprise. With more of these applications available in cloud-based solutions, the applications supported by the internal IT services group probably is not all inclusive of the point solutions employed by the organization.

This has shifted the balance of power among the business, IT, and the vendor. The vendor has become the process specialist the business manager looks to first. Industry specific trade shows showcase “solutions in search of problems”, software vendors hawking their wares to business process specialists directly. Vendors host user conferences and discussion boards to address issues and identify needs of the business specialists, usually without the involvement of IT. Some vendors even offer first-level help desk services, with end users calling the vendor directly for application support. This has resulted in a power shift to the vendor, with both the business process owners and the IT department aligning to the vendor products, which is illustrated in Figure 1.

Figure 1

This implementation of so called “best of breed” technologies has brought faster automation to processes than would have been done by an internal IT department writing custom code.  Not only do vendors have economies of scale, they also can dedicate technical staff to become “process specialists” on par with the business process specialists of a firm.  Overall the vendor may have more customers to support than an internal IT firm, but they all speak the same language (HR, accounting, MRP, procurement, etc.).  Efforts to meet externally imposed requirements placed upon one client (Sarbox reporting, Basel II Accord) can be leveraged to meet the needs of all, reducing costs.

Improvements in RA&D

It is in the interests of the vendors to improve communication between technologists and the business process owners. The improved communication (and specialization) of the IT developer community to support a specific business process has led to an improvement in the requirements analysis and design of the entire practice of software development. From the SIM survey 2007, more organizations aspire to the development practices of the Software Engineering Institute's (SEI's) Capability Maturity Model for software development since the same assessment in 1997 (Kappelman & Salmans, 2008). The number of level 4 and 5 shops has increased, with the percentage of software defects falling proportionally (Jones, 1996). Commercial software has both improved in quality and delivery speed, fostering the business need to bring automation of a process to a level of sufficiency, maximizing efficiency in both time and money.

This “virtuous cycle” of technology process specialists has come at the cost of an overall enterprise process specialist. As RA&D has improved for a specific business function, the business has rewarded the vendor with loyalty to a product, encouraging the IT staff to become technically proficient in the vendor’s tool. This has a dampening effect on the business analytical capabilities of the IT staff, reducing the business process to a “black box” which they support as per the vendor training received. This fosters further reliance on the vendor tool by both the business and the technologists, with both becoming proponents of the vendor solution.

What appears to be an alignment of the business and the technology is, in fact, an alignment with the vendor or the tool created for the business process. Loyalty between the IT department and the business is contingent upon their individual loyalties to the vendor, and not to the overall business strategy or enterprise-wide plan. This “shifting of the burden” is well documented by Peter Senge and others as an archetype with similarities to models depicting dependencies of an addiction. Ultimately, this vicious cycle has left organizations where they no longer have the abilities to achieve the comprehensive goal: the purposeful design of the enterprise.

Not all these “matches” are bad for the business, however. Some processes that are necessary but not “core” to the business benefit greatly from a vendor solution. The framework for both identifying candidate processes and selecting the best “match” for the organization begins with the identification of the leverage point in the model, identification of the absolute target for the organization (Wolstenholme, 2004).

The leverage point: enterprise management

The business focus on matching the vendor to the specific process has resulted in the collapsing of other considerations into marginal importance. Using a framework for enterprise management, business process can be represented as one of the logical things of the enterprise. Managers deal with logical things (organization structure, process flows, material flows), or logical behaviors (business plans, work flows, timing cycles) specific to their area of responsibility. The manager may not know the logical things and behaviors of the other managers, and often this knowledge often has not been reduced to writing.

The vendor knows the physical things (data models, system design, and technology architecture) and the physical behaviors (user interface, process order, and rules) to bring the manager’s logical vision to physical reality.

Currently, the focus on “best fit” revolves around the process at the functional area level. Application features (function points), reporting capabilities, and generic interfacing abilities encapsulate the majority of specific service deliverables of systems purchased today. All three of these are process-centric evaluations. The other facets are either ignored or invisible, and rely on luck or re-work if they are to be achieved. Once selected, these components (vendor software solutions) are “shoved up” into the enterprise from the bottom. Implementation specialists (internal or external) discourage modification to the product for adoption, instead pressuring the employees to adopt their work processes to conform to the process coded by the vendor. The resulting slivers of alignment meet discrete business process needs but fail to achieve a purposefully designed organization.

To change this, the organization needs to first identify the overall goals and structure for the company, and after “match” the out of scope products with the overall design of the enterprise (Finkelstein & NetLibrary, 2006). A two by two matrix, separating the logical from the physical and the processes from the people can be used to identify and match the vendor solution (a physical process thing) to an overall integrated logical design as depicted in figure 2.

Figure 2: The Zachman Quandrant Phrase Structures

New opportunities can come from both the vendor community (through the development of an improved tool or process) or from the business strategy (a new product offering).  As these new parts are identified, the framework acts to focus on the boundary between the logical and the physical, thereby improving matches between product and process.

The leadership intervention to bring about the learning organization

Learning is the key to purposeful organization design. To encourage learning, an organization should generate a holistic view of the organization (Goh & Richards, 1997). This necessitates both the will and the tools to design an enterprise. In many organizations, managers are evaluated on their performance of the business process they directly control. It is tempting to view the selection of software as falling into the realm of simple contexts, where the employees responsible for business process select from a short listing of “best practice” solutions to improve the performance of their direct teams (Kurtz & Snowden, 2004).

This approach is inappropriate for more complex contexts. No organization is a single purpose, goal seeking entity, but rather an entity with a functional division of labor in pursuit of the common purpose of the elements that define it (Ackoff, 1971). Paradoxically, it seems that few enterprises have developed strategies for addressing change to the organization (Zachman, 2004). To correct this, companies must institutionalize a process of organizational change management to purposefully structure the people, processes, and technology to best achieve the common goals.

Vendor driven alignment (the selection of the solution out of context with the enterprise design) is the “norm” for most organizations today, and the by-product of the IT duopoly governance model. This alignment of the parts at the expense of the whole costs organizations

This requires the recognition of the need for a design of the organization, the vantage point to “see” all the parts of the organization, the ability to get the senior management to support the design, and the power to enforce compliance. Of all the executives available to bring about this transformational leadership, the COO is the best placed executive.

The COO as Architect

IT governance matters because research has shown that top performing enterprises reap up to 40% greater return than their competitors for the same IT investment (Ross et al., 2006; Weill, 2004). From studies of IT governance practices, it is proposed that structures where business departments are involved in one on one relationships with IT executives are becoming more popular in the belief that this will ensure IT aligns with business strategies (Weill, 2004). Instead, this is a recipe for alignment with tactics and a misalignment with the organization.

With IT’s focus on alignment to the process, it falls to the COO to play the role of matchmaker, balancing the needs of the overall good of the enterprise with the point solutions desired by the department. With the rising emphasis on “cloud computing”, where the organization uses services from an online array of vendors, more choices are faced by the leader with an overall vision for the enterprise. The choices of what to outsource, what to in-source, what to federate (that is, what services or processes or data to share), what is principal (as defined as what services or processes or data to keep exclusive and separate) cannot be made without an overall understanding of the role of IT in the context of the organization.

The COO must expand his/her role to embrace not only the governance of IT by overseeing the duopolies between IT and the business processes, but must ensure the logical overall design of the organization is supported by these initiatives. To do this, the COO must both ensure that the vision of the executive leadership (particularly the “why” or “motivations” of the enterprise) are agreed upon as well as managing the resource allocations (through the budgeting process and IT governance) to holistically achieve the optimal enterprise designs and objectives.

Architecture is not about the physical design of IT, as many respondents in multiple SIM surveys indicate (Kappelman, 2008; Kappelman et al., 2014). This common perception has resulted in architecture management processes resemble existing IS/IT management processes (Winter & Schelp, 2008). Instead, architecture is about the context within which to make the trade-off decisions between the long-term and short-term options facing the company, identifying the relationships and dependencies so they can be altered or preserved as necessary (Zachman, 1982). This is why the responsibility of architecture belongs jointly to the COO and the CIO.

The Future of the Internal IT Organization

Predictions that the management style of IT will change from anticipatory (to anticipate business strategy) to architectural will prove to be accurate, but will not be accomplished by the CIO alone (McKeen & Smith, 2008). The role of the CIO will be split into two distinct responsibilities: the CTO, who manages the actual technology components (internal or cloud) of the enterprise; and the CIO/COO, who manages the architecture and is responsible for the overall return on investment over time.

This is further defined in the differences between two primary approaches to IT service delivery: as an internal service provider focused on maximizing the efficiency of building and running systems; or as a partner and player in the business, defining IT systems in the context of the entire enterprise objectives and strategies. Both of these approaches seek to partner with the business, but for different purposes. Interestingly, in a recent survey of SIM members, many exhibit signs of cognitive dissonance, with respondents who do not involve the business in EA activities counter-intuitively expressing they are more aligned with the business objectives than those who do incorporate business participation.

For practitioners, this implies that IT shops that do engage business process owners, users, and business subject matter experts in their EA activities may have a better appreciation of the alignment gap between IT and the business. It would be expected that more mature IT organizations emphasize business engagement equally with build-and-run capabilities and following some logically ordered approach to achieving an agreed-upon service level. There may be value in interpreting IT firms in a 2x2 matrix by which organizations can be classified according to their physical technology practices on the one hand, and their logical perceptions about EA on the other. On the physical dimension, the degree to which enterprise-wide technologies are applied; and the logical dimension whether they perceive EA as simply a tool used just for IT architecture as opposed to a tool to integrate IT and align it into the overall business activities for the enterprise as a whole. This then decomposes to four overall types of IT shops, dependent upon where they fall in the respective logical-physical continuums as depicted in Figure 3.

Figure 3: Proposed Decompositions of Internal IT Service Provider Organizations  

Though not necessarily indicative of four mutually exclusive types of IT departments, it may be that depicts four primary archetypical IT organizations. It is proposed that the following descriptions of four distinct types of IT departments can be seen:

Organizations which fall into the upper-right quadrant (Business Partner) are those which perceive EA as encompassing the entire organization, and practice inclusion of the business process owners, user subject matter experts and governance bodies, and incorporate enterprise-wide tools and technologies to support this comprehensive approach. It would be expected that the IT functions of organizations in this category would be the most aligned as perceived by both the IT department and the other organizational leaders of the firms. It would be expected that IT leadership of these firms may more likely report directly to the CEO, or at least have a seat at the strategy table.

Organizations in the upper-left quadrant (Agility-Focused) are those which use the tools to achieve holistic IT solutions to the benefit of the overall enterprise but only view EA as descriptive of the technology infrastructure, disassociating IT models from the business process owners and users. This could be the reflection of a philosophical shift of the focus of IT from alignment to agility and cost-effectiveness, as a comprehensive enterprise-wide technology approach using the right enterprise-wide tools should help the IT organization react to changing priorities and facilitate immediate business challenges. IT organizations in this quadrant may tend to report to the CFO, COO, or some other business leader other than the CEO, and though perhaps not viewed as a strategic partner to the organization are nevertheless seen as a significant and responsive service provider.

Organizations in the lower-left quadrant (Disintegrated) are those which do not use enterprise-wide tools in their IT activities and view EA as strictly an IT initiative. These IT groups would be focused on building and running systems, often be highly decentralized, and view IT as a separate entity (or guild) from the core business, the primary purpose of which is to optimize the technology supporting specific business processes out of context to the whole organization. IT departments in this quadrant could be expected to focus on cost control and responsiveness to specific business functions or processes, and there likely could be several IT departments reporting to different C-level executives. Cost control, functional performance metrics and divisional relevance would be the primary objectives for these IT organizations, but as an expense managed by each for each division, discipline, business-unit, or agency.

Organizations in the lower-right quadrant (Cognitive Dissonance) are those which believe they have the mission of partnering but do not use the tools and technologies which help them articulate the business objectives into technology integration or business-IT alignment. These IT groups will focus on the language of partnering with the business but without the capabilities to turn these into actionable projects and solutions. These organizations may have outsourced their IT function, focusing the internal IT organization into a consulting or oversight responsibility, responsible for tasking the IT vendor or cloud services supplier with the business requirements and managing service levels. Contract management and service delivery by the external provider(s) would be primary objectives for these IT organizations, and they could be expected to report to the CFO or an accounting manager or administrative officer. Arguably, this may represent the future of IT, separating build-and-run from design and integrate.

Conclusions

Before organizations outsource what is unique, before companies miss a competitive advantage, before the opportunity is lost, the management of information as an asset has to be transformed from an art and into a science.  Before there was chemistry, there was alchemy, with some people using either luck or guesswork identifying compounds that would display specific desired properties without really understanding why they behaved in the way they did.  Some alchemists were better than others, with some more adept at finding and identifying routines for replicating their alchemy better than others.  It took the development of the periodic chart of elements to transform chemistry into a science.  This transformation is happening today in the construction of organizations, and is currently called Enterprise Architecture.  The name is of little importance, what is important is that the proper leader of business transformation is identified and takes the tools for the purposeful design of the organization and makes them work to realize the synergy, reduce the redundancy, and lead the next generation of the corporations into the future.

References

Ackoff, R. L. (1971). Towards a System of Systems Concepts: Institute of Management Sciences.
Carr, N. (2003). IT Doesn't Matter (Vol. May, 2003). Cambridge, MA: Harvard Business Review.
Finkelstein, C., & NetLibrary, I. (2006). Enterprise Architecture for Integration: Rapid Delivery Methods and Technologies: Artech House.
Goh, S., & Richards, G. (1997). Benchmarking the learning capability of organizations. European Management Journal, 15(5), 575-583.
Jones, C. (1996). Patterns of Software System Failure and Success: International Thomson Pub.
Jones, C., Subramanyam, J., & Bonsignour, O. (2011). The Economics of Software Quality: Addison-Wesley Professional.
Kappelman, L. (2008). Enterprise Architecture: Charting the Territory for Academic Research. Proceedings of the Fourteenth Americas Conference on Information Systems. Conference on Information Systems. Toronto, ON, CA.
Kappelman, L., McLean, E., Johnson, V., & Gerhart, N. (2014). Key Issues of IT Organizations and Their Leadership: The 2014 SIM IT Trends Study. MIS Quarterly Executive, 13(4), 237-263.
Kappelman, L., McLean, E., Luftman, J., & Johnson, V. (2013). Key Issues of IT Organizations and Their Leadership: The 2013 SIM IT Trends Study. MIS Quarterly Executive, 12(4).
Kappelman, L., & Salmans, B. (2008). Information Management Practices Survey 2007. Enterprise Architecture Working Group. Preliminary Report. Society for Information Management. Chicago, Illinois.
Kurtz, C. F., & Snowden, D. J. (2004). The new dynamics of strategy: Sense-making in a complex and complicated world. IBM SYSTEMS JOURNAL, 42(3), 462-483.
McKeen, J. D., & Smith, H. A. (2008). Developments in Practice XXIX: The Emerging Role of the Enterprise Business Architect. Communications of AIS, 2008(22), 261-274.
Ricks, T. E. (2012). What Ever Happened to Accountability? Between George C. Marshall and William Westmoreland, leadership in the US Army markedly declined. Harvard Business Review, 93.
Ross, J. W., Weill, P., & Robertson, D. C. (2006). Enterprise Architecture as Strategy. Havard Business School Press. August, 1.
Smith, H., & McKeen, J. D. (2006). IT in 2010: The Next Frontier. MIS Quarterly Executive, 5(3), 125-136.
Weill, P. (2004). Don't Just Lead, Govern: How Top-Performing Firms Govern IT. MIS Quarterly Executive, 3(1), 1-17.
Winter, R., & Schelp, J. (2008). Enterprise architecture governance: the need for a business-to-IT approach.
Wolstenholme, E. (2004). Using generic system archetypes to support thinking and modelling. System Dynamics Review, 20(4), 341-356.
Zachman, J. A. (1982). Business Systems Planning and Business Information Control Study: A comparison. IBM Journal of Research and Development, 21(1), 31.
Zachman, J. A. (2004). The Challenge is change: A Management paper.