ISSN 2166-6768 (print) ISSN 2166-6792 (online)

Journal of

Enterprise Architecture 2016, Volume 12, Number 1 From the Editor – About this Issue Leonard Fehskens Article: How about Strategy? – A Survey into the Pitfalls of Strategic Alignment Melissa Roelfsema, Adina Aldea, Marc Lankhorst, and Henry Franken Short Subject: Inter-Enterprise Architecture Yan Zhao Short Subject: Enterprise Architecture Manifesto: Defining Guiding Principles Matt Fishbeck Article: The History of Enterprise Architecture: An Evidence-Based Review Svyatoslav Kotusev

Journal of Enterprise Architecture® President, Association of Enterprise Architects: Steve Nunn Interim Chief Executive Officer, Association of Enterprise Architects: Allen Brown Chief Editor: Leonard Fehskens, Association of Enterprise Architects Production Editor: Cathy Fox, The Open Group Associate Editors Tyson Brooks, PhD, PMP

William W. Krauter, PhD

Co-Director, Syracuse University

Senior Architect, Lockheed Martin Corporation

Dick Burk

Haiping Luo, PhD

Enterprise Architect

International Trade Administration, US Dept. of Commerce

Brian Cameron, PhD

Stephen Marley, PhD

Professor & Executive Director, Center for EA, PA State University

Chief Technologist, Harris Corporation

Gary Doucet

George Paras

Human Resources and Skills Development Canada

Managing Director, EADirections

Robert Ellinger, PhD

Pallab Saha, PhD

Enterprise Architect

Professor of Information Systems, National University of Singapore

Steve Else, PhD

P. Kathie Sowell

CEO, EA Principals & Adjunct Professor, University of Denver

President, Custom Enterprise Solutions, LLC/SowellEAC

William A. Estrem, PhD

Eskil Swende

President, Metaplexity Associates, Inc.

Partner IRM Sweden, President of DAMA Scandinavia

Jups Heikkilä, PhD

Torben Tambo

Professor, University of Turku

Associate Professor, Aarhus University Institute of Business & Technology

Leon Kappelman, PhD

Tim Westbrock

College of Business, University of North Texas

Managing Director, EADirections

About the Journal: The Journal of Enterprise Architecture (JEA) is published by the Association of Enterprise Architects, 44 Montgomery Street, Suite 960, San Francisco, CA 94104, Tel: +1 415 374-8280, Fax: +1 415 374-8293, www.globalaea.org. The JEA is a peer-reviewed international publication for the EA community. Four issues are published each year. The JEA supports the global practitioner community of interest through the publication of articles that promote the profession of enterprise architecture, and deals with issues regarding practices and methods, case studies, and standards at the national and international levels. The views expressed in JEA articles are those of the respective authors, and not necessarily those of the publisher, the Chief Editor, the associate editors, or the Association of Enterprise Architects (AEA). Copyright: © 2005-2016 Association of Enterprise Architects. The reproduction, storage, or transmission of JEA articles or other content is prohibited without prior permission in writing from the JEA Chief Editor, who can be contacted via email at [email protected]. ®

®

Trademarks: Association of Enterprise Architects , the AEA logo, and Journal of Enterprise Architecture are registered trademarks of the Association of Enterprise Architects. Article Submissions: Authors may submit properly formatted manuscripts to the JEA Chief Editor at [email protected] for publication consideration. Author submission guidelines are available on the AEA website at www.globalaea.org. Copyright of all accepted articles and other published content is transferred by the author to the JEA upon notification of acceptance by the JEA Chief Editor. Subscription: Available to AEA members. The annual cost of AEA membership is US$75.00. To join, please refer to www.globalaea.org. Online edition: no charge access for AEA members. Back Issues: All back issues of the JEA are available in electronic form, and can be accessed online by AEA members. Libraries can apply for access by contacting the AEA. 2

© 2016 Association of Enterprise Architects – Volume 12, No. 1

Contents From the Editor – About this Issue ......................................................................................................................................... 4 Article: How about Strategy? – A Survey into the Pitfalls of Strategic Alignment .................................................................. 7 Short Subject: Inter-Enterprise Architecture ........................................................................................................................ 20 Short Subject: Enterprise Architecture Manifesto: Defining Guiding Principles ................................................................... 24 Article: The History of Enterprise Architecture: An Evidence-Based Review ...................................................................... 31

© 2016 Association of Enterprise Architects – Volume 12, No. 1

3

From the Editor – About this Issue Leonard Fehskens Welcome to the March 2016 issue of the Journal of Enterprise Architecture. First, this issue omits two regular features – a book review and my “Len’s Lens” article. They will resume in the next issue. Their subjects (respectively, “Metaphors We Live By”, by George Lakoff and Mark Johnson, and “What Can We Know About Enterprise Architecture, and How Can We Know It?”) both lead into philosophical explorations of the foundations of Enterprise Architecture, and I believe this issue has enough thought-provoking material without them. We open with a topical article in which Melissa Roelfsema, Adina Aldea, Marc Lankhorst, and Henry Franken share the results of a survey on strategic alignment.

As always, I urge you to consider contributing to the Journal. You don’t have to write something to do so – you can suggest something you’ve seen published elsewhere that you think would be of value to the EA community if it were featured in the JEA. If you do want to write something original, we’re now accepting nonpeer-reviewed short subjects (a few pages) and articles (a half dozen or so pages), as well as the traditional peer-reviewed longer articles. We’re especially interested in business and other forms of enterpriserelated material, as well as technological topics. Finally, you can always send us your own “Four Questions”, suggest someone you’d like to have submit their “Four Questions”, volunteer to “Talk Shop” with me, or suggest someone you’d like me to “Talk Shop” with.

We have two short subjects: “Inter-Enterprise Architecture” by Dr. Yan Zhao, and “Enterprise Architecture Manifesto: Defining Guiding Principles” by Matt Fishbeck. Dr. Zhao proposes a formalization of the increasingly frequent observation that enterprises don’t exist in isolation; they unavoidably interact with other enterprises, and these interactions must be addressed as an integral part of their Enterprise Architectures. Mr. Fishbeck applies the idea of architectural principles to the practice of Enterprise Architecture, an example of what is often inelegantly expressed as “eating our own dog food”. The issue closes with a very well-researched and wellargued article on the historical provenance of the conventional wisdom on Enterprise Architecture, “The History of Enterprise Architecture: An Evidence-Based Review” by Svyatoslav Kotusev. This article challenges some cherished elements of the conventional wisdom on the history of Enterprise Architecture, and I expect it will provoke some heated discussion. I ask the community to please keep this discussion civil and evidence-based.

4

© 2016 Association of Enterprise Architects – Volume 12, No. 1

Visit the AEA website at www.globalaea.org

Call for Papers The Journal of Enterprise Architecture is accepting article submissions for its future issues. Research and best practice articles are sought on enterprise architecture-related topics, including: Case Studies, Configuration Management, Culture, Documentation Evaluation, Frameworks, Governance, Implementation, Maintenance Methodologies, Taxonomies, Theory, Training, Tools, Use, Value Please send articles to the JEA Chief Editor at [email protected]. Author submission guidelines can be found on the AEA website at www.globalaea.org.

© 2016 Association of Enterprise Architects – Volume 12, No. 1

5

6

© 2016 Association of Enterprise Architects – Volume 12, No. 1

Article How about Strategy? – A Survey into the Pitfalls of Strategic Alignment Melissa Roelfsema, Adina Aldea, Marc Lankhorst, and Henry Franken

Abstract The prospects are grim for organizations that manage organizational change through a new strategy. In the Strategic Alignment survey, conducted in the second quarter of 2014, 177 managers, consultants, architects, IT specialists, and others were asked about the strategic alignment efforts and experiences of their organization. This article presents findings concerning several aspects of the strategy process. Results from the Strategic Alignment survey suggest that organizations still experience significant difficulties during development and implementation of their strategies. Especially, ineffective communication and insufficient organizational capabilities are pitfalls that prevent organizations from reaching strategic alignment. Keywords Strategic alignment, strategic alignment survey, strategy development, strategy implementation, organizational change

INTRODUCTION In a constantly changing environment in which competition and globalization are intensifying, it is increasingly important for organizations to manage and survive change (Amagoh 2008). Organizations need to keep up with the fast-changing and increasing demands of customers. The ability to adapt rapidly and to remain agile is imperative. A strategy determines the decisions and courses of action that organizations take to achieve competitive advantage and to survive change (Mintzberg et al. 2009). A strategy needs to be developed and implemented in order to successfully direct the organization from their current position to a future desired state. Previous studies indicate that numerous organizations were not successful in completing this strategy process (Kaplan & Norton 2005). Formulating a consistent strategy is a daunting task; making that strategy work is even more difficult (Li et al. 2010). It seems that organizations fail when trying to implement strategic choices, and thus fail to realize their strategic vision. The fit between the business and IT is an important example of strategic alignment (Luftman 2003). More specifically, strategic alignment is the ability to create synergy between the position of the organization within the competitive environment and the design of the appropriate structure to support the execution (Baker & Jones 2008). This should be done in such a way that a strategy is developed while considering the supporting structure (IT) and that operational goals and actions are in line with the overall strategy (business). Strategic alignment is an ideal state above all; it is a process of © 2016 Association of Enterprise Architects – Volume 12, No. 1

continuous adaptation and change Venkatraman 1993).

