Organizational Theory

"The history of enterprise architecture as a management discipline has been marked by failure to live up to the promise it showed as a concept. The idea of an enterprise architecture and the explicit understanding of the relationships between the most critical forces, resources, and processes involved in the execution of an organization’s business is powerful. People can grasp on an intuitive level how powerful the reality of that concept would be if it could be put into practice and harnessed on behalf of the enterprise. Unfortunately, the conceptual enterprise architecture that enables the agile enterprise and informs executives in the midst of critical portfolio and execution decisions has given way to a morass of additional bureaucracy and expensive efforts to create enterprise models that are more often significant as records of organizational history than as blueprints for the future. The problems lie in three areas. The first of which is a lack of clear performance objectives for the EA effort... The second major failure stems from the belief that EA is somehow all about the process for developing content... Finally, there is far too little attention paid to helping the consumers of EA information..."

"The historical roots of enterprise architecture are well recorded and span a period that starts with the Zachman framework and continues to the present day. During these twenty years of productive activity many well-known frameworks and government level initiatives have seen the light. The aim of this section is to examine the history of enterprise architecture in an attempt to discover the tradition within which it stands. This tradition is explored in terms of diversity of definitions, the components of enterprise architecture, and enterprise architecture frameworks and methods:"

"What I wanted to do when I came in... was help the community turn a corner and become relevant in the key initiatives that we need in the federal government... make sure architecture was relevant, it became more agile, it continued to move to have a more business and more strategy focus."

"Enterprise architecture (EA) is the definition and representation of a high-level view of an enterprise‘s business processes and IT systems, their interrelationships, and the extent to which these processes and systems are shared by different parts of the enterprise. EA aims to define a suitable operating platform to support an organisation‘s future goals and the roadmap for moving towards this vision. Despite significant practitioner interest in the domain, understanding the value of EA remains a challenge. Although many studies make EA benefit claims, the explanations of why and how EA leads to these benefits are fragmented, incomplete, and not grounded in theory. This article aims to address this knowledge gap by focusing on the question: How does EA lead to organisational benefits? Through a careful review of EA literature, the paper consolidates the fragmented knowledge on EA benefits and presents the EA Benefits Model (EABM). The EABM proposes that EA leads to organisational benefits through its impact on four benefit enablers: Organisational Alignment, Information Availability, Resource Portfolio Optimisation, and Resource Complementarity."

"EA originated from and is influenced by a number of business areas: The manufacturing industry, with Material Requirements Planning (MRP) and later Manufacturing Resource Planning (MRP II). These approaches developed into the so-called supply chain or value chain (Porter, et al). Not only the incoming logistics and internal operations were considered, but also the flow of material to customers and back. The second origin of EA growth was from Process Modelling and Design approaches, e.g. Business Process Re-engineering (Hammer, et al). These approaches seek to depict the enterprise in terms of business processes, leading to process improvements and “end-to-end” process integration. Corporate and process governance, organisational adaptability and IM/IT system integration were typical considerations. Organisations were consequently often restructured, to become “flatter” (less management layers) and coined process-centred or process-oriented organisations. A third development is a type of backward integration where software developers trie to better understand and serve the business world with “functioning and value-adding” software solutions (business applications). It is a well-known fact that enterprise integration software (ERP, etc.), according to business users and owners, are often considered to be failures."

"A literary review by Schöenherr (2009) clearly shows that the level of interest in Enterprise Architecture is indeed increasing. Although the term architecture was limited to information systems when originally adopted by John Zachman (1987), the concept has since then been expanded to encompass the entire enterprise and interpreted by academia as well as the private and public sectors. The different views on how to approach Enterprise Architecture are often documented and compiled into “guides” or “frameworks” which are intended to instruct practitioners in how to apply this concept to their organization. However, the numerous approaches all present disparate views on what exactly Enterprise Architecture entails and how it is best administered (Rood, 1994; Whitman, Ramachandran & Ketkar, 2001; Sessions, 2007; Schöenherr, 2009). This essentially leaves the practitioner in the dark as the approaches offer virtually no common ground, no common language and no common orientation on which to base a comparison."

"Enterprise Architecture is the continuous practice of describing the essential elements of a sociotechnical organization, their relationships to each other and to the environment, in order to understand complexity and manage change."

"In recent years, enterprise architecture (EA) management has emerged to one of the major challenges for enterprises. When looking for guidance in this field companies can choose from a variety of EA management approaches, which have been developed by scientists, practitioners, and governmental organizations. However, these approaches differ significantly in a number of characteristics and especially when it comes to methods for the EA management function. There is neither a common understanding of the scope and content of the main activities an EA management function consists of nor has a commonly accepted reference method been developed."

"has been an area of significant research in the information systems discipline throughout the last decade. Mainly developed by IT-practitioners, enterprise architectures (EA) became a promising and comprehensive approach to model either the current or desired state of enterprises. Existing approaches are, however, often criticized for paying too little attention to the business side of enterprises. In this paper, we interpret an enterprise as socio-technical system and analyze from a systems theory perspective which features are necessary for a comprehensive model. From there, we deduce if, why and how additional aspects of enterprises should be included into EA. Amongst others, it becomes obvious that especially human actors, as most flexible and agile elements of enterprises, are not adequately included in current architectures."

"Since 2003, more and more authors using the term EA explicitly in their publications, Most of the newer contributions are coming from an academic background. Especially after 2005, a lot of consultancies and IT-companies are adopting their products and strategies to an extended architectural understanding hence Enterprise Architecture... After 2004-2005 a lot of companies started to use the term EA and since then have connected it somehow to their products and strategies a huge amount of superficial marketing material has been distributed. Consider the maturity and the focus of the contributions there is no topic or even a theory in the discipline of EA. Almost half of the approaches discussed in the papers are still coming from low maturity level (Concept Phase) in the context of readiness to be used in an organization. Only a third of the authors are delivering some kind of best practice (Implementation/Adoption). Differentiating the focus of EA-authors there are two specific topics only (EA-Frameworks and Enterprise Modeling) the majority is dealing with rather general aspects."

"Methods for enterprise architecture, such as TOGAF, acknowledge the importance of requirements engineering in the development of enterprise architectures. Modelling support is needed to specify, document, communicate and reason about goals and requirements. Current modelling techniques for enterprise architecture focus on the products, services, processes and applications of an enterprise. In addition, techniques may be provided to describe structured requirements lists and use cases. Little support is available however for modelling the underlying motivation of enterprise architectures in terms of stakeholder concerns and the high-level goals that address these concerns"

"Enterprise architecture {is] a coherent whole of principles, methods, and models that are used in the design and realisation of an enterprise's organisational structure, business processes, information systems, and infrastructure... The most important characteristic of an enterprise architecture is that it provides a holistic view of the enterprise... To achieve this quality in enterprise architecture, bringing together information from formerly unrelated domains necessitates an approach that is understood by all those involved from those different domains."

"Enterprise Architecture is the organizing logic for key business processes and IT capabilities reflecting the integration and standardization requirements of the firm’s operating model."

"When software applications became larger and larger, people such as Shaw and Garlan coined the term software architecture. This notion of architecture deals with the key design principles underlying software artefacts. In the 1980s and 1990s, people became aware that the development of information technology (IT) should be done in conjunction with the development of the context in which it was used. This led to the identification of the so-called business/IT alignment problem. Solving the business/IT alignment problem requires enterprises to align human, organizational, informational, and technological aspects of systems. Quite early on, the term architecture was also introduced as a means to further alignment, and thus analyzes and solves business?IT alignment problems, Recently, the awareness emerged that alignment between business an IT is not enough, there are many more aspects in the enterprise in need of alignment. This has led to the use of the term architecture at the enterprise level: enterprise architecture."

"Enterprise Architecture is the description and visualization of the structure of a given area of contemplation, its elements and their collaborations and interrelations links vision, strategy and feasibility, focusing on usability durability and effectiveness. Architecture enables construction, defining principles, rules, standards and guidelines, expressing and communicating a vision."

"The dream of every CEO is to have one standardized, integrated, flexible and manageable landscape of aligned business and IT processes, systems and procedures. Having complete control over all projects implementing changes in that landscape so that they deliver solutions that perfectly fit the corporate and IT change strategies, makes this dream complete. The reality for many large organizations is quite the opposite. Many large organizations struggle to keep their operational and change costs in control. Key reasons are the inflexibility and enormous complexity of their business and IT structures, processes, systems, and procedures, often distributed across lines of business (LoB) and business divisions (BD) spread out over various regions, countries or even continents.., Over the last decade, Enterprise Architecture (EA) has been one of many instruments used by organizations in their attempt to get grip on the current operational environment and the implementation of changes. EA provides standardization, and sets a clear direction for the future to guide changes."

"Enterprise Architecture (EA) is becoming an increasingly mature field of work, but many large organizations still struggle with implementing an integral and truly effective EA function. The literature provides a fragmented picture of the EA function, describing the various separate elements that make up the total package of activities, resources, skills, and competences of the EA delivery function. In our view, the EA function reaches beyond EA delivery and also includes the stakeholders, structures and processes involved with EA decision making and EA conformance. A holistic and integral view on the EA function is essential in order to properly assess an EA function on its performance, and to allow identifying the key points of improvement..."

"The goal of enterprise architecture is to create a unified IT environment (standardized hardware and software systems) across the firm or all of the firm's business units, with tight symbiotic links to the business side of the organization (which typically is 90% of the firm... at least by way of budget). More specifically, the goals are to promote alignment, standardization, reuse of existing IT assets, and the sharing of common methods for project management and software development across the organization."

"Enterprise architecture is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise's future state and enable its evolution. The scope of the enterprise architecture includes the people, processes, information and technology of the enterprise, and their relationships to one another and to the external environment. Enterprise architects compose holistic solutions that address the business challenges of the enterprise and support the governance needed to implement them."

"Since the 1970's, organizations are spending more and more money building new information systems. The fast growing number of systems and in many cases the ad hoc manner in which the systems were integrated have exponentially increased the cost and complexity of information systems. At the same time organizations are finding it more and more difficult to keep these information systems in alignment with business need. Furthermore, the role of information systems has changed during the last two decades, from automation of routine administrative tasks to a strategic and competitive weapon. In light of this development, a new field of research and practice was born that soon came to be known as Enterprise Architecture."

"Enterprise Architecture is conceptually defined as the normative restriction of design freedom. Practically, it is a coherent and consistent set of principles that guide the design, engineering, and implementation of an enterprise. Any strategic initiative of an enterprise can only be made operational through transforming it into principles that guide the design, engineering, and implementation of the new enterprise. Only by applying this notion of Enterprise Architecture can consistency be achieved between the high-level policies (mission, strategies) and the operational business rules of an enterprise."

"In the case of Enterprise Architecture, the most widely read book ever published with this kind of subject or field of study is entitled Enterprise Architecture as Strategy. By reading this book, you will learn that every company has its own architecture, but unfortunately, some just do not have the right one."

"Enterprise architecture is the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the company's operating model. The operating model is the desired state of business process integration and business process standardization for delivering goods and services to customers."

"Most business-folk have probably never heard of enterprise architecture. Which is not surprising, because most of the literature in the field suggests it’s about IT, and only about IT. There might be a few throwaway references somewhere to some blurry notion of ‘business architecture’, but that’s about it. Hence of no relevance to everyday business, really. Which is a problem, because real enterprise-architecture isn’t much about IT at all. Or rather, although IT is significant, it’s only one small part. Turns out instead that that blurry ‘business architecture’ isn’t something that can be skipped in a headlong rush down to the technical minutiae: it’s actually the core of enterprise-architecture. Enterprise-architecture is about the architecture – the structure – of the whole of the enterprise:"

": (2) The structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time."

": (1) A formal description of a system, or a detailed plan of the system at component level to guide its implementation;"

"Architecture has two meanings depending upon its contextual usage:"

"Enterprise architecture is the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of a company's operation model... The key to effective enterprise architecture is to identify the processes, data, technology, and customer interfaces that take the operating model from vision to reality."

"[T]his article presents the results of a survey in which Swedish CIOs have prioritized their most important concerns. The three most pertinent concerns are to decrease the cost related to the business organization, improve the quality of the interplay between the IT organization and the business organization, and provide new computer-aided support to the business organization. The survey also shows that CIOs in large companies have a more business-oriented focus than those in small companies... [and that] the foci of Enterprise Architecture frameworks should be aligned with the concerns of the CIO."

"Enterprise ontology is a novel subject, and writing a book on this novel subject puts the author under the obligation to provide at least two kinds of explanation. One explanation regards the justification of presenting yet another point of view on enterprises. Why and how would enterprise ontology assist in coping with the current and future problems related to enterprises? The other explanation concerns the particular approach towards enterprise ontology that the author takes. Why would this approach be more appropriate and more effective than some other one? These are serious questions indeed, and anyone who takes the pain to study this book deserves satisfying answers. You will get the answers; however, not straight away. A first attempt is in this introductory chapter. Definite and fully satisfying answers can only emerge from a dedicated and thorough study of the book. The lasting reward of such a study is a novel and powerful insight into the essence of the operation of enterprises; by this we mean insight that is fully independent of the (current) realization and implementation."

"In the 1970s and 1980s, business processes were redesigned on average once every seven years. This rate of change was easy for the IT department to follow. The time needed to alter the information systems that supported new or changed business processes stayed within acceptable limits. In the 1990s, the rate of change began to increase and information systems began to lag behind. In 2000, a manager succinctly remarked: “We can completely redesign our business processes every three months and subsequently our IT department needs a year to catch up with the supporting information systems.”"

"Since the late 1980s, EA Management Frameworks have emerged within the federal government, beginning with the publication of the National Institute of Standards and Technology framework in 1989. In 1992, the GAO issued EA guidance entitled Strategic Information Planning: Framework for Designing and Developing System Architecture. This EA Management Framework was intended to:"

"During the mid-1980s, John Zachman... identified the need to use a logical construction blueprint (i.e., an architecture) for defining and controlling the integration of systems and their components... Since Zachman introduced his framework, a number of frameworks have emerged within the federal government, beginning with the publication of the National Institute of Standards and Technology (NIST) framework in 1989. Since that time, other federal entities have issued enterprise architecture frameworks, including the Department of Defense (DOD) and the Department of the Treasury. In September 1999, the federal CIO Council published the , which was intended to provide federal agencies with a common construct for their architectures, thereby facilitating the coordination of common business processes, technology insertion, information flows, and system investments among federal agencies. The Federal Enterprise Architecture Framework describes an approach, including models and definitions, for developing and documenting architecture descriptions for multi-organizational functional segments of the federal government."

"The concept of enterprise architecture emerged in the mid-1980s as a means for optimizing integration and interoperability across organizations. In the early 1990s, GAO research of successful public and private sector organizations led it to identify enterprise architecture as a critical success factor for agencies that are attempting to modernize their information technology (IT) environments. Since then, GAO has repeatedly identified the lack of an enterprise architecture as a key management weakness in major modernization programs at a number of federal agencies. It has also collaborated with the Office of Management and Budget (OMB) and the federal Chief Information Officers (CIO) Council to develop architecture guidance. In 2002, OMB began developing the Federal Enterprise Architecture (FEA), an initiative intended to guide and constrain federal agencies’ enterprise architectures and IT investments."

"The software architecture of a system or a family of systems has one of the most significant impacts on the quality of an organization's enterprise architecture. While the design of software systems concentrates on satisfying the functional requirements for a system, the design of the software architecture for systems concentrates on the nonfunctional or quality requirements for systems. These quality requirements are concerns at the enterprise level. The better an organization specifies and characterizes the software architecture for its systems, the better it can characterize and manage its enterprise architecture. By explicitly defining the systems software architectures, an organization will be better able to reflect the priorities and trade-offs that are important to the organization in the software that it builds."

"An enterprise architecture framework"

"[T]he average company’s enterprise system - i.e. the overall system of IT related entities - is today highly complex. Technically, large organizations possess hundreds or thousands of extensively interconnected and heterogeneous single IT systems performing tasks that varies from enterprise resource planning to real-time control and monitoring of industrial processes. Moreover are these systems storing a wide variety of sometimes redundant data, and typically they are deployed on several different platforms... Organizationally, the enterprise system embraces business processes and business units using as well as maintaining and acquiring the IT systems. The interplay between the organization and the IT systems are further determined by for instance business goals, ownership and governance structures, strategies, individual system users, documentation, and cost. Lately, Enterprise Architecture (EA) has evolved with the mission to take a holistic approach to managing the above depicted enterprise system. The discipline’s presumption is that architectural models are the key to succeed in understanding and administrating enterprise systems. Compared to many other engineering disciplines, EA is quite immature in many respects. This thesis identifies.. firstly, the lack of explicit purpose for architectural models... [A] company’s Chief Information Officer (CIO) should guide the rationale behind the development of EA models. In particular, distribution of IT related information and knowledge throughout the organization is emphasized as an important concern uncared for. Secondly, the lack of architectural theory is recognized..."

"Enterprise Architecture is the discipline whose purpose is to align more effectively the strategies of enterprises together with their processes and their resources (business and IT). Enterprise architecture is complex because it involves different types of practitioners with different goals and practices. Enterprise Architecture can be seen as an art; it is largely based on experience but does not have strong theoretical foundations. As a consequence, it is difficult to teach, to apply, and to support with computer-aided tools."

"Enterprise Architecture is a complete expression of the enterprise; a master plan which "acts as a collaboration force" between aspects of business planning such as goals, visions, strategies and governance principles; aspects of business operations such as business terms, organization structures, processes and data; aspects of automation such as information systems and databases; and the enabling technological infrastructure of the business, such as computers, operating systems and networks"

"A well-defined enterprise architecture (EA) is a blueprint for institutional modernization and evolution that consists of models describing how an entity operates today and how it intends to operate in the future, along with a plan for how it intends to transition to this future state. Such architectures are essential tools whose effective development and use are recognized hallmarks of successful organizations."

"Principal among the Strategic Systems Architectures is the so-called ‘Enterprise Architecture’. This is usually regarded as an ‘umbrella’ architecture that covers business, application, information and technical architectures too. This Best Practice Guide concentrates on the structure, construction and use of an Enterprise Architecture. An Enterprise Architecture is a dynamic and powerful tool that helps organisations understand their own structure and the way they work. It provides a ‘map’ of the enterprise and a ‘route planner’ for business and technology change. A well-constructed Enterprise Architecture provides a foundation for the ‘Agile’ business. Normally an EA takes the form of a comprehensive set of cohesive models that describe the structure and functions of an enterprise. An important use is in systematic IT planning and architecting, and in enhanced decision-making. The EA can be regarded as the ‘master architecture’ that contains all the subarchitectures for an enterprise. The individual models in an EA are arranged in a logical manner that provides an ever-increasing level of detail about the enterprise: its objectives and goals; its processes and organisation; its systems and data; the technology used and any other relevant spheres of interest."

"An architecture framework is a tool which can be used for developing a broad range of different architectures [architecture descriptions]. It should describe a method for designing an information system in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks."

"Since the late 1980s, architecture frameworks have emerged within the federal government, beginning with the publication of the National Institute of Standards and Technology framework in 1989. Subsequently, we issued EA guidance, and our research of successful public and private sector organizations’ IT management practices identified the use of EAs as a factor critical to these organizations’ success. Since that time, other federal entities have issued EA frameworks, including the Department of Defense, Department of the Treasury, and the federal CIO Council. Although the various frameworks use different terminology and somewhat different structures, they are fundamentally consistent in purpose and content, and they are being used today to varying degrees by many federal agencies. The emergence of federal frameworks and guidance over the last 5 years owes largely to the Congress’s passage of the in 1996. This act, among other things, requires the CIOs for major departments and agencies to develop, maintain, and facilitate the implementation of information technology architectures as a means of integrating business processes and agency goals with IT. In response to the act, OMB, in collaboration with us, issued guidance on the development and implementation of EAs..."

"The concept of EAs dates back to the mid-1980s. At that time, John Zachman, widely recognized as a leader in the field, identified the need to use a logical construction blueprint (i.e., an architecture) for defining and controlling the integration of systems and their components. Accordingly, Zachman developed a “framework” or structure for logically defining and capturing an architecture. Drawing parallels to the field of classical architecture, and, later, to the aircraft manufacturing industry, in which different work products (e.g., architect plans, contractor plans, shop plans, bills of lading) represent different views of the planned building or aircraft, respectively, Zachman’s framework identified the kind of work products needed to understand and thus build a given system or entity. In short, this framework provides six perspectives or windows from which to view how a given entity operates. The perspectives are those of the (1) strategic planner, (2) system user, (3) system designer, (4) system developer, (5) subcontractor, and (6) system itself. Associated with each of these perspectives, Zachman also proposed six abstractions of the entity, or models covering (1) how the entity operates, (2) what the entity uses to operate, (3) where the entity operates, (4) who operates the entity, (5) when entity operations occur, and (6) why the entity operates. Zachman’s framework provides a way to identify and describe an entity’s existing and planned component parts and the parts’ relationships before the costly and time-consuming efforts associated with developing or transforming the entity begin."

"The use of Enterprise Architectures is becoming increasingly widespread in the private sector. Borrowing insights from enterprise reference architectures developed during the last decade, IT vendors and companies belonging to specific industries are establishing reference data and process models advancing the standardisation of their businesses and creating a more integrated environment for their activities. Although public administrations share the same problem of non-standardisation, which is being magnified rapidly in a changing and demanding environment, little has been done so far in the direction of integration..."

"Architecture : The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution."

"Enterprise architecture is a family of related architecture components. This include information architecture, organization and business process architecture, and information technology architecture. Each consists of architectural representations, definitions of architecture entities, their relationships, and specification of function and purpose. Enterprise architecture guides the construction and development of business organizations and business processes, and the construction and development of supporting information systems. Enterprise architecture is a holistic representation of all the components of the enterprise and the use of graphics and schemes are used to emphasize all parts of the enterprise, and how they are interrelated... Enterprise architectures are used to deal with intra-organizational processes, interorganizational cooperation and coordination, and their shared use of information and information technologies. Business developments, such as outsourcing, partnership, alliances and Electronic Data Interchange, extend the need for architecture across company boundaries."

"Similar to a computer architecture, the enterprise architecture is comprised of several views, including activity view, organizational view, business rule (information) view, resource view, and process view. These views should be cross-referenced with each other to provide an integrated picture of the enterprise."

"This book... provides a formal notational system for drawing and maintaining IT architectures, which I call the Enterprise Information Technology Architecture Blueprinting (EAB for short). This methodology adresses the features required of any formal notational system... In short, EAB defines a communications system that allows a community of IT professionals to visualize architectures in a standard manner."

"Generically, an architecture is the description of the set of components and the relationships between them. Simple enough. The trouble starts when you tack on an adjective: There are software architectures, hardware architectures, network architectures, system architectures, and enterprise architectures. People have their own preconceived notions and experiences about “architecture.” A software architecture describes the layout of the software modules and the connections and relationships among them. A hardware architecture can describe how the hardware components are organized. However, both these definitions can apply to a single computer, a single information system, or a family of information systems. Thus “architecture” can have a range of meanings, goals, and abstraction levels, depending on who’s speaking. An information system architecture typically encompasses an overview of the entire information system—including the software, hardware, and information architectures (the structure of the data that systems will use). In this sense, the information system architecture is a meta-architecture. An enterprise architecture is also a meta-architecture in that it comprises many information systems and their relationships (technical infrastructure). However, because it can also contain other views of an enterprise—including work, function, and information—it is at the highest level in the architecture pyramid. It is important to begin any architecture development effort with a clear definition of what you mean by “architecture.”"