Increasing the Relevance of Enterprise Architecture through ...

Increasing the Relevance of Enterprise Architecture through “Crisitunities”1 in U.S. State Governments How enterprise architecture (EA) can deliver its promised benefits remains an open question. The common assumption is that an EA program should be incrementally implemented (the maturing approach). But our research found that U.S. state governments are also using two other approaches, both of which take advantage of crisitunities: the refreshing approach, which updates an existing EA program in response to a radical IT change, and the bundling approach, where a radical IT change jump-starts the development of a new EA program. Based on three representative cases, we identify four lessons for creating a relevant EA program.2, 3 Quang “Neo” Bui Rochester Institute of Technology (U.S.)

Enterprise Architecture Implementation

,,

1 2 3

“… there are two sides to an enterprise architecture. There is a conceptual side … which works on paper … [but] it is all meaningless unless someone physically and basically can do it … Before that happens, you surely have nothing more than a really good set of ideas.” A Chief Enterprise Architect talking about EA benefits

Although enterprise architecture (EA) has been around for almost 30 years, there is confusion and skepticism about EA’s meaning and value. While there is some evidence of EA successfully transforming an enterprise,4 the core question that remains unanswered is: How can EA deliver its promised benefits? The answer, as suggested by the above quote, lies in what makes EA relevant to the organization.5 A relevant EA program has positive impacts on the business. These may be measured by reduced IT development time and costs, or be visible as specific solutions to local business

1 The term “crisitunity” was popularized by The Simpsons episode 114 “Fear of Flying.” When told that the Chinese word for crisis consists of two characters, danger and opportunity, Homer Simpson suggests the word “crisitunity” to describe the situation. Examples of crisitunities can be found in many management cases. 2 Sia Siew Kien, Michael Rosemann and Phillip Yetton are the accepting senior editors for this article. 3 This study is based on work supported by the National Science Foundation under Grant No. SES-0964909. The author gratefully acknowledges the contributions of researchers from the Art of the State project (http://blogs.bentley.edu/nsf/). Additionally, the author especially thanks M. Lynne Markus, Matthew Levy, Son Bui, the editors of this special issue and anonymous reviewers for their invaluable comments. The support of the Supply Chain and Information Systems department at Pennsylvania State University is also greatly appreciated. 4 Rai, A., Venkatesh, V., Bala, H. and Lewis, M. “Transitioning To a Modular Enterprise Architecture: Drivers, Constraints, and Actions,” MIS Quarterly Executive (9:2), 2010, pp. 83-94. 5 Tamm, T., Seddon, P. B., Shanks, G. and Reynolds, P. “How Does Enterprise Architecture Add Value to Organisations?,” Communications of the Association for Information Systems (28:1), 2011, pp. 141-168.

December 2015 (14:4) | MIS Quarterly Executive 169

Increasing the Relevance of Enterprise Architecture through “Crisitunities” in U.S. State Governments

challenges.6 A relevant program may also be recognized by awards and in social media. The EA community is full of competing guidelines and models (e.g., Zachman,7 TOGAF8) specifying what a relevant EA program should include. Nevertheless, there is general agreement on one point: progressive EA implementation can create relevance by developing an EA program and working to improve it over time.9 The incremental EA improvement model is enshrined in various published maturity models. For example, the National Association of State CIOs (NASCIO) classifies the maturity of an organization’s EA program based on how well it is established, ranging from level 0 with no program to level 5 with a continuously improving program.10 The MIT Center for Information Systems Research (CISR) classifies EA program maturity based on the competencies it enables, ranging from local business solutions to enterprise modularized components.11 The maturity models imply organizations should implement EA incrementally, building the program and creating capabilities one phase at a time. However, our study of EA practice in 50 U.S. state governments (see the Appendix for details) shows that the incremental maturity approach is not the only way to create a relevant EA program. In addition, we observed two approaches that capitalize on “crisitunities”—opportunities arising from crises—to increase the relevance of EA. The first approach took advantage of a state’s radical IT changes to refresh its EA program. The second approach bundled EA initiatives within a state’s radical IT changes. These radical IT changes, including statewide IT consolidation, IT reorganization or IT integration, provided opportunities to make EA programs more relevant to the state’s agenda. We describe below three representative cases of these approaches: a maturing approach in 6 Ross, J. W., Weill, P. and Robertson, D. C. Enterprise Architecture as Strategy: Creating a Foundation for Business Execution, Harvard Business School Press, 2006. 7 Zachman Enterprise Architecture Framework (see http://www. zachman.com/). 8 The Open Group Architecture Framework (see http://www. opengroup.org/togaf/). 9 Robertson, B. and Blanton, C. E. Enterprise Architecture Frameworks: Just Choose One and Use It, Gartner, Inc., March 5, 2008. 10 Enterprise Architecture Maturity Model Version 1.3, National Association of State Chief Information Officers, 2004. 11 Ross, J. W. “Creating a Strategic IT Architecture Competency: Learning in Stages,” MIS Quarterly Executive (2:1), 2003, pp. 31-43.

170

MIS Quarterly Executive | December 2015 (14:4)

Kansas, a refreshing approach in Michigan and a bundling approach in California.12

Kansas: The Maturing Approach to EA

In 1998, Kansas legislated to form an Information Technology Executive Council to coordinate IT efforts at the state level. The council was explicitly charged with establishing an IT architecture that encompassed the various systems and IT equipment being used in all state agencies. The legislation also created the position of chief IT architect and established the Kansas Information Technology Architecture (KITA). KITA’s goal was to “focus our future information technology investments on supporting the business needs of state agencies and the citizens of Kansas” (KITA version 12.0, p 1-2).13 Since its inception, KITA has gone through 12 incremental updates to ensure it stays relevant to state IT needs as well as EA developments in the public sector (see Table 1). The updates were triggered by agency feedback (e.g., through annual reviews) and lessons learned from EA developments in other sectors (e.g., federal agencies, private enterprises) and have evolved KITA from a technical to a more holistic EA. By 2003, KITA had released ten versions and had achieved level 4 maturity based on the NASCIO Maturity Model. This classified it as a well-defined and well-managed program. The major advantage of gradually maturing an EA program is that it requires relatively low investments and subjects the organization to few shocks. In Kansas, the EA team remains small— just two or three people. The team operates at a high level, providing statewide guidelines and procedures rather than detailed consulting services at an agency level. This helps to minimize resistance to EA and provides flexibility to agencies. However, the maturing approach makes slow progress and frequently lacks momentum. In Kansas, it took several years to fine-tune KITA and use it to reduce IT complexity in the state. Within some agencies, the slow progress has made it

12 While 24 formal EA programs were identified and used to generalize the three patterns, we only report three representative cases here, which clearly demonstrate the pattern and subsequent outcomes. 13 Kansas Information Technology Architecture version 12.0, available at https://oits.ks.gov/.

misqe.org | © 2015 University of Minnesota


Table 1: EA Development Timeline in Kansas Date 1998

KITA development Draft v1.x a work-in-progress draft

12/1998 Draft v2.0 an updated draft for executive approval 1999 2/1999

Draft v2.1 updated network architecture to facilitate enterprise integration Draft v2.18 updated platform architecture to standardize server use

1999

Draft v3.10 introduced sub-architectures based on feedback from state agencies

1999

Draft v3.11 provided structure for Kansas Technical Architecture Review Board (KTARB)

1999

Draft v4 introduced conformance elements from KTARB

10/1999 KITA v5 updated sub-architectures to provide state-related content 2000 2001

KITA v6-8 incrementally updated to provide more state-related content (e.g., asset management, information management, security, storage architecture, etc.) KITA v9 updated content

2002

KITA v9.5 updated content

2003

2009

KITA v10 linked IT architectures to business value, used business modeling tools to increase consistency KITA v11 aligned with other public EA frameworks to encourage information sharing and collaboration KITA v11.2 updated content

2011

KITA v12 provided clarifications for technical managers and project teams

2006

difficult to credit KITA with specific financial impacts. Even without this recognition, the EA team has persisted with its educational efforts. The team has presented KITA several times to highlevel executives to illustrate how EA supports the state’s business objectives. As a result, the EA program has been an active part of the state’s IT governance process. When the governor released his plan to improve IT efficiency in 2011, EA was one of the 25 key IT initiatives to better manage IT investments.

Michigan: The Refreshing Approach to EA

As one of the states hardest hit by the financial crises, Michigan has always aggressively used

IT to improve its services. Since the creation of the first state CIO and statewide IT office in 2001, Michigan has continuously introduced consolidation projects to cut costs in various areas. These have included geographic information systems (GIS) and a human resource application in 2001, helpdesk services in 2003, emergency radio systems in 2004, tax e-filing in 2005 and a standardized office platform in 2006. The results have been encouraging. Since 2001, Michigan has consistently been ranked by the Center for Digital Government as a leading state in using IT to deliver governmental services.14 Developing a statewide EA was just one of the many IT initiatives Michigan undertook to transform its IT environment. Realizing the need to align IT strategy with 14 http://www.govtech.com/cdg/digital-states/.

December 2015 (14:4) | MIS Quarterly Executive

171


Figure 1: Michigan’s MiCloud Solutions Used EA Standards and Components

Michigan EA Frameworks

MiCloud

Function Review

MiCloud Delivery Decision

• • •

Virtual Data Storage (IaaS) Virtual Server Hosting (IaaS) Process Automation (SaaS)

business plans, the state created a formal EA plan in 2006 and released a developed EA framework in 2007.15 The purpose was to increase collaboration, transform governmental services and align IT investments with public service needs. Between 2009 and 2010, the EA program received a major refresh resulting from a radical state IT initiative. To further reduce costs, a new central IT department was created by merging two other departments. The new department orchestrates IT services and administrative services, including contract portfolio management, procurement services, retirement plans and state facilities management.16 Michigan built on its previous consolidation and service delivery successes to develop an internal cloud computing service. This service—MiCloud—was the first internal government cloud in the U.S. and promises to further reduce costs for Michigan. A lead architect from the Office of Enterprise Architecture was appointed as MiCloud’s project manager to ensure it would be aligned with the state’s business objectives and IT standards. EA standards and procedures were revised to account for the selection and use of cloud-based solutions. A review was conducted to evaluate whether existing functions would benefit from a cloud-based solution and how that solution would leverage existing business plans and technical architecture. 15 2006 Michigan IT Strategic Plan: From Vision to Action, available at https://www.michigan.gov/. 16 State of Michigan ICT Strategic Plan 2010-2014: From Vision to Action, available at https://www.michigan.gov/.

172


• •

Technical EA Domains SOA

As shown in Figure 1, three cloud-based solutions were proposed: virtual data storage for users and servers (an infrastructure-as-a-service or IaaS solution), virtual server hosting for development (also an IaaS solution) and process automation as a software-as-a-service (SaaS) solution. EA standards and components were adopted to help develop these cloud solutions. For example, Michigan used standards from its technical architecture to develop databases for IaaS solutions and used service-oriented architecture (SOA) components and web services to increase reusability of service interfaces for SaaS solutions. Compared with Kansas, Michigan refreshed its EA program in a more radical way. By capitalizing on the opportunities stemming from a radical state IT change—the creation of a new central IT department—the Michigan EA program was refreshed to stay relevant to the state’s IT needs. The program produced quick outcomes responding to immediate needs of agencies. As a result, EA gained increased support from agencies, many of which were attracted by the cost savings from the cloud solutions. Within a year, MiCloud produced measurable impacts. Data service requests were processed in 10 minutes, 90% faster than non-cloud processes. Data storage was 85% cheaper than the next cheapest alternative storage solution. The hosting service was performed 10 times faster because it was being performed internally. In 2011, MiCloud received a national award from NASCIO for its



fast-track solutions17 and an Innovations Award from the Council of State Government.18 A major benefit of the refreshing approach is cost-effectiveness. Because the development of MiCloud was based on existing infrastructure standards and components that conformed with the state’s EA, development costs were modest. However, using this approach was complex; it required careful planning to ensure consistency with existing systems. For example, Michigan’s EA team recognized that SaaS solutions can be built on different standards, which would limit system integration and interoperability. To resolve this, the team used SOA components to make SaaS solutions more interchangeable. In 2003, the IT environment in California was in a state of flux. The Department of Information Technology (DOIT), which was established in 1996 to provide IT oversight, was being slowly phased out, with its responsibilities being devolved to state agencies. The state did not have a strategy to manage its various IT challenges. These included a diverse and complex IT environment, weak collaboration between agencies, ambiguous oversight processes, undefined standards and an absence

of performance metrics. Reports from outside consultants showed that the state needed significant reform to improve its IT environment. In 2005, the newly elected governor submitted a reorganization plan, which included the establishment of a new Department of Technology Services (DTS) to consolidate major data centers and telecoms functions. The plan also included the creation of an Information Technology Council (ITC). The council created an Enterprise Architecture Committee to research and recommend actions to create a statewide enterprise architecture. This committee conducted extensive research, gathering experience from agencies that had developed EAs and inviting presentations from major EA consultants. The result was the California Enterprise Architecture Framework (CEAF), which combined best practices from the FEA (Federal Enterprise Architecture) framework, TOGAF, Medicaid Information Technology Architecture (MITA), the National Institute of Standards and Technology (NIST), MIT CISR research, Harvard Business Press, Gartner and the Corporate Executive Board. CEAF version 1.0 (released in 2005) was a major step toward IT consolidation and the establishment of statewide standards. The 2013 CEAF version 2.0 focuses on building business capabilities.19 To assist agencies in using EA to

17 2011 NASCIO Recognition Award Nomination: MiCloud Automated Hosting Service, available at https://www.michigan.gov/. 18 http://www.csgmidwest.org/policyresearch/CSGInnovationsAwards2011.aspx.

19 California Enterprise Architecture Framework Version 2.0, California Department of Technology, 2013.

California: The Bundling Approach to EA

Figure 2: Reference Architecture Areas across Major IT Initiatives in California


173


deliver business outcomes, California developed seven reference architectures—Identity and Access Management (IdAM), Business Intelligence (BI), Master Data Management (MDM), ServiceOriented Architecture (SOA), Enterprise Application Integration (EAI), Enterprise Content Management (ECM) and e-Government (eGov). These reference architectures documented best practices to develop IT solutions that could be reused and shared throughout the state government for a variety of projects (see Figure 2). For example, California identified e-Government as a common component in nine major IT projects and created the eGov reference architecture in 2014. Four specific e-Government scenarios were identified. For each scenario, the eGov architecture specifies the components, platforms and technical layers needed to develop an e-Government solution. In the publishing data scenario, for instance, agencies can use enterprise content management to query for content and publish it on their web portals. This standardizes the process for developing e-Government solutions, while allowing agencies to reuse components from prior projects. Whereas Michigan took advantage of the state IT transformation to refresh its EA program, California created a new EA program as part of a radical statewide IT reorganization to cope with its IT governance crisis. The program received considerable attention and support from state agencies. A recent self-assessment showed that most agency managers are aware of the program as well as its deliverables and relevance.20 In several agencies, the EA program was one of the key drivers for successfully reorganizing IT. For example, the California Department of Health Care Services received a national award for implementing an innovative strategy with mobile applications, cloud computing and software-asa-service.21 The strategy was enabled through an EA that established clear technology roadmaps, used performance metrics for key architectural areas, deployed enterprise solutions and provided training aligned with the department’s strategies. 20 CEAF 2.0 EA Maturity Scorecard; this worksheet is available for download at http://www.cio.ca.gov/ea/documents.asp. 21 “DHCS Wins National Award for Health Care Innovation Strategy,” techwire.com, October 9, 2014, available at https://www.techwire.net/dhcs-wins-national-award-health-care-innovation-strategy/.

174


The California Department of Correction and Rehabilitation used solution architects as a bridge between business and technology to identify solutions that not only served business needs, but also complied with enterprise standards. The architects worked with business managers to understand their business plan, selected standards that met their needs and identified collaboration opportunities.22 Involving the solutions architects resulted in a faster procurement process (reduced from 18-to-24 months to 6-to-9 months), on-time project development and improved service responsiveness due to standardized procedures. The bundling approach to enterprise architecture can create momentum and deliver immediate outcomes related to the organization’s goals. However, it requires significant investment. The California Enterprise Architecture Committee comprised 10 members from various agencies. It took them over a year working with EA-related subcommittees and external groups to deliver version 1.0 of the framework. The EA program continues to expand with new groups: the EA Peer Group, the Identity and Access Management Group and the Service-Oriented Architecture Group. In light of the state’s budgetary crises, these developments represent significant commitments and illustrate California’s high interest in pursuing EA.

Patterns of EA Implementation across U.S. State Governments

The three cases described above represent three different approaches to EA adoption and use. Kansas used the maturing approach for its EA program, which started as an IT architecture and evolved incrementally to become a more holistic EA with enterprise-wide technology standards. In Michigan, IT consolidation sparked an interest in cloud computing, and the existing EA program was refreshed to take advantage of the new opportunities. In California, the governor’s reorganization plan kick-started the development of a completely new EA program to support the plan. 22 Mupparaju, S., Word, B. and Wiebe, E. Enterprise Architecture (EA): Basic Concepts, Guidance, and Success Stories, presented at California Project Academy Series, 2014.



Table 2: Use of the Refreshing and Bundling Approaches to EA in U.S. States Refreshing EA Case Michigan: In 2009, the state went Exemplar through an IT reorganization, and the EA program was in charge of developing a cloud computing solution to improve governmental services. Other Massachusetts: EA played a greater Cases role in the 2009 state IT consolidation. Minnesota: EA became businessoriented due to IT reorganization in 2004. Utah: IT consolidation in 2005 led to an enterprise approach to EA being adopted. Virginia: The EA program was given greater roles in the 2003 IT reorganization. Washington: The EA program had a more significant role due to the 2011 state reorganization. In our research for this study, of the 24 U.S. state governments with a formal EA program, six used the refreshing approach to EA, and eight used the bundling approach (see Table 2). Both approaches take advantage of opportunities from radical IT changes to increase the relevance of an EA program. Notably, states adopting the maturing approach started their EA programs earlier than others (average starting year was 2000). In contrast, states using the refreshing and bundling approaches started later (average starting years of 2003 and 2006, respectively). In addition, five of the eight states that adopted the bundling approach sought external help to guide and facilitate their EA programs (California, Colorado, Illinois, Missouri and Oregon). The bundling approach is complex and frequently requires considerable external expertise to successfully execute it. Given the pressure for transformation due to ongoing financial crises and market pressures, EA practitioners would find the refreshing and bundling approaches appealing. However, this does not necessarily imply the maturing approach

Bundling EA California: The EA program was initiated as part of the 2005 governor’s reorganization plan. The program created several reference architectures to address emerging needs of state agencies.

Colorado: The EA program was started in 2008 to assist IT consolidation. Delaware: The EA program was created as part of a new state IT department in 2003. Hawaii: IT reform in 2010 triggered the formation of the EA program in 2012. Illinois: The EA program was created as part of the 2004 IT rationalization. Missouri: a new state IT department was established in 2003 and initiated the EA program. Oregon: The IT function was reformed in 2006, and the new CIO started an EA program. Vermont: The EA program assisted the state’s migration to cloud computing in 2011. is less effective. The first step in building a relevant EA program is to understand and embrace the most appropriate implementation approach for your organization. Figure 3 depicts the decision process. In the absence of a crisitunity, the maturing EA approach is the default option for developing and progressing an EA program. Yet, even with a crisitunity, the maturing approach could still be appropriate for organizations that lack the ability to seize the opportunities arising from the crisis. In U.S. state governments, this may happen when their EA teams have low resources, managerial support, in-house expertise and agency involvement in the EA development process. These conditions favor progressive changes within a maturing approach. A major benefit of the maturing approach to EA is that, by its nature, it introduces few shocks and therefore does not trigger significant resistance from users. Most of the changes are incremental, making them less complex than changes occurring in the refreshing or bundling approaches. For example, Kansas has only two or three members in its EA team, which has December 2015 (14:4) | MIS Quarterly Executive

175


Figure 3: Choosing an Appropriate and Relevant EA Approach

introduced incremental changes over several years. The trade-off from adopting the maturing approach is weak momentum and slow progress in EA development. In the presence of a crisitunity, organizations with existing EA programs can choose to refresh them. However, radically adjusting an existing EA program is a complex process that can trigger considerable resistance or lead to conflict with existing processes, so the EA team must have the necessary resources and support from top managers, significant expertise and agency involvement. Moreover, the EA team should make the process open and transparent, involving stakeholders throughout the planning and development phases. The development of MiCloud in Michigan provides a good example. It required expertise, top management support and collaboration from multiple agencies to ensure the final solution would fit with existing processes. 176


The EA team engaged the users by thoroughly explaining all aspects of MiCloud.23 With the right execution, the refreshing approach can provide strong momentum and quick progress when it responds directly to the immediate changes in the organization. Michigan enjoyed significant outcomes within a year. Organizations facing radical IT changes but that do not have existing EA programs can adopt the bundling approach to jump-start their EA programs. This approach requires significant resources and support. For example, the California EA team received spin-off support from the governor’s reorganization plan. The bundling approach also requires high levels of expertise and agency involvement because it needs significant up-front efforts to initiate a relevant EA program. To overcome the expertise deficit, organizations can engage consultants to quickly 23 Michigan Enterprise Architecture Framework, Appendix K, available at http://www.michigan.gov/.



acquire the necessary knowledge to kick-start their EA programs. As a result of the intensive developments needed by the bundling approach, quick progress can be made and strong momentum built for EA development and use. This is an advantage of a bundling approach because it allows an EA program to quickly address the organization’s immediate needs. In contrast, the rapid and radical changes are complex and can trigger considerable resistance, especially from those who feel threatened by changes.

Lessons for Building a Relevant EA Program

Four lessons can be drawn from these three cases on how to make EA a relevant and important initiative.

Lesson 1: Take Advantage of Crisitunities The word “crisitunity,” coined by Homer Simpson, highlights that, under the right circumstances, crises bring opportunities. In both California and Michigan, taking advantage of crisitunities—opportunities arising from radical IT changes—allowed their EA programs to become relevant to their agendas. In Michigan, the EA team led the efforts to develop in-house cloud computing solutions to further support the state’s IT consolidation efforts. In California, the EA program developed reference architectures that assisted agencies in creating business capabilities as outlined by the governor’s transformation plan. A crisitunity can be a great boost to EA development. Implementing an EA program could impact both technical and non-technical aspects of a business, thereby transforming a company’s IT environment. During crises when performance plummets or market pressures intensify, an EA program can drive the transformation needed to leverage the organization’s IT investments so it can create new business capabilities or do more with less.24 In the context of EA, crisitunities arise not just from radical IT structural changes (e.g., departmental reorganization), but also from 24 Bradley, R. V., Pratt, R. M. E., Byrd, T. A. and Simmons, L. L. “The Role of Enterprise Architecture in the Quest for IT Value,” MIS Quarterly Executive (10:2), 2011, pp. 73-80.

disruptive technologies that impact business models (e.g., cloud computing, business analytics, e-commerce). Advocates of EA can use those windows of opportunity to increase the relevance of EA to their organizations. There are three steps to “sell” the advantages of leveraging a crisitunity. First, explain to business leaders how EA can help smooth the path of radical IT changes. Use specific examples, including success stories from other organizations. California used best practices and presentations from consultants and other states to gain support for its EA program. Second, become actively involved in the planning and execution of radical IT changes. Michigan’s EA team led the development of cloud-based solutions rather than passively waiting for changes. Third, provide training and support to help business units implement IT changes. Michigan and California provided training modules and tools to help agencies implement new systems.

Lesson 2: Increase EA Visibility Not all EA programs need a crisitunity to be relevant to their organizations. If your EA program is well established, do not be afraid to innovate and update your EA frameworks and standards as new technologies are introduced. New EA practices are continuously being developed, and business directions change. These changes require frequent EA updates, which would increase the visibility of the EA program and adjust it to the changing needs of the organization. Two lessons stand out on how organizations use EA updates to increase the relevance of EA. The first is that, when introducing updates, EA teams must recognize that the goal is being relevant, not being perfect. The Kansas EA program was initiated in 1998 and has gone through more than 12 updates in the following 17 years. The EA frameworks were revised and updated as the understanding and concepts of EA evolved toward a more holistic and businessoriented approach. As a result, state leaders (the governor) and business unit managers understood the relevance of the EA program. The second lesson is that, although updating EA programs is useful, architects must remember who the end user is. In Kansas, each update of December 2015 (14:4) | MIS Quarterly Executive

177


KITA resulted from agency feedback and specific issues that the IT Architecture Review Board identified. KITA has been updated to incorporate components from other public EA frameworks to encourage information sharing across agencies, to include business modeling tools that better aligned technologies and business objectives, and to add specific sub-architectures that were important to agencies (e.g., security, electronic records management). Focusing on the end user keeps EA programs relevant.

Lesson 3: Fix Current Pains Before Building Future Gains Whether enterprise architects take advantage of a crisitunity or use frequent updates to increase the relevance of an EA program, it is critical that they first address current threats to organizational performance before building new capabilities. When we asked enterprise architects why EA was important, many highlighted EA’s technical superiority (e.g., standardized systems, lower development time) or its greater potential (e.g., creating a service-oriented environment). Unfortunately, these positive technical characteristics mean little to managers who are dealing with business crises. Successful EA teams engage business managers’ attention by relating to their existing problems. Michigan targeted agencies’ needs for reliable and cheap hosting services through EA-driven cloud computing solutions. California identified best practices for common IT problems areas for agencies, thus saving them time and resources. Addressing current crises allows an EA program to stay relevant to the needs of user groups. This means the EA team must identify its user groups, their relevant business problems and how to appropriately address them. As expressed enthusiastically by an architect, “without anybody doing EA, it will remain only a good concept on paper.” Generally, each type of user group will have different interests and needs. For senior executives (e.g., CEO, CFO), their concerns are high-level issues such as budget deficits, costefficiency and organizational competitiveness. EA advocates should explain how EA contributes to the overall business model and strategic goals (e.g., creating business analytics capabilities). Explaining EA in terms of technical benefits such 178


as interoperability or lower development time would be less appealing to senior executives. The primary concern of business unit managers is operational efficiency. EA teams should explain EA benefits to them by using specific business unit processes or success stories from other units. Describing the technical benefits of EA is not necessary unless business unit managers specifically ask about them. IT teams (e.g., developers in business units) are interested in IT efficiency and technical knowhow. In this case, EA teams can explain EA using technical artifacts (e.g., EA transition map, valueadded models). Additionally, IT teams should be given flexibility on how to implement EA in local contexts.

Lesson 4: Use Architects Who Also Have People Skills Lessons 1 to 3 show how to make EA programs relevant to existing organizational problems and challenges. However, much of an EA program’s success rests on the shoulders of EA advocates. Frequently, these are enterprise architects who directly communicate and work with business units to explain concepts and mobilize actions. User groups will not be convinced of the benefits of EA by hearing about perfect frameworks or sophisticated artifacts. To make EA understandable and relevant to user groups, enterprise architects must also have the ability to engage in persuasive and targeted communications. To achieve this, architects need people skills so they can connect with their user groups. Communication training and positive enforcement play a crucial role in developing these skills. Also, it is critical that your EA team also includes people with business backgrounds and good communication skills. They can act as role models for others in the team. It follows that EA managers need to rethink their hiring process. Instead of hiring architects just with technical skills, managers should bring in people with both technical and people skills. They can build bridges to the user groups.

Concluding Comments

The enterprise architecture field has evolved into a sizable community with numerous publications, interest groups, conferences and misqe.org | © 2015 University of Minnesota


advocates. Yet, the issue of how EA delivers business outcomes and becomes a relevant organizational practice remains. This is especially true for public-sector enterprises, where cost is always a major concern. Based on EA implementation cases in U.S. state governments, we have identified that, in addition to the common maturing approach to EA, organizations can take advantage of crisitunities arising from radical IT changes to adopt the refreshing or bundling approaches. Given the increasing pressure for transformation driven by financial crises and market pressures, the refreshing and bundling approaches provide managers, private and public-sector alike, with new ways to increase the relevance of their EA programs. Regardless of the approach adopted, we recommend managers adopt the lessons identified from the cases: exploiting opportunities from crises, providing frequent updates based on feedback, relating to the current needs of the user groups and using architects with people skills as well as technical skills to communicate the relevance of EA and increase the chances of success.

in 24 states were compared to identify common themes.

About the Author

Quang Bui Quang “Neo” Bui ([email protected]) is an assistant professor at the MIS, Marketing and Digital Business department, Rochester Institute of Technology. He received his Ph.D. from Bentley University. His research focuses on innovation adoption issues and diffusion processes, particularly IT management innovations (e.g., outsourcing models, shared services models, enterprise architecture). His work has been published in Journal of Management Information Systems (JMIS) and Information & Management and in the proceedings of the International Conference on Information Systems (ICIS) and the Academy of Management Annual Meetings.

Appendix: Research Method

This study is based on EA program data collected from the websites of 50 U.S. state governments. From each website, a team of researchers identified whether the state had a formal EA program. If so, the researchers collected all publicly available documents (e.g., EA documents, annual reports and academic studies). Interviews also were conducted in four states. Only states with a formal EA program were selected for the next phase of the research. In each of these states, a researcher identified the elements of its EA program in terms of the framework used, key features, methodologies, enforcement mechanisms and governance structures. To understand the evolution of the program, the researcher also collected any relevant cached webpages or documents from the web archive database (https://archive.org/ web/). The histories of EA adoption and usage


179