(Henderson &

To get a better understanding of why organizations often fail to reach strategic alignment it is essential to understand the variables that affect strategic alignment. There are various variables which can have an impact on strategic alignment. These variables are grouped into four main categories: the strategic alignment indicators, culture and shared beliefs, organizational capabilities, and communication (Beer & Eisenstat 2000; Luftman 2000; Higgins 2005; Hrebiniak 2006; Neilson, Martin & Powers 2008; Elquist LoRé 2012). A survey is used to examine which variables, found in the literature, affect the strategic alignment efforts of organizations.

Figure 1: Variables Influencing Strategic Alignment

7

Survey Methodology

The Strategic Alignment survey is created to get a better understanding of the strategic alignment efforts and experiences of organizations. Especially, the way in which organizations move from strategy development to strategy implementation is examined. The questionnaire is designed to gather information about the problems experienced by organizations during the strategy process. The reasons that cause organizations to fail at developing and implementing their strategies are investigated. The respondents were reached through collaboration with The Open Group, the Association of Enterprise Architects (AEA), and the Nederlands Architectuur Forum (NAF). The Strategic Alignment survey asked 177 managers, consultants, architects, IT specialists, and others about the strategic alignment efforts and experiences of their organizations.

These organizations did probably not reach a state of strategic alignment. The amount of organizations that might have reached a state of alignment is relatively small; only 5% did not experience any problems during the development and implementation of their strategies. Remarkable, none of organizations was able to implement a strategy without problems when problems had already occurred during development. A strategy which is not properly developed is doomed to fail during the implementation phase. From the organizations that successfully developed a strategy, some experienced problems during the implementation of that strategy.

INSIGHTS AND FINDINGS Problems in Strategy Development and Strategy Implementation

Organizations might experience a variety of problems during the strategy process; for example, some have insufficient communication. In general, more than half of the organizations experience problems during the development of their strategies. Strategy formulation is a challenging task for many organizations. However, implementing a developed strategy is even more difficult. About 75% of the organizations experience problems during the implementation of the strategy. This indicates that organizations have much to improve in the strategy process, especially during the strategy implementation phase. Nonetheless, the focus should not only be on the implementation phase; problems that occur during the development of strategies might cause problems during strategy implementation.

Figure 3: Problems During Development and Implementation Involvement in Developing and Implementing Strategies

Strategic long-term plans are turned into reality by setting operational short-term objectives in the strategy implementation phase. Implementation is about the translation of strategic goals into executable objectives. During this implementation phase a large part of the organization is involved. About 67% of the respondents indicate that they were often involved during implementation. “A larger part of the organization is involved during the implementation of strategies than during the development.”

Figure 2: Identification of Problems During Strategy Development and Implementation “52% of the organizations experience problems both during the development and during the implementation of their strategies.”

Of the organizations that experience problems during the development of strategies, about 52% also experienced problems during the implementation of a strategy.

8

Strategy development is about formulation of a strategy; i.e., the strategic plans and goals. In this phase a much smaller part of the organization is involved. Of the respondents, 33% indicate that they were often involved in the development of the strategies. Consequently, more people are involved during the implementation of strategies than during the development. People involved during the development do not identify problems in the strategy process as often as the people who are not involved. They usually feel empowered and involved since they have ownership and responsibility for the success of the strategy. The people who are not

© 2016 Association of Enterprise Architects – Volume 12, No. 1

involved during strategy development experience more problems because their interests might not have been considered or heard. The involvement of the majority of the organization’s employees during development is essential for organizations to avoid difficulties during the strategy process.

Figure 4: Percentage of Respondents Involved During Development or Implementation

Vice versa, the respondents involved during the implementation of strategies more frequently identify problems in the strategy process than those that are not involved. Those that are involved during the implementation phase know which problems occur during implementation and what has gone wrong during development. Consequently, the people uninvolved during development but involved during implementation most frequently experience problems. Feedback from

the people involved during strategy implementation should get back to the strategy development team. It is important that those voices are heard and taken into consideration by organizations. Involvement of Departments in the Strategy Process

In the strategy process there are various departments involved at different phases. In a state of strategic alignment there should be a synergy between the business and IT. Consequently, a strategy should not be developed without considering IT and a strategy should not be implemented without involving the business. However, business departments such as Finance, Legal, Marketing & Sales, and R&D are more involved during development than during implementation. Information Technology (IT) and operational departments such as Portfolio Management, Enterprise Architecture, and Program and Project Management (PPM) are more frequently involved during implementation. Especially PPM and IT are more frequently involved when strategy is already developed, thus when the strategy needs to be implemented. For a proper strategy process organizations should not forget to consider their supporting structure and involve departments such as IT and PPM.

Figure 5: Percentage of Disciplines Involved During Development or Implementation

Problem Identification by Function Groups

Within the organization there are different function groups which are concerned with the development and implementation of strategies. These are function groups such as management, consultants, architects, IT specialists, and others from departments such as R&D © 2016 Association of Enterprise Architects – Volume 12, No. 1

and HR. A distinction is made between these function groups to determine whether they identify problems differently during development and implementation. “58% of management identifies problems during strategy implementation compared to 83% of the architects.”

A smaller part of the managers identifies problems during strategy development and during strategy 9

implementation than the other function groups. Of the managers surveyed, almost 46% identify problems during the development of strategies, while about 70% of the others notice problems during the development phase. Moreover, a far smaller part of management identifies problems during implementation (58%) compared to the amount of architects (83%). The fact that management does not identify the problems to the

same extent as the other function groups could have several causes. Managers may have a different perspective or look at the bigger picture in which the problems experienced by, for instance, an IT specialist are less significant. Apparently, there is a difference in how the function groups perceive problems which might cause frictions between these function groups.

Figure 6: Differences in Problem Identification by the Various Function Groups

Use of Strategy Techniques and Methods in the Strategy Process

There is a wide range of techniques, methods, models, frameworks, and tools which organizations can use in their strategy process. Development and implementation can be supported by several of these techniques. In the current environment in which organizations often fail to develop or implement a strategy it is remarkable that a large part of the organizations (52%) never or sporadically use strategy techniques.

the techniques that are available. The results show that management is more hesitant to use software tools to support the development and implementation of strategies. A smaller amount of the surveyed managers (33%) immediately agree to the use of such a tool than the other function groups. Consultants (51%) and IT specialists (53%) are more confident about the use of such a software tool and indicate that they would certainly use it.

Figure 8: Willingness to Use Software Tools to Support the Strategy Process

Figure 7: Use of Strategy Techniques to Support the Strategy Process

It is surprising that about 90% of the organizations are willing to use a software tool to support the development and implementation of strategies; at least if a good one is available. It appears there is a barrier to the use of strategy techniques or methods to support the strategy process. Organizations are willing to use a strategy technique or tool but a large fraction (often) do not use 10

“52% of the organizations do not (often) use strategy techniques to support the strategy process, while 90% is willing to consider it.”

About 80% of the organizations that do use strategy techniques use the SWOT analysis to support the development of strategies. The SWOT analysis is one of the most popular methods to analyze the environment of an organization. Almost 75% of the organizations use a business case to motivate the value of a project in the context of a strategy. So, the SWOT analysis and the business case are used by most of the organizations © 2016 Association of Enterprise Architects – Volume 12, No. 1

while other techniques and methods are used less frequently. Various frameworks or methods, techniques, and tools are mentioned as additional support for the development and implementation of strategies. Of the organizations ® surveyed a large part uses the TOGAF framework, a

method for designing and implementing Enterprise ® Architecture (EA). In addition, the ArchiMate language is used as a modeling language for EA. There was a large group of architects that participated in this survey (34%) which might explain the mentioning of EA methods or techniques to support the strategy process.

Figure 9: Percentage of Strategy Techniques Used During Development and Implementation

Figure 10: Percentage that Identify Each Indicator of Strategic Alignment as a Problem

THE PROBLEMS IDENTIFIED IN THE STRATEGY PROCESS In this article the factors which influence the strategy process are grouped into four main variables. The results of the survey show which factors are experienced as significant problems in the strategy process. Strategic Alignment Indicators

Strategic alignment indicators are the indicators which are specific to strategic alignment; i.e., the indicators mentioned in the literature regarding strategic alignment. In order to reach strategic alignment, the development © 2016 Association of Enterprise Architects – Volume 12, No. 1

phase and the implementation phase should be intertwined. The data shows that more than half of the organizations do not view strategy development and strategy implementation as an intertwined process. These organizations might have difficulties involving the supporting structure (e.g., IT) during development and the business during implementation, and therefore struggle to reach alignment. In addition, organizations struggle to involve the concerns and interests of the majority of the organization during development. However, most of the organizations do consider the organizational resources and capabilities during strategy development. They recognize the importance of the

11

characteristics of the organization which might limit the ability to successfully develop and implement a strategy. A large part of the organizations define actions according to strategic plans during implementation; they recognize that actions should contribute to the strategic goal(s). Culture and Shared Beliefs

Culture and shared beliefs are about the mindset within the organizations regarding strategic changes. Many organizations experience conflicting priorities regarding reaching strategic goal(s) which can make the development and implementation of strategies

challenging. If there is no agreement regarding priority of goals it is difficult to determine how to use the limited resources of an organization. Except for conflicting priorities, there are no significant problems with culture and shared beliefs. About half of the organizations have a culture in which there is willingness to change. A relatively large part of the organizations recognize the contribution of individuals to the development and implementation of a strategy. The main recommendation regarding culture and shared beliefs is for organizations to focus on resolving conflicting priorities.

Figure 11: Percentage that Identify Each Indicator of Culture/Shared Beliefs as a Problem

Organizational Capabilities

Organizational capabilities are about the ability of the organization to create a strategy and to execute its strategic vision. Capabilities are not always sufficient; for more than half of the organizations the developed strategy is not in line with the existing information systems. Organizations might need to make unexpected investments to improve the existing information systems or (re)adjust their initial strategy to fit their current capabilities. Some organizations do not translate the long-term strategic goals to short-term objectives or

clear actions. Without these objectives it is difficult to determine the short-term direction. In general, the organizations are able to monitor and measure the process and performance of the strategy, employees have the right competencies, and management is able to motivate strategic decisions. The other variables which are not considered as significant problems are mentioned in Figure 12. Concerning the organizational capabilities, it is recommended that existing information systems are considered during strategy development, and long-term strategic goals should be translated into clear short-term actions.

Figure 12: Percentage that Identify Each Indicator of Organizational Capabilities as a Problem

12

© 2016 Association of Enterprise Architects – Volume 12, No. 1

Communication

Communication is concerned with creating understanding and awareness about the strategy. While communication does not have the largest impact on the strategy process, it is a common and well-known problem. A relatively large part of the organizations have not made the individual responsibilities and the impact of the strategy clear to their employees. About 45% of the organizations have employees who do not understand the strategy, which could lead to significant problems during implementation. Employees often have

no understanding of the expected actions and no access to information about strategic plans. There is unclear communication of the strategy for 36% of the organizations. The quality of the communication leaves something to be desired since for some of the organizations the communication is inaccurate, too late, or infrequent. However, 56% do have a defined and official strategy. Apparently, a defined and official strategy is present but not communicated sufficiently. Organizations should focus on creating understanding and on ensuring the quality of the information.

Figure 13: Percentage that Identify Each Indicator of Communication as a Problem

Figure 14: The Ten Most Significant Problems Identified in the Strategy Process © 2016 Association of Enterprise Architects – Volume 12, No. 1

13

The Ten Most Significant Problems in the Strategy Process

From the factors mentioned above, the ten most significant problems can be distinguished. A large fraction of the organizations are not able to prevent conflicting priorities regarding reaching strategic goal(s). These conflicting priorities are the most significant difficulty for organizations in the strategy process. Conflicting priorities can seriously restrain strategic transformations and the implementation of a strategy. “64% of the organizations have conflicting priorities within the organization when it comes to reaching the strategic goal(s).”

A majority of the organizations still see strategy development and strategy implementation as separate processes, following strategic alignment they ideally form one intertwined process. About 51% have a strategy which is unsupported by the existing information systems, which means that new information systems should be created to make implementation successful. Slightly less than half of the organizations do not involve the majority of the organization during the development of a strategy. When the interests of the majority of the organization are not considered it can cause difficulties during implementation. Organizations experience difficulties with communication during the strategy process. Several communication problems have been identified by some of the organizations, such as unknown individual responsibilities, lack of understanding of strategy, unknown impact of the strategy, lack of understanding about needed actions, insufficient access to information about strategic plans, and unclear communication. These communication problems form serious problems for organizations managing strategic changes. Constraints of Strategic Alignment

The previous findings show which problems organizations experience in the strategy process. However, it does not indicate how these problems influence the extent of strategic alignment. In order to measure the impact on strategic alignment a distinction is made between organizations with a state of strategic alignment and organizations without strategic alignment. This distinction is made by the amount of problems they experienced during development and during implementation. The extent to which organizations with strategic alignment identify the above-mentioned indicators as problems is compared with the extent to which organizations without strategic alignment identify the above mentioned indicators as problems.

14

Variables identified as a problem by both groups of organizations have no influence on strategic alignment; i.e., these variables are not constraints to strategic alignment. Variables identified more frequently by organizations without strategic alignment as a problem than by organizations with strategic alignment have an impact on strategic alignment; i.e., these variables are constraints. The constraint that affects strategic alignment the most is an unknown impact of the strategy on employees. Organizations that are not aware of the consequences of a strategy on their employees will struggle to reach strategic alignment. Another significant constraint is no understanding about the strategy by the majority of the organization. Without a proper understanding of the strategy, implementation becomes a challenge. These two constraints which have a significant effect on strategic alignment both concern problems of communication. As explained earlier, strategic alignment is influenced by several indicators of communication. Other significant constraints concerning communication are: unclear understanding of expected actions, unknown individual responsibilities, and no access to information about strategic plans. “Communication has the largest impact on strategic alignment; the main constraint is an unknown impact of the strategy on employees.”

Organizations that do not translate their long-term strategic goals into short-term objectives negatively influence the level of strategic alignment. This translation is of importance to make sure that the execution of strategic plans becomes possible. Without short-term objectives it is challenging to determine what has to be changed in order to achieve strategic transformations. A similar constraint is the insufficient translation of strategic goals into clear actions. These constraints pertain to organizational capabilities. An additional constraint regarding organizational capabilities is a lack of measurement of the impact of the strategy on the organization’s performance. Without measurement it is unclear whether a strategy creates shareholder value. Only a few indicators of culture and shared beliefs have a significant effect on strategic alignment, such as conflicting priorities within the organizations regarding strategic goal(s) and uncoordinated strategic change. Strategic alignment indicators have the weakest impact on strategic alignment, as can be seen in Figure 15. Apparently, these indicators of strategic alignment do not represent the full extent of strategic alignment. Our findings suggest that the strategic alignment indicators, as identified in the literature, are actually not a good determinant of strategic alignment.

© 2016 Association of Enterprise Architects – Volume 12, No. 1

Figure 15: The Ten Most Significant Constraints to Strategic Alignment

Contrary to the ten most significant constraints, there are variables with no significant effect on the extent of strategic alignment. A similar percentage of organizations with and without strategic alignment experience (or do not experience) these problems, indicating that it is not a constraint to strategic alignment. Development and implementation are not seen as an intertwined process by a large part of the organizations with and without strategic alignment. Consequently, the

extent of strategic alignment is not influenced by this indicator. The same applies to uninvolved management during strategy implementation. While organizations without strategic alignment experience this problem more often than those with strategic alignment, the difference is too small to have an effect on strategic alignment. Strategic alignment is not influenced by the variables mentioned in Figure 16.

Figure 16: A Similar Percentage of Organizations With and Without Strategic Alignment Experience Each Indicator as a Problem © 2016 Association of Enterprise Architects – Volume 12, No. 1

15

The Way Organizations Move from Development to Implementation

There are some additional interesting findings about the way organizations move from development to implementation. Organizations that define the boundaries of strategic transformations have various guidelines such as budget, scope of the strategy, timeframe, by management, and by objectives. The

intent behind strategic plans is communicated mainly by management through the intranet, meetings, or channels such as presentations, emails, and newsletters. The organizations that align personal values and goals to a common (strategic) goal mostly use personal target objectives or define the expected personal values. They use training and education to make sure that values and goals are aligned, or appraisals in the form of bonuses.

Figure 17: The Way Organizations Move from Development to Implementation

Interdependencies between stakeholders are primarily recognized by a stakeholder interdependencies matrix, by Project Portfolio Management, or by stakeholder analyses. However, many recognize interdependencies in an ad hoc or an informal way. Necessary changes and actions are defined through the use of project or program management. Management is involved when the necessary changes are defined and roadmaps, discussions, gap analyses, or workshops are used. The contribution of a project to reaching the strategic goals is communicated through the intranet or through the use of newsletters or emails. Meetings and presentations are also held in order to communicate this contribution. CONCLUSION Nowadays, there is a demand for change since an environment has developed in which customers expect a swift delivery of products and services with seamless user experience. Competitors born in the digital age take their advantage through rapid delivery of digital products and services. Organizations need to change their business model as in a few years every organization will be a digital organization. The capability to change rapidly and remain agile is imperative. Subsequently, management wants to satisfy stakeholders, create sustainable business revenue, and effectively execute their constantly renewed strategies. Moreover, they want to enable business transformations that are agile and to make fast business improvement while reducing the costs significantly. In a time where 16

most organizations fail to develop and implement a strategy it is crucial to successfully manage strategic change. Management needs to take into account the constraints to strategic alignment such as an unknown impact of strategy or lacking translation of long-term strategic goals. There is a need for strategy rationalization and strategy implementation through consistent modeling, and for sufficient communication to all stakeholders involved. This study illuminates the areas and problems on which management should focus if they want to survive upcoming necessary changes. EVIDENCE In total, 177 people participated in the Strategic Alignment survey, which consisted of: 33 managers = 18.9% 41 consultants = 23.4% 59 architects = 33.7% 19 IT specialists = 10.9% 23 others = 13.1% These participants mostly worked for large organizations with more than 500 employees. About 73% of the organizations included in this survey have more than 500 employees. About 12% of the organizations are small organizations with less than 50 employees.

© 2016 Association of Enterprise Architects – Volume 12, No. 1

University of Twente, where she is assigned as a PhD student. Adina has studied Business Administration at the University of Twente, the Netherlands, where she obtained her Masters’ degree.

Figure 18: The Size of Organizations Involved in the Survey

There is an equal distribution of the industries in which the organizations are active. Some of the largest industries are the information and communication industry in which 25% of the organizations are active and the finance and insurance industry in which 21% of the organizations are active. Most of the organizations have an office located in Western Europe (71%), about 37% in Northern Europe, and almost 25% in North America. RECOMMENDED READING A. Aldea: Strategy Analysis and Design, BiZZdesign Academy BV (2014). For more information contact BiZZdesign at [email protected]. A. Aldea, M.E. Iacob, D. Quartel, H. Franken: Strategic Planning and Enterprise Architecture, pp.1-8, in Enterprise Systems Conference (ES), IEEE (2013). J.N. Luftman: Assessing Business-IT Alignment Maturity, pp.150, Communications of AIS 4(14) (2000). B. van Gils, S. van Dijk: The Practice of Enterprise Architecture: Experiences, Techniques, and Best Practices, BiZZdesign Academy BV (2014).

ABOUT THE AUTHORS Melissa Roelfsema MSc is a Junior Advisor at InnoValor, working on subjects such as business models, value creation, risk management, and strategy models. For her Masters’ thesis, conducted at BiZZdesign in collaboration with the University of Twente, she made a contribution to the method for improving the gap between business and IT by exploring the pitfalls to strategic alignment. Melissa has studied Business Administration at the University of Twente, the Netherlands, where she obtained her Masters’ degree. Adina Aldea MSc is a Junior Research Consultant at BiZZdesign, assigned to the R&D department. Here she works on developing a method for improving the gap between business and IT, with the help of strategy models, capability-based planning, portfolio management, and Enterprise Architecture. She is working on this topic also in collaboration with the © 2016 Association of Enterprise Architects – Volume 12, No. 1

Marc Lankhorst MSc PhD is Managing Consultant and Service Line Manager Enterprise Architecture at BiZZdesign. As an internationally recognized thought leader on EA, he guides the development of BiZZdesign’s portfolio of services, methods, techniques, and tools in this field. In the past, Marc has managed ® the development of the ArchiMate language for EA modeling, now an Open Group standard. Marc is a ® TOGAF 9 Certified architect, and holds an MSc in Computer Science from the University of Twente and a PhD from the University of Groningen in the Netherlands. Henry Franken MSc, PhD is co-founder and CEO of BiZZdesign. BiZZdesign offers complete and integrated solutions (software tools, methods, consultancy, and training) to design and improve organizations. BiZZdesign offers solutions including training courses and tools that conform to Open Group standards. Henry is responsible for the strategic international growth of BiZZdesign. Moreover, Henry is responsible for the research and innovation at BiZZdesign. In this capacity, the alignment with and contribution to open standards is ® key. Henry is chair of The Open Group ArchiMate Forum. Henry is an invited speaker on business architecture at many conferences. REFERENCES A. Aldea, M.E. Iacob, J. van Hillegersberg, D. Quartel, ® H. Franken, L. Bodenstaff: Modeling Strategy with ArchiMate , in the Proceedings of the 30th ACM/SIGAPP Symposium on Applied Computing (SAC) (2015). F. Amagoh: Perspectives on Organizational Change: Systems and Complexity Theories, pp.1-14, The Innovation Journal: The Public Sector Innovation Journal 13(3) (2008). J. Baker, D. Jones: A Theoretical Framework for Sustained Strategic Alignment and an Agenda for Research, pp.1-30, Sprouts: Working Papers on Information Systems 8(16) (2008). M. Beer, R.A. Eisenstat: The Silent Killers of Strategy Implementation and Learning, pp.29-40, Sloan Management Review (2000). C. Elquist LoRé: Strategic Management Process: Seven Deadly Sins of Strategy Sabotage (2012). J.C. Henderson, N. Venkatraman: Strategic Alignment: Leveraging Information Technology for Transforming Organizations, pp.472-484, IBM Systems Journal 32(1) (1993). J.M. Higgins: The Eight ‘S’s of Successful Strategy Execution, pp.3-13, Journal of Change Management 5(1) (2005).

17

L.G. Hrebiniak: Obstacles to Effective Strategy Implementation, pp.12-31, Organizational Dynamics 35(1) (2006). R.S. Kaplan, D.P. Norton: The Office of Strategy Management, pp.72-80, Harvard Business Review 83(10) (2005). Y. Li, S. Guohui, M.J. Eppler: Making Strategy Work: A Literature Review on the Factors Influencing Strategy Implementation, in P. Mazzola, F.W. Kellermanns: Handbook of Research on Strategy Process, pp.165-183, Cheltenham UK: Edward Elgar Publishing Limited (2010). J.N. Luftman: Assessing Business-IT Alignment Maturity, pp.150, Communications of AIS 4(14) (2000). J.N. Luftman: Assessing IT/Business Alignment, pp.9-15, Information Systems Management 20(4) (2003). H. Mintzberg, B. Ahlstrand, J. Lampel: Strategy Safari: Your Complete Guide Through the Wilds of Strategic Management nd (2 Ed.), Harlow, UK: Pearson Education Limited (2009). G.L. Neilson, K.L. Martin, E. Powers: The Secrets to Successful Strategy Execution, pp.60-70, Harvard Business Review (June) (2008).

18

© 2016 Association of Enterprise Architects – Volume 12, No. 1

© 2016 Association of Enterprise Architects – Volume 12, No. 1

19

Short Subject Inter-Enterprise Architecture Yan Zhao, PhD

Abstract This article introduces the notion of Inter-Enterprise Architecture (IEA) in response to the current evolution of the business environment and landscape associated with the adoption of common shared services, cloud computing, and social networking. The IEA describes the context, business environment, collaboration channels, partnership opportunities, influential components, and relationships across enterprises and business organizations in a selected business domain or service domain for a targeted enterprise or business organization. The IEA enables an enterprise or business organization to understand its position in today’s networked business world. Due to the open and dynamic nature of service adoption and collaboration, and the autonomy of current enterprise structure, culture, and operating environments, it is necessary to explore how a business should be architected across boundaries to effectively respond to the common service and collaboration environment. It is becoming more important for a business to be agile and able to incorporate collaboration elements across organization boundaries. If Enterprise Architecture (EA) is like a city plan, the IEA is more like a plan for a metropolitan area. This article discusses the subject areas for IEA to address, the impact of common service facilitation, public cloud, and social media to enterprises, the challenges, and the possible transitions necessitated by IEA adoption. Some examples will be provided as well. Keywords Enterprise Architecture, cloud computing, collaboration, common service, Inter-Enterprise Architecture, Service-Oriented Architecture, Service-Oriented Enterprise, Service-Oriented Infrastructure

INTRODUCTION

THE EVOLUTION OF THE ENTERPRISE LANDSCAPE

Businesses and the world economy are so much more interdependent nowadays due to global networking and boundary-less information flow. We can see that today’s influences on and dependencies of an enterprise often lie far beyond the enterprise boundary. The trend of common service commoditization will add the mutual dependencies of service providers, service consumers, and service facilitators. Partnership and collaboration are the essence of this emerging dynamic. The evolution of the Internet and enabling technologies encourage such changes, such as the current popular efforts of SOA, cloud computing (see References), and social networking platforms (e.g., LinkedIn, Facebook, Twitter, YouTube).

The enterprise landscape is evolving due to the shift towards a new paradigm and the new opportunities it presents. This trend is illustrated in Figure 1.

It is essential for enterprises and business organizations to understand their business context, environment, landscape, collaboration channels, partnership opportunities, influential components, and relationships across enterprises and business organizations. The Inter-Enterprise Architecture (IEA) is introduced for this purpose.

20

Enterprise Production Emphasize on Process, Maturity, Best Practice, Replaceable Resources

Small Business

Service Providers

Innovation

Infrastructure Support

Emphasize on Novelty, Uniqueness

Emphasize on Commonality, Commodity Services

Figure 1: The Enterprise Landscape Evolution

We can see that the inter-enterprise restructuring is happening to fit the new economy and the changing paradigm.

© 2016 Association of Enterprise Architects – Volume 12, No. 1

The roles and responsibilities for the players are evolving. The focuses for good-sized enterprises are more on productivity, process-driven, maturity, and industrialization with replaceable components and resources, while the tasks of innovation are moving to small companies that will likely be acquired by large companies as they mature. Infrastructure services are forming and separating from enterprise business, becoming a business itself to provide common commodity services. The IEA is helpful in identifying such services and providing corresponding descriptions for businesses, both large and small, to have a clearer picture for effective business propositions and game plans. IEA is helpful in being aware of business context, environment, mutual dependencies, collaboration, and partnership opportunities. THE NOTION OF IEA The IEA is an abstract presentation of a selected business domain, with coverage across the enterprises and business organizations in the domain, and with descriptions in terms of scope, context, environment, roles and responsibilities, structure, components, relationships, interaction mechanisms, business process flow, information flow, etc. Specifically: Scope: Describes a selected business domain or a service domain. A business domain can be healthcare, education, financial service, retail, etc. A service domain can include service providers, service consumers, and service facilitators. Business context and environment: Identify the context for the targeted enterprise/enterprises or business organization/organizations. Identify their associated business environment. Roles and responsibilities: Identify the roles and responsibilities of the players in the IEA scope. Structure, components, and relationships: Identify the structure and describe the influential components. Identify and describe the relationships between the components and to the targeted enterprise or business organization. Interaction mechanisms: Identify media, channels, and mechanisms for interaction and communications. Business process flow and information flow: Describe business and inter-business process flows, and describe business and inter-business information flows through identified media and channels. THE IEA WITH OTHER CONCEPTS AND EFFORTS The relationship of IEA with other popular concepts and efforts is illustrated in Figure 2.

© 2016 Association of Enterprise Architects – Volume 12, No. 1

The IEA is constructed above each individual Enterprise Architecture (EA), while Service-Oriented Architecture (SOA) is an architecture style and approach that can be applied to EA and IEA where appropriate (Zhao 2010). By applying SOA to EA, we have Service-Oriented Enterprise Architecture (SOEA) (Zhao 2010; Zhao 2007; Zhao 2006). To implement an SOEA, we can partition it into: Service-Oriented Infrastructure (SOI), ServiceOriented Applications (SOA), and Service-Oriented Enterprise (SOE). Cloud computing enables SOI from ® the technical point of view, while ITIL enables SOI from the management point of view. Under cloud computing, we have Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). IaaS can be implemented by the combination of virtualized and physical computing environments, though the trend is moving towards virtualization to maximize the benefits. Inter-Enterprise Architecture SOA

EA SOEA SOApps

SOI Cloud

IaaS

PaaS

Virtualization

Others SOE

ITIL SaaS

Multi-Tenant Apps & Data

Physical components

Figure 2: The Relationship of IEA with Other Concepts and Efforts

The IEA can facilitate the adoption of cloud computing by demonstrating the evolving landscape, business environment, and players for service provision, consumption, and facilitation, and demonstrating the environment and mutual dependencies for partnership and collaboration. It can help to describe inter-business structure for cloud computing adoption, either public or private. Also, it can guide the adoption of cloud computing by providing business cases, concept of operations, solution options, technical implementation options, flexibility for changes in vendors, and technologies. IEA FOR ENTERPRISE TRANSITIONS The IEA can guide an enterprise transition to the new paradigm, which enables IEA to be formed by intention instead of by accident from stove-piped implementations bounded inside each organization. It can make cloud computing and social media adoption more effective by identifying inter-business solutions and adapting to new 21

inter-business relationships and dynamics by design and by the effective usage of social media. Examples of IEA for cross-enterprise cloud service adoption include: Shopping Mall on Cloud for crossretailer efforts and Library on Cloud for cross-library efforts. Also, it can guide the solutions for business domain-oriented cloud. A public cloud implementation should be guided by an IEA, not the other way around. ABOUT THE AUTHOR Dr. Zhao is an enterprise-level chief architect, strategist, thought leader, and innovator, and was also an executive for Fortune 500 companies and a professor. She has over 20 years’ work experience across academia, corporate research, the software industry, and consulting services, where she demonstrated strength in insight, vision, creativity, and discipline. She is a positive thinker and a motivational leader with experience in leading R&D, capability and intellectual property development, and consulting practice. She received a PhD in computer science and a Masters in mathematics from Arizona State University. She has six patents granted, four patents pending, and a number of invention disclosures and publications.

REFERENCES P. Mell, T. Grance: The NIST Definition of Cloud Computing, Version 15, October 7, 2009; refer to: www.nist.gov/itl/cloud/upload/cloud-def-v15.pdf. Y. Wei, B.M. Blake: Service-Oriented Computing and Cloud Computing: Challenges and Opportunities, IEEE Internet Computing, Vol. 14, No. 6, pp.72-75, November/December 2010. Y. Zhao: Cloud Computing and SOA from an Enterprise Perspective, ArchiTech Consulting LLC, 2010; refer to: www.architechllc.com/uploads/Publications/Cloud-SOAEnterprise.pdf. A. Arsanjani, S. Ghosh, A. Allam, T. Abdollah, S. Ganapathy, K. Holley: SOMA: A Method for Developing Service-Oriented Solutions, IBM Systems Journal, Vol. 47, No. 3, 2008. Y. Zhao: Service-Oriented Infrastructure Framework, 2008 IEEE Congress on Services – Part I, 2008. Y. Zhao: EA and SOA: A Partnership, Perspectives of IASA Special Issues: Enterprise Architecture – A 20 Years Retrospective, International Association of Software Architects, April 2007. Y. Zhao: Enterprise Service-Oriented Architecture (ESOA) Adoption Reference, Proceedings of 2006 IEEE International Conference on Services Computing, September 2006.

22

© 2016 Association of Enterprise Architects – Volume 12, No. 1

© 2016 Association of Enterprise Architects – Volume 12, No. 1

23

Short Subject Enterprise Architecture Manifesto: Defining Guiding Principles Matt Fishbeck

Abstract This article proposes the idea of an Enterprise Architecture Manifesto that consists of ten principles that apply across the context of Enterprise Architecture (EA), business architecture, business analysis, and the wider domain of business ® transformation. These principles take the format defined within TOGAF 9, a standard of The Open Group, and are written in short form to lean out any unnecessary words, examples, or intended applications and are purely generic in definition. No references have been included because there is no information that has been obtained from other sources; this proposal is a synthesis of experience derived from 20 years’ experience within the software engineering, technology, and now business analysis and enterprise/business architecture disciplines. Keywords Enterprise Architecture, Business Architecture, Business Analysis, Strategic Planning, Principles

INTRODUCTION

PURPOSE

Enterprise Architecture (EA) is a discipline, practice, and profession for enabling organizations to realize their strategic vision and objectives through transformation initiatives. Conducting EA is a complex endeavor. Enterprises themselves are complex dynamic systems that constantly evolve, requiring a structured and methodical approach to managing continual transitions that aim to maximize value and reduce risk in response to changing internal and external conditions.

EA allows complexity to be managed; however, practicing enterprise, business, and technology architecture is a complex endeavor in its own right. Professionals need to have a broad spectrum of knowledge in frameworks, methodologies, techniques, technology, relevant industry and market exposure, business acumen, as well as soft skills and conformance to the appropriate ethical standards. Being successful within engagements is determined by all factors measured primarily from the viewpoint of the relevant stakeholders.

There are many different models, frameworks, and methods to develop enterprise, business, and technology architectures. These predefined structures are merely starting points to reference within the broader context of organization transformation. They represent an array of tools in the practitioner’s toolkit that can be selected and tailored based on business needs and constraints. Despite the multiplicity of different frameworks, methods, and technology options there are, however, a number of common denominators that are universal in breadth and depth, irrespective of the specific endeavor being pursued. These common denominators seldom change and therefore should serve as principles that act as a reference to ensure higher standards of quality and excellence. Considerations such as time, cost, and scope are good examples of constraints that place boundaries around how these principles can be pursued within engagements. After taking these real-world constraints into consideration, these principles serve as clear guidelines for EA considerations and decisionmaking in perusing better business outcomes.

24

Despite these seemingly overwhelming complexities, principles provide a constant that can always be relied upon. These principles are designed as lean guidelines positioned across all architectures to provide an additional level of rigor in decision-making. Considering these principles along with their implications may bring to light some additional considerations and insights. These ten (10) principles are agnostic of professional disciplines and instead are generic, enabling them to be applied to EA, business architecture, business analysis, strategic planning, or any other discipline. Although they are discipline-agnostic they are targeted primarily toward EA. Generally, they should serve as pillars to business transformation efforts through a simple set of governing principles. Similar to the Agile Manifesto, an Enterprise Architecture Manifesto can also provide some direction for how EA endeavors are pursued and what kind of ideals Enterprise Architects should strive for.

© 2016 Association of Enterprise Architects – Volume 12, No. 1

Table 1: Principles: Visibility Name: Visibility Statement: “You only know what you know.” Rationale: Visibility is the precursor to possibility; without it nothing can be identified, quantified, considered, analyzed from a problem, and synthesized into a solution. Implications: Enables identification of information Enables scope to be defined Enables a problem to be identified Enables stakeholders to form a perspective Enables empowerment through knowing Enables a strategy to be formulated Enables a solution to be realized Table 2: Principles: Transparency Name: Transparency Statement: “Opacity introduces problems for perceiving structures and information.” Rationale: Structures composed with layers of abstraction need to be transparent on demand to enable visibility of abstraction layers, enabling relationships and meaning to be realized. Implications: Enables structures to be seen amongst other seemingly irrelevant information Enables structures to be translucent enabling visibility of other structures through structures Enables the inner workings of structures to be exposed externally Enables information about structures to be available irrespective of position or level of abstraction Supports boundary-less information flow Table 3: Principles: All Encompassing Name: All Encompassing Statement: “The bigger picture perceives the smaller picture; not the reverse.” Rationale: Perspectives that are formulated from viewing the entire system allow for a broader perspective to be achieved that highlights the implications when making decisions within a smaller domain of scope.

© 2016 Association of Enterprise Architects – Volume 12, No. 1

Name: All Encompassing Implications: Enables a broader perspective to be realized Enables the narrower perspective to be realized, within context of the broader perspective Enables causal relationships to be discovered between the broader and narrower perspective Enables valid decision-making within both the broader and narrower perspective Enables the narrower perspective to be validated by the broader perspective Table 4: Enterprise Architecture Principles: Horizon Name: Horizon Statement: “Short-term, medium-term, and long-term.” Rationale: Having a broad time domain of consideration allows for smaller intermediate time periods to be considered within a planning context for the future. Implications: Enables time domains to be defined and decomposed into smaller time domains from the current position to the horizon Enables each time domain and its relevant information to be perceived relative to other time domains Enables time domains to be validated against longer time domains Enables current decision-making to be conducted with the broadest necessary time domain for consideration Table 5: Principles: Traceability Name: Horizon Statement: “Joining the dots reveals patterns and order that make sense.” Rationale: Different abstractions are required to provide different information and insights. Ultimately, these different views relate to other abstractions and must be linked through traceability to provide a higher level of order and understanding. Implications: Enables information to be connected Enables meta information to be created from the underlying connected information Enables relationships to be uncovered from meta information Enables pathways to be identified, traversed, and navigated between information and relationships Enables on-demand impact analysis and root cause analysis

25

Table 6: Principles: Alignment Name: Alignment Statement: “Correct relative positioning reduces complexity and establishes relationships.” Rationale: Positioning information in an arrangement that is common allows for a higher order of abstraction to be created, simplifying the arrangement. Elements arranged in common order have a relationship that unifies the information in a simplified order. Implications: Enables information to be arranged in a common relative position Enable information to be grouped together within a relationship Enables the relationship to serve as a basis for other currently unrelated or seemingly disparate information Table 7: Principles: Simplicity Name: Simplicity Statement: “Always reduce complexity as much as possible.” Rationale: Simple concepts and structures facilitate learning and understanding. Simple things lack the variations that require additional cognition and attention for achieving a sense of understanding. As a result, simple things are more efficient to engage, and feel more natural and intuitive. Implications: Enables the more effective comprehension and understanding of information Enables information to be communicated and consumed more efficiently Reduces systems to the required constituents but no further Implies that simplification concentrates value in a smaller, more compact, and efficient form Simplicity produces symmetry that is closely associated with beauty

Name: Consistency Implications: Reduces variations and reduces complexities Enables sounder assumptions to be made Reduces the resources dedicated to managing systems, and therefore also reduces waste Enables a more predictable platform planning, continuity, and benefits realization Enables more effective risk management Provides fertile ground for confidence Table 9: Principles: Synchronization Name: Synchronization Statement: “Timing has everything to do with efficiency.” Rationale: Systems require work to be conducted at specific times because of general work interdependence and resource management. Work needs to be orchestrated and scheduled to occur at the right time to make the most efficient use of resources. Waiting conditions within systems that do not involve work being performed often represent waste. Implications: Work is interdependent on other work Enables work to be scheduled at the correct time to maximize efficiency and performance Enables waiting conditions to be minimized and therefore reduces waste Enables more effective resource utilization Enables dynamic configuration and system behavior changes to adapt to environmental conditions and resource availability Enables time to be used as a basis for current and future performance Enables the benefit of momentum to be realized through more continuous delivery Table 10: Principles: Harmonization Name: Harmonization

Table 8: Principles: Consistency

Statement: “Balance often produces the best outcome.”

Name: Consistency

Rationale: Systems are the most effective when they are said to be balanced, which is a state of performance and efficiency. Systems become balanced with the correct work scheduling, synchronization, and resource utilization. Harmonization is achieved with an optimal balance that affects the system and its dependents.

Statement: “Variation creates exception and complexity.” Rationale: When variability is lacking from a system a sense of understanding is achieved that allows future expectations to be set with confidence. Consistency produces expected results, and requires less resources to be dedicated to manage variability, reducing waste.

26

© 2016 Association of Enterprise Architects – Volume 12, No. 1

Name: Harmonization Implications: Enables an ideal for performance Enables systems to be efficient and effective Enables less resources to be consumed and waste to be generated Enables less resources to be consumed in system regulation, control, and governance Enables more autonomy and self-governance Implies a general state of performance, efficiency, balance, and health

CONCLUSION These principles serve as a validation criteria to be used when considering potential options for decision-making relating to all aspects of design. They can also be used within the context of architecture governance, and not by just the Enterprise Architects themselves. Architecture governance boards and external steering committees that evaluate architecture change and variation requests can also use them as a source of guidance. EA is a complex discipline that when applied to real business problems becomes more complex; selecting

© 2016 Association of Enterprise Architects – Volume 12, No. 1

sometimes multiple frameworks and methods, combining and tailoring, and then applying them to organizations is challenging. Aligning the target state architecture with the organization’s strategic plan and then moving the organization from current state to future state, and then through change and benefits realization is even more challenging. Amidst this seemingly unbounded landscape of challenges it is reassuring to know that there are a set of immutable principles that do not change and that can always be relied upon, to guide decision-making throughout a transformation. It is therefore worthwhile returning to basics independent of all the frameworks and methods to consider a simple set of principles, their rationales, and more importantly their implications. ABOUT THE AUTHOR Matt Fishbeck is a senior business consultant with 10+ years’ experience in transport, telecommunications, utilities, technology, and automotive industries working with stakeholders to meet the objectives of organizations, employing sound alignment to best practice in enterprise/business architecture and analysis.

27

28

© 2016 Association of Enterprise Architects – Volume 12, No. 1

Article The History of Enterprise Architecture: An Evidence-Based Review Svyatoslav Kotusev

Abstract The conventional wisdom says that the concept of Enterprise Architecture (EA) originated from the pioneering work of John Zachman. He is frequently referred to as the “father” of EA and many consider the Zachman Framework to be the breakthrough that created the discipline of EA and provided the foundation for all subsequent EA frameworks and methodologies. Is Zachman’s “A Framework for Information Systems Architecture” really the seminal publication of the EA discipline? Is it really the first EA framework? Did it really profoundly influence modern EA methodologies? In order to answer these questions, in this article I describe an evidence-based history of EA and trace the origins of all essential ideas constituting the basis of the modern concept of EA. Keywords Enterprise Architecture, history, frameworks, Zachman Framework, Business Systems Planning

INTRODUCTION Almost every publication on Enterprise Architecture (EA) cites the Zachman Framework (Zachman 1987) as a seminal EA publication that fundamentally shaped the discipline of EA. Authors routinely call John Zachman the “father” of EA and consider his framework paper to be the initial breakthrough publication that created the very concept of EA and significantly influenced its modern understanding. Moreover, many authors argue that the Zachman Framework inspired all other subsequent EA frameworks and methodologies. Feeling skeptical about these unsubstantiated statements that are typically taken for granted, I decided to initiate an historical inquiry to understand what the real roots of EA are and where the major EA-related ideas originate from. In particular, I focused on the evolution of specific actionable ideas that shaped modern EA methodologies and contributed to the current understanding of EA as an instrument for corporate information systems planning. Therefore, my study deliberately did not cover definitions and philosophy of EA, other IT-related types of architecture (software architecture, system architecture, etc.), as well as architectures for computer integrated manufacturing (CIMOSA, PERA, GRAI, TOVE, GERAM, etc.). In order to trace the historical provenance of EA, I searched all available physical and electronic libraries and the Internet looking for early ideas and methodologies for information systems planning and related them to the modern EA literature. This led me to conclude that EA has a long history that can be logically

© 2016 Association of Enterprise Architects – Volume 12, No. 1

divided into three distinct periods: Business Systems Planning, early EA, and modern EA. BUSINESS SYSTEMS PLANNING The idea of deliberate information systems planning is far from new. Early planning approaches proposed various considerations on how to design corporate information systems based on an organizational strategy (King 1978), data flows between departments (Blumenthal 1969), suppliers and orders (Carlson 1979; Kerner 1979), critical success factors (Rockart 1979), management information requirements (King & Cleland 1975), and decisions (Henderson & West 1979; Zani 1970). However, the earliest origins of the modern concept of EA can be traced back to the Business Systems Planning (BSP) methodology initiated by IBM in the 1960s and led by P. Duane (“Dewey”) Walker (BSP 1975; BSP 1984; Davenport 1994; Harrell & Sage 2010; Lederer & Putnam 1986; Lederer & Putnam 1987; Sidorova & Kappelman 2010; Spewak & Hill 1992; Zachman & Ruby 2004; Zachman & Sessions 2007). The first edition of BSP (BSP 1975) resembled EA in many important aspects. Specifically: BSP activities are carried out by a dedicated group of experts (BSP study team) whose responsibilities include collecting data by interviewing managers and developing information systems plans in a topdown manner. BSP information systems plans describe the relationship between organization, business processes, data, and information systems.

29

BSP uses relationship matrices, information systems networks, flowcharts, and other techniques to model processes, systems, and data. BSP is implemented in a step-wise manner starting from identifying business objectives, defining business processes and data, analyzing the existing IT landscape and developing a desired

future information systems plan, and ending with preparing an action plan and communicating it. Later editions of BSP (BSP 1984) used the notion of architecture to describe the relationship between business processes and data classes (Periasamy 1993; Periasamy & Feeny 1997). The BSP methodology is shown in Figure 1.

Figure 1: BSP methodology (BSP 1984, p.10)

After the introduction of the BSP methodology by IBM many other consulting companies and experts proposed similar formal architecture planning methodologies (Martin 1982; Method1 1979; Nolan & Mulryan 1987). For instance, Nolan, Norton & Company consultancy recommended the following architecture methodology (Nolan & Mulryan 1987): 1. Develop an agreed definition of architecture. 2. Identify and involve architecture stakeholders. 3. Determine the key questions to be answered with architecture. 4. Build a baseline of the existing architecture. 5. Formulate the strategic architecture vision. 6. Organize an effective IT department capable of managing and implementing the architecture. Therefore, BSP was the earliest, definitive, and most widely known top-down planning methodology among a number of similar BSP-like approaches used by different companies (Adriaans & Hoogakker 1989; Davenport 1994; Lederer & Gardiner 1992b; Lederer & Putnam 1986; Lederer & Putnam 1987; Sullivan 1985; Zachman 1982). All these methodologies used the notion of architecture as a formal description of the relationship between business and IT. However, they were known and discussed under different titles: data architecture, information architecture, strategic data planning, and other similar names (Davenport 1994; Goodhue et al. 1992; Lederer & Gardiner 1992a; Martin 1989; Periasamy & Feeny 1997). 30

EARLY ENTERPRISE ARCHITECTURE The notion of an EA framework, as a logical structure for organizing the description of an enterprise, was introduced in 1986 by the PRISM research service of Index Systems and Hammer and Company as a result of the research project sponsored by a group of companies (including IBM) and aimed at finding optimal ways to describe an architecture of distributed systems (PRISM 1986). The PRISM EA framework was the first published EA framework in the modern understanding of this concept (Greefhorst & Proper 2011; Harrell & Sage 2010; Rivera 2013); however, somewhat similar ideas were presented even earlier (Wardle 1984). The PRISM EA framework organizes an architectural description into 16 categories according to four domains (organization, data, application, and infrastructure) and four types (inventory, principles, models, and standards). The PRISM EA framework is shown in Figure 2. One year later in 1987 a similar framework for organizing architectural documentation was published by an IBM marketing specialist, John Zachman, in the internally reviewed IBM Systems Journal (Zachman 1987). The Zachman Framework organizes an architectural description into 15 categories according to five perspectives (planner, owner, designer, builder, and subcontractor) and three interrogatives (what, how, and where). Although it is claimed that the first version of this framework was created in 1984 (Zachman 2009) or even in 1982 (Zachman & Ruby 2004; Zachman & © 2016 Association of Enterprise Architects – Volume 12, No. 1

Sessions 2007), these claims are not substantiated by any documents. Five years later in 1992 the extended version of the Zachman Framework was published in the IBM Systems Journal (Sowa & Zachman 1992a). The extended version of the Zachman Framework organizes an architectural description into 30 categories according to five perspectives (planner, owner, designer, builder, and subcontractor) and six interrogatives (what, how, where, who, when, and why).

Figure 2: PRISM EA framework (PRISM 1986, p.5)

In 1989 the National Institute of Standards and Technology (NIST) issued the first official guidance on EA (Rigdon 1989). The NIST EA model organizes an architectural description into five different architecture levels: business unit, information, information system, data, and delivery system. The NIST EA model is shown in Figure 3.

publications, which used the term “Information Systems Architecture” (Sowa & Zachman 1992a; Sowa & Zachman 1992b; Zachman 1987; Zachman 1989). The term “Enterprise Architecture” was first consistently used by Rigdon (1989) for describing the NIST EA model, although also without any specific definition of its meaning. Later the term “Enterprise Architecture” was first formally defined by Richardson et al. (1990) in their MIS Quarterly article describing the application of the PRISM framework (in particular architecture principles, its most important element) in a large oil company. They defined EA as an architecture that “defines and interrelates data, hardware, software, and communications resources, as well as the supporting organization required to maintain the overall physical structure required by the architecture” (Richardson et al. 1990, p.386). The first EA methodology called Enterprise Architecture Planning (EAP) was proposed by Spewak and Hill (1992). “EAP has its roots in IBM’s BSP” (Spewak & Hill 1992, p.53) and prescribes essentially the following sequence of steps to practice EA: 1. Understand and document the current state of an organization. 2. Develop the desired future state of an organization. 3. Analyze the gaps between current and future states. 4. Prepare the implementation plan. 5. Implement the plan. Although Spewak and Hill (1992, p.13) claim that EAP “creates the top two layers of John Zachman’s Framework”, the Zachman Framework is seemingly mentioned only for marketing-related purposes and is not used in any real sense because the actual deliverables of EAP can hardly be mapped to the framework as claimed. For instance, the EAP methodology and its deliverables are structured around four architecture domains (business, data, applications, and technology), which do not map to the three columns of the Zachman Framework (what – data, how – processes, and where – locations) and do not distinguish between its top two rows (ballpark and owner’s views) (Spewak & Hill 1992, pp.12-13). Subsequently, the EAP methodology served as a basis for many modern EA methodologies (Spewak & Tiemann 2006). The EAP “wedding cake” methodology is shown in Figure 4.

Figure 3: NIST EA Model (Rigdon 1989, p.138)

The phrase “enterprise architecture” was first used by Zachman (1982) (Harrell & Sage 2010). However, its usage was seemingly accidental since this term was mentioned only once without any clear definition. Moreover, it was not used later in subsequent © 2016 Association of Enterprise Architects – Volume 12, No. 1

At the same time, the Government Accountability Office (GAO) published a somewhat similar architecture development methodology recommended for federal agencies (GAO 1992).

31

This methodology is made up of eight steps: 1. Mission and strategy identification 2. Function identification and analysis 3. Information needs identification and analysis 4. Data needs identification and analysis 5. Applications identification and analysis 6. Logical system definition 7. Alternative architecture identification and analysis 8. Target architecture selection

MODERN ENTERPRISE ARCHITECTURE In 1996 the Congress had enacted the Clinger-Cohen Act obliging the Federal Government and all its departments to develop consistent architectures compatible with the NIST EA model in order to improve the usage of information systems (OMB 1997). As a response, in 1999 the Federal CIO Council initiated the Federal Enterprise Architecture (FEA) program and published the corresponding FEA Framework (FEAF) (FEA 2001; FEAF 1999). FEAF is based on the EAP methodology and aligned with the NIST EA model (FEAF 1999; Thomas et al. 2000; Zachman & Sessions 2007). Therefore, FEAF prescribes following the same sequence of steps to practice EA, but recommends describing business, data, applications, and technology architectures in a segmented manner. Similarly to EAP, it is claimed that FEAF is based on the Zachman Framework; however, the Zachman Framework is again “used” only as a symbol without any far-reaching consequences (FEAF 1999, pp.20-23).

Figure 4: EAP methodology (Spewak & Hill 1992, p.16)

It was later supplemented with the best practices learned from leading private and public organizations (GAO 1994). The Department of Defense was one of the first federal agencies to adopt EA (Buss & Shillabeer 2012). In order to speed up the delivery of information systems, lower their costs, and promote integration and flexibility, the Defense Information Systems Agency (DISA) in 1994 introduced the Technical Architecture Framework for Information Management (TAFIM) (Buss & Shillabeer 2012; Goikoetxea 2007; Sessions 2007; TAFIM 1996a), which was based on some previous models initiated in 1986 (Golden 1994). TAFIM describes EA practice as a seven-steps iterative process including documenting baseline and then target states, analyzing the gaps between them, preparing implementation plans, and following them (TAFIM 1996b). TAFIM recommends describing four domains of EA: work organization, information, applications, and technology (TAFIM 1996b). The TAFIM methodology is shown in Figure 5.

Figure 6: TOGAF Architecture Development Method (TOGAF 2011, p.48)

Figure 5: TAFIM Methodology (TAFIM 1996b, p.xiv) 32

After the passage of the Clinger-Cohen Act in 1996 TAFIM was superseded by the Command, Control, Computers, Communications, Intelligence, Surveillance, © 2016 Association of Enterprise Architects – Volume 12, No. 1

and Reconnaissance (C4ISR) framework (C4ISR 1997; Levis & Wagenhals 2000; Sowell 2000) and officially withdrawn in 2000 (Bhagwat 2009; DoDAF 2007a; DoDAF 2009; Goikoetxea 2007; Schekkerman 2004). C4ISR, in its turn, was later replaced with the Department of Defense Architecture Framework (DoDAF) (DoDAF 2007a; DoDAF 2007b; DoDAF 2007c) in 2003 (Bhagwat 2009; DoDAF 2009; Schekkerman 2004). After TAFIM had been replaced, its materials were explicitly given to The Open Group and provided a ® basis for the creation of the TOGAF standard initiated in 1995 (Bhagwat 2009; Perks & Beveridge 2003; TOGAF 2011). Unsurprisingly, the TOGAF standard also recommends describing the typical four domains in EA (business, data, applications, and technology) and recommends the Architecture Development Method (ADM) with one Preliminary phase and eight cyclic phases including describing current and future states, analyzing gaps, preparing transition plans, and implementing them (TOGAF 2011). The TOGAF ADM is shown in Figure 6. Presently TOGAF (2011) is the most cited and widely discussed publication in EA literature (Simon et al. 2013). It embodies the modern understanding of EA and is even considered as a de facto industry standard in EA practice by some authors (Brown & Obitz 2011; Dietz & Hoogervorst 2011; Gosselt 2012; Lankhorst et al. 2010; Sarno & Herdiyanti 2010; Sobczak 2013). CONCLUSION This analysis describes the history of EA and the origin of the most discussed EA frameworks: Zachman, FEAF, and the TOGAF standard (Simon et al. 2013). It clearly shows that the concept of EA has a long history beginning in the 1960s when the BSP methodology was initiated by IBM. The fundamental ideas of BSP permeate the entire history of early and modern EA. Specifically: 1. BSP suggested that the information systems planning for the whole organization is carried out by a dedicated group of experts (prototype of Enterprise Architects). 2. BSP introduced the notion of architecture for describing the relationship between business and IT (prototype of EA). 3. BSP recommended to describe business, data, and information systems domains (prototype of EA domains). 4. BSP proposed various techniques to model processes, systems, and data in a formal way (prototype of EA diagrams). 5. BSP advocated a formal step-wise process for architecture planning including the analysis of

© 2016 Association of Enterprise Architects – Volume 12, No. 1

the current state, description of the desired state, and development of the action plan (prototype of EA methodologies). The comparison between BSP, early EA, and modern EA is summarized in Table 1. Therefore, the concepts and methodologies of EA are far from new and essentially emerged from BSP in the 1960s long before the publication of the Zachman Framework (Zachman 1987). All of the foundational ideas constituting the modern concept of EA are thus almost 50 years old. In fact, all early and modern EA methodologies are based on the ideas pioneered by BSP (Armour et al. 1999; Bernard 2012; Bittler & Kreizman 2005; Boar 1999; Covington & Jahangir 2009; FEAF 1999; IBM 2006; Longépé 2003; Niemann 2006; Schekkerman 2008; Spewak & Hill 1992; TAFIM 1996b; Theuerkorn 2004; TOGAF 2011; van’t Wout et al. 2010). For instance, the modern concept of EA embodied in the TOGAF standard is essentially nothing more than a modernized, revamped, and rebranded version of the BSP methodology introduced in the 1960s since the differences between them are largely stylistic and inessential with the only notable exception that the TOGAF framework is iterative in nature and more technical than BSP (see Table 1). At the same time, PRISM (1986), the very first architecture framework, seemingly had a significant influence on the modern concept of EA. For instance, the organization of architecture according to four domains (organization, data, application, and infrastructure) initially proposed by the PRISM framework was largely adopted by the most prominent early and modern EA standards and methodologies (Bernard 2012; Covington & Jahangir 2009; FEAF 1999; Rigdon 1989; Spewak & Hill 1992; TAFIM 1996b; TOGAF 2011; van’t Wout et al. 2010). Initially proposed by King (1978) in its rudimentary form, the idea of using architecture principles as the most fundamental and stable element of EA was elaborated by the PRISM framework to its modern form which is currently embraced by prominent EA methodologies (Boar 1999; Schekkerman 2008; TOGAF 2011; van’t Wout et al. 2010). The PRISM framework also pioneered the idea of using architecture standards as the essential component of EA presently adopted by prominent EA methodologies (Bernard 2012; Spewak & Hill 1992; TOGAF 2011; van’t Wout et al. 2010). Additionally, the PRISM framework explicitly suggested that EA should describe both current and desired states of an enterprise. This idea is now closely associated with the very notion of EA (Bernard 2012; FEA 2001).

33

Aspect

BSP

Early EA

Modern EA

Time period

1960s – 1980s

1980s – 1990s

1990s – present

Definitive source

BSP (1975)

Spewak and Hill (1992)

TOGAF (2011)

Actors

BSP study team

EA planning team

Team of Enterprise Architects

Products

Information systems plans (later architecture)

Enterprise Architecture

Enterprise Architecture

Domains

Organization, processes, data, and Business, data, applications, and information systems technology

Business, data, applications, and technology

Modeling

Relationship matrices, information systems networks, and flowcharts

Lists, relationship matrices, and diagrams

Catalogs, matrices, and diagrams

Methodology

Describe current and desired states, prepare an action plan, and implement it

Describe current and future states, Describe baseline and target prepare an implementation plan, states, prepare a transition plan, and implement it implement the plan, and repeat the process

Difference from the predecessor

N/A

Pays more attention to technical aspects

Iterative in nature

Table 1: Comparison between BSP, Early EA, and Modern EA Aspect

Conventional Wisdom

General concept

EA is a new concept introduced BSP (1975) by the Zachman Framework and its breakthrough ideas (Zachman BSP (1975) 1987) that subsequently shaped BSP (1984) the very discipline of EA.

Methodology Notion of architecture

Evidence Shows

Notion of framework

Arguably, PRISM (1986) or even earlier (Wardle 1984)

Four architecture domains

PRISM (1986)

Architecture principles

PRISM (1986), in a rudimentary form King (1978)

Architecture standards

PRISM (1986)

Term “Enterprise Architecture”

Arguably, Rigdon (1989) or Richardson et al. (1990)

Summary

EA originated in the 1960s and is essentially an updated version of the BSP methodology significantly influenced by the novel ideas of the PRISM framework.

Table 2: Comparison between the Conventional Wisdom on and Actual Origins of EA

The Zachman Framework (Zachman 1987), which is widely considered to be the seminal EA innovation, does not seem to have played a significant role in the formation of the concept of EA because this framework did not introduce any ideas that were subsequently adopted by the early or modern concepts of EA. For instance, the organization of architecture according to different perspectives (planner, owner, designer, builder, and subcontractor) and interrogatives (what, how, and where) recommended by the Zachman Framework was not adopted by the most prominent early and modern EA standards and methodologies (FEAF 1999; Rigdon 34

1989; Spewak & Hill 1992; TAFIM 1996b; TOGAF 2011) which structure an architectural documentation according to the four domains (business, data, applications, and technology). The documentary evidence cited strongly suggests that the Zachman Framework, even if referred to, as in the cases of EAP and FEAF, did not significantly influence any EA frameworks and methodologies in any real sense. The actual role of the Zachman Framework as the source of the basic concepts of EA seems to be overstated in the conventional wisdom. This is not to say that the Zachman Framework did not add any value to the

© 2016 Association of Enterprise Architects – Volume 12, No. 1

discipline, only that its concepts did not find their way into the bulk of the community’s thinking on the subject. Based on the available documentary evidence, I conclude that the widespread belief that the concept of EA originated with the Zachman Framework is unwarranted. A comparison between the conventional wisdom about EA and what the historical evidence shows about the actual origins of EA is summarized in Table 2.The evidence-based comparison shows that all the fundamental ideas of EA belong to the BSP methodology, some ideas belong to the PRISM framework, and none of them come from the Zachman Framework. The modern concept of EA is conceptually rooted in the BSP methodology initiated by IBM in the 1960s and is significantly shaped by the novel ideas introduced by the PRISM framework. Despite my best efforts to find and analyze all early information systems planning publications that might have influenced the modern concept of EA, the analysis provided in this article may not be exhaustive since many early publications have apparently never been digitized and cannot be obtained for analysis now. Nevertheless, even this potentially incomplete analysis clearly demonstrates that the concept of EA has a long history and provides a more objective discussion of its origins than the conventional wisdom. Finally, I would be very grateful if any readers of this article could provide me with any additional relevant information that can help further clarify the real history of EA. ABOUT THE AUTHOR Svyatoslav Kotusev is a researcher at RMIT University, Melbourne, Australia. He has spent the last two years studying EA practices in organizations. Prior to his academic career he held various software development ® and architecture positions in industry. He is a TOGAF 9 Foundation certified architect. Svyatoslav can be reached at [email protected]. REFERENCES W. Adriaans, J.T. Hoogakker: Planning an Information System at Netherlands Gas, Long Range Planning (22:3), pp.64-74 (1989). F.J. Armour, S.H. Kaisler, S.Y. Liu: Building an Enterprise Architecture Step by Step, IT Professional (1:4), pp.31-39 (1999). S.A. Bernard: An Introduction to Enterprise Architecture (3rd Ed.), Bloomington, IN: AuthorHouse (2012). A. Bhagwat: Role of Beacon Architecture in Mitigating Enterprise Architecture Challenges of the Public Sector, in Advances in Government Enterprise Architecture, P. Saha (Ed.), Hershey, PA: Information Science Reference, pp.56-81 (2009).

© 2016 Association of Enterprise Architects – Volume 12, No. 1

R.S. Bittler, G. Kreizman: Gartner Enterprise Architecture Process: Evolution 2005, G00130849, Gartner, Stamford, CT, pp.1-12 (2005). S.C. Blumenthal: Management Information Systems: A Framework for Planning and Development, Englewood Cliffs, NJ: Prentice Hall (1969). B.H. Boar,: Constructing Blueprints for Enterprise IT Architectures, New York, NY: Wiley (1999). A. Brown, T. Obitz: Enterprise Architecture is Maturing: Findings from the Infosys Enterprise Architecture Survey 2007, Infosys, Bangalore, India, pp.1-38 (2011). BSP: Business Systems Planning: Information Systems Planning Guide (1st Edition), GE20-0527-1, IBM Corporation, White Plains, NY (1975). BSP: Business Systems Planning: Information Systems Planning Guide (4th Edition), GE20-0527-4, IBM Corporation, Atlanta, GA (1984). T.F. Buss, A. Shillabeer: IT and Enterprise Architecture in US Public Sector Reform: Issues and Recommendations, in Enterprise Architecture for Connected E-Government: Practices and Innovations, P. Saha (Ed.), Hershey, PA: Information Science Reference, pp.412-440 (2012). C4ISR Architecture Framework, Version 2.0, Department of Defense, Arlington County, VA (1997). W.M. Carlson: Business Information Analysis and Integration Technique (BIAIT): The New Horizon, Data Base (10:4), pp.3-9 (1979). R. Covington, H. Jahangir: The Oracle Enterprise Architecture Framework, Oracle, Redwood Shores, CA (2009). T.H. Davenport: Saving IT’s Soul: Human-Centered Information Management, Harvard Business Review (72:2), pp.119-131 (1994). J.L. Dietz, J.A. Hoogervorst: A Critical Investigation of TOGAF – Based on the Enterprise Engineering Theory and Practice, in Advances in Enterprise Engineering V, A. Albani, J.L. Dietz, J. Verelst (Eds.), Berlin: Springer, pp.76-90 (2011). DoDAF: The DoDAF Architecture Framework, Version 1.5 (Volume I: Definitions and Guidelines), Department of Defense, Arlington County, VA (2007a). DoDAF: The DoDAF Architecture Framework, Version 1.5 (Volume II: Product Descriptions), Department of Defense, Arlington County, VA (2007b). DoDAF: The DoDAF Architecture Framework, Version 1.5 (Volume III: Architecture Data Description), Department of Defense, Arlington County, VA (2007c). DoDAF: The DoDAF Architecture Framework, Version 2.0, Department of Defense, Arlington County, VA (2009). FEA: A Practical Guide to Federal Enterprise Architecture, Version 1.0, Chief Information Officer Council, Springfield, VA (2001).

35

FEAF: Federal Enterprise Architecture Framework, Version 1.1, Chief Information Officer Council, Springfield, VA (1999). GAO: Strategic Information Planning: Framework for Designing and Developing System Architectures, GAO/IMTEC-92-51, Government Accountability Office, Washington, DC (1992). GAO: Executive Guide: Improving Mission Performance Through Strategic Information Management and Technology, GAO/AIMD-94-115, Government Accountability Office, Washington, DC (1994).

A.L. Lederer, A. Gardiner: Strategic Information Systems Planning: The Method/1 Approach, Information Systems Management (9:3), pp.13-20 (1992b). A.L. Lederer, A.G. Putnam: Connecting Systems Objectives to Business Strategy with BSP, Information Strategy: The Executive's Journal (2:2), pp.75-89 (1986). A.L. Lederer, A.G. Putnam: Bridging the Gap: Connecting Systems Objectives to Business Strategy with BSP, Journal of Information Systems Management (4:3), pp.40-46 (1987).

A. Goikoetxea: Enterprise Architectures and Digital Administration: Planning, Design, and Assessment, Singapore: World Scientific Publishing (2007).

A.H. Levis, L.W. Wagenhals: C4ISR Architectures: I. Developing a Process for C4ISR Architecture Design, Systems Engineering (3:4), pp.225-247 (2000).

C. Golden: A Standard Satellite Control Reference Model, in Proceedings of the 3rd International Symposium on Space Mission Operations & Ground Data Systems, J.L. Rash (Ed.), Greenbelt, MD: NASA, pp.1205-1212 (1994).

C. Longépé: The Enterprise Architecture IT Project: The Urbanisation Paradigm, London: Kogan Page Science (2003).

D.L. Goodhue, L.J. Kirsch, J.A. Quillard, M.D. Wybo: Strategic Data Planning: Lessons from the Field, MIS Quarterly (16:1), pp.11-34 (1992). R.W. Gosselt: A Maturity Model-Based Roadmap for Implementing TOGAF, in Proceedings of the 17th Twente Student Conference on IT, F. Wijnhoven (Ed.), Enschede, The Netherlands: University of Twente, pp.1-10 (2012). D. Greefhorst, E. Proper: Architecture Principles: The Cornerstones of Enterprise Architecture, Berlin: Springer (2011).

J. Martin: Strategic Data-Planning Methodologies, Englewood Cliffs, NJ: Prentice Hall (1982). J. Martin: Strategic Information Planning Methodologies (2nd Ed.), Englewood Cliffs, NJ: Prentice Hall (1989). Method1: Method/1: Systems Development Practices, Arthur Andersen and Co., Chicago, IL (1979). K.D. Niemann, From Enterprise Architecture to IT Governance: Elements of Effective IT Management, Wiesbaden: Vieweg (2006). R.L. Nolan, D.W. Mulryan: Undertaking an Architecture Program, Stage by Stage (7:2), pp.1-10 (1987).

J.M. Harrell, A.P. Sage: Enterprise Architecture and the Ways of Wickedness, Information, Knowledge, Systems Management (9:3), pp.197-209 (2010).

OMB: Memoranda 97-16 (Information Technology Architectures) (1997). Retrieved November 10, 2015 from: www.whitehouse.gov/omb/memoranda_m97-16/.

J.C. Henderson, J.M. West: Planning for MIS: A DecisionOriented Approach, MIS Quarterly (3:2), pp.45-58 (1979).

K.P. Periasamy: The State and Status of Information Architecture: An Empirical Investigation, in Proceedings of the 14th International Conference on Information Systems, J.I. DeGross, R.P. Bostrom, D. Robey (Eds.), Orlando, FL: Association for Information Systems, pp.255-270 (1993).

IBM: An Introduction to IBM's Enterprise Architecture Consulting Method, IBM Global Services, Armonk, NY, pp.1-17 (2006). D.V. Kerner: Business Information Characterization Study, Data Base (10:4), pp.10-17 (1979). W.R. King: Strategic Planning for Management Information Systems, MIS Quarterly (2:1), pp.27-37 (1978). W.R. King, D.I. Cleland: The Design of Management Information Systems: An Information Analysis Approach, Management Science (22:3), pp.286-297 (1975). M.M. Lankhorst, D.A. Quartel, M.W. Steen: Architecture-Based IT Portfolio Valuation, in Proceedings of the 2nd Working Conference on Practice-Driven Research on Enterprise Transformation, F. Harmsen, E. Proper, F. Schalkwijk, J. Barjis, S. Overbeek (Eds.), Delft, The Netherlands: Springer, pp.78-106 (2010). A.L. Lederer, V. Gardiner: The Process of Strategic Information Planning, Journal of Strategic Information Systems (1:2), pp.76-83 (1992a).

36

K.P. Periasamy, D.F. Feeny: Information Architecture Practice: Research-Based Recommendations for the Practitioner, Journal of Information Technology (12:3), pp.197-205 (1997). C. Perks, T. Beveridge: Guide to Enterprise IT Architecture, New York, NY: Springer (2003). PRISM: Dispersion and Interconnection: Approaches to Distributed Systems Architecture, CSC Index, Cambridge, MA (1986). G.L. Richardson, B.M. Jackson, G.W. Dickson: A PrinciplesBased Enterprise Architecture: Lessons from Texaco and Star Enterprise, MIS Quarterly (14:4), pp.385-403 (1990). W.B. Rigdon: Architectures and Standards, in Information Management Directions: The Integration Challenge (NIST Special Publication 500-167), E.N. Fong, A.H. Goldfine (Eds.), Gaithersburg, MD: National Institute of Standards and Technology (NIST), pp.135-150 (1989).

© 2016 Association of Enterprise Architects – Volume 12, No. 1

R. Rivera: The PRISM Architecture Framework – Was It the Very First Enterprise Architecture Framework?, Journal of Enterprise Architecture (9:4), pp.14-18 (2013). J.F. Rockart: Chief Executives Define Their Own Data Needs, Harvard Business Review (57:2), pp.81-93 (1979). R. Sarno, A. Herdiyanti: A Service Portfolio for an Enterprise Resource Planning, International Journal of Computer Science and Network Security (10:3), pp.144-156 (2010). J. Schekkerman: How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Architecture Framework (2nd Ed.), Victoria, BC: Trafford Publishing (2004). J. Schekkerman: Enterprise Architecture Good Practices Guide: How to Manage the Enterprise Architecture Practice, Victoria, BC: Trafford Publishing (2008). R. Sessions: A Comparison of the Top Four EnterpriseArchitecture Methodologies (2007). Retrieved April 8, 2014 from: http://msdn.microsoft.com/en-us/library/bb466232.aspx. A. Sidorova, L.A. Kappelman: Enterprise Architecture as Politics: An Actor-Network Theory Perspective, in The SIM Guide to Enterprise Architecture, L.A. Kappelman (Ed.), Boca Raton, FL: CRC Press, pp.70-88 (2010). D. Simon, K. Fischbach, D. Schoder: An Exploration of Enterprise Architecture Research, Communications of the Association for Information Systems (32:1), pp.1-72 (2013). A. Sobczak: Methods of the Assessment of Enterprise Architecture Practice Maturity in an Organization, in Perspectives in Business Informatics Research, A. Kobylinski, A. Sobczak (Eds.), Berlin: Springer, pp.104-111 (2013). J.F. Sowa, J.A. Zachman: Extending and Formalizing the Framework for Information Systems Architecture, IBM Systems Journal (31:3), pp.590-616 (1992a). J.F. Sowa, J.A. Zachman: A Logic-Based Approach to Enterprise Integration, in Proceedings of the 1st International Conference on Enterprise Integration Modeling, C.J. Petrie (Ed.), Austin, TX: The MIT Press, pp.152-163 (1992b). P.K. Sowell: The C4ISR Architecture Framework: History, Status, and Plans for Evolution, in Proceedings of the 5th International Command & Control Research and Technology Symposium, D. Burns (Ed.), Canberra: CCRP Press, pp.1-21 (2000). S.H. Spewak, S.C. Hill: Enterprise Architecture Planning: Developing a Blueprint for Data, Applications, and Technology, New York, NY: Wiley (1992). S.H. Spewak, M. Tiemann: Updating the Enterprise Architecture Planning Model, Journal of Enterprise Architecture (2:2), pp.11-19 (2006). C.H. Sullivan: Systems Planning in the Information Age, Sloan Management Review (26:2), pp.3-12 (1985).

(Version 3.0), Defense Information Systems Agency, Arlington County, VA (1996a). TAFIM: Department of Defense Technical Architecture Framework for Information Management, Volume 4: DoD Standards-Based Architecture Planning Guide (Version 3.0), Defense Information Systems Agency, Arlington County, VA (1996b). F. Theuerkorn: Lightweight Enterprise Architectures, Boca Raton, FL: Auerbach Publications (2004). R. Thomas, R.A. Beamer, P.K. Sowell: Civilian Application of the DoD C4ISR Architecture Framework: A Treasury Department Case Study, in Proceedings of the 5th International Command & Control Research and Technology Symposium, D. Burns (Ed.), Canberra: CCRP Press, pp.1-21 (2000). ®

TOGAF Version 9.1, G116, The Open Group (2011). J. van’t Wout, M. Waage, H. Hartman, M. Stahlecker, A. Hofman: The Integrated Architecture Framework Explained: Why, What, How, Berlin: Springer (2010). C. Wardle: The Evolution of Information Systems Architecture, in Proceedings of the 5th International Conference on Information Systems, L. Maggi, J.L. King, K.L. Kraemer (Eds.), Tucson, AZ: Association for Information Systems, pp.205-217 (1984). J.A. Zachman: Business Systems Planning and Business Information Control Study: A Comparison, IBM Systems Journal (21:1), pp.31-53 (1982). J.A. Zachman: A Framework for Information Systems Architecture, IBM Systems Journal (26:3), pp.276-292 (1987). J.A. Zachman: The Integration of Systems Planning, Development, and Maintenance Tools and Methods, in Information Management Directions: The Integration Challenge (NIST Special Publication 500-167), E.N. Fong, A.H. Goldfine (Eds.), Gaithersburg, MD: National Institute of Standards and Technology (NIST), pp.63-122 (1989). J.A. Zachman, D. Ruby: Erecting the Framework, Part I (2004). Retrieved October 31, 2015, from: http://archive.visualstudiomagazine.com/ea/magazine/spring/o nline/druby/default_pf.aspx. J.A. Zachman, R. Sessions: Exclusive Interview with John Zachman, President of Zachman International, CEO of Zachman Framework Associates, Perspectives of the International Association of Software Architects, Austin, TX, pp.2-12 (2007). J.P. Zachman: The Zachman Framework Evolution, Zachman International, Monument, CO (2009). W.M. Zani: Blueprint for MIS, Harvard Business Review (48:6), pp.95-100 (1970).

TAFIM: Department of Defense Technical Architecture Framework for Information Management, Volume 1: Overview

© 2016 Association of Enterprise Architects – Volume 12, No. 1

37

38

© 2016 Association of Enterprise Architects – Volume 12, No. 1

© 2016 Association of Enterprise Architects – Volume 12, No. 1

39