Real Enterprise Architecture
- 1 Defining Real Enterprise Architecture
- 2 Enterprise Architecture (Noun)
- 3 Enterprise Architecture (Verb) or Enterprise Architecting
- 4 Distinguishing Real Enterprise Architecture From "Folk-EA"
- 5 Enterprise Architecture Management
- 6 Enterprise Architecture and Enterprise Engineering
- 7 Enterprise Architecture and Enterprise Systems Engineering
- 8 Enterprise Architecture Methodologies
- 9 Enterprise Architecture and Systems Thinking
- 10 Enterprise Architecture and Management Science
- 11 Enterprise Architecture and Business Change Management
- 12 Enterprise Architecture and Strategic Management
- 13 Enterprise Architecture and Innovation
- 14 Enterprise Architecture Frameworks, Methodologies, Methods and Techniques
- 15 Enterprise Architecture Software Tools
- 16 Navigation
Defining Real Enterprise Architecture
There are many definitions of "Enterprise Architecture". Scott Bernard, author of "Introduction to Enterprise Architecture" provides the following definition, that is as good as any and better than most:
"Enterprise Architecture is a management and technology practice that is devoted to improving the performance of enterprises by enabling them to see themselves in terms of a holistic and integrated view of their strategic direction, information flows, and technology resources."
[Introduction to Enterprise Architecture, 3rd Edition pp.31]
There are a number of aspects to this definition of what Bernard earlier refers to as a "discipline" and "business-driven activity" that are defining characteristics of the practice, activity or discipline:
1. Management and Technology Practice. This means that the practice and practitioners are concerned with both "business management" (or "management" in general) and with "technology" (in general) and implies a balanced view. This implies that practitioners of Enterprise Architecture are more or less equally well-educated in both management and technology. It also implies that the discipline or activity is well-integrated into the management systems (decision-making systems) of the enterprise concerned - including where they span multiple organisations.
2. Improving the Performance of Enterprises. Enterprises are partially designed and partially organically emergent around a set of purposes or objectives. For example, the US Space Industry, in the 1960s, was an enterprise that grew around the objective of "putting a man on the moon before the end of the decade" - a purpose given the enterprise by the US Government. Many commercial enterprises are based on the purpose of providing benefits to their stakeholders (including but not limited to profits for shareholders) concurrently with satisfying the demands or needs of some other enterprise - or 'segment of humanity'. "Performance" in this context means how well the enterprise achieves its purposes or objectives which, following Checkland, may be measured in terms of Efficacy - the (potential) ability or capability to achieve, Effectiveness - the likelihood of actual achievement, and Efficiency - the (inverse) level of resources consumed in the achievement. "Improving the Performance" means systematically changing the enterprise to make it achieve the purposes better - with greater Efficacy, Effectiveness or Efficiency. It is noteworthy how close this is to the discipline or practice of Operational Research - which has been called "the science of better".
3. Reflexivity: "enabling them to see themselves". Many enterprises do not have a developed, objective, comprehensive, common understanding of themselves (or their operating context) - and rely on the partial and biased perceptions of individuals and small groups within the enterprise. Herbert Simon called this phenomenon "Bounded Rationality". Enterprise Architecture, as a practice, seeks to enhance and develop this self-understanding using the mechanism of shared, coherent models describing the enterprise (and its context).
4. Holistic and Integrative. Holism and Integration are founding principles of Enterprise Architecture practice. John Zachman's early (1987) paper started from the premise of lessons that could be learned from other industries (in particular the aircraft industry) in the efficient and effective delivery of complex (sociotechnical) systems for the delivery of IT systems in organisations (intended to improve organisational performance). This itself stemmed from the growing realisation that a specialisation and focus approach, that focused on only the technological components, was (and remains) ineffective. Colloqualially "computerising existing processes, routines and organisations" doesn't work - coherent multi-aspect change is required. Enterprise Architecture seeks to deliver coordination and coherence across the technological and non-technological aspects of the enterprise through reference to a coherent model set for the enterpise. Hence integrative and holistic.
5. Strategy-to-Delivery. "strategic direction" through to delivering "performance improvements" for the enterprise.
6. Multi-aspect. Strategy (business), Information Flows (and systems) and Technology Resources. Enterprise Architecture encompasses and models all these aspects of the enterprise. The technology resources are not limited to just the Information Technology (IT) resources available to the enterprise - but all technological resources. For example, for a glass-manufacturing enterprise the primary technology is not IT
Enterprise Architecture (Noun)
The term, or phrase, "Enterpise Architecture" is often used as a noun (or noun-phrase). As a noun it is polysemantic - has multiple meanings and can refer to a number of things:
- the model or description of the enterprise architecture
- the group or organisation engaged in modelling the enterprise architecture
- one or more representations of the enterprise architecture in some medium
- the concrete instantiation of the enterprise architecture
- the methodology or discipline used in constructing an enterprise architecture model or description
The actual intended meaning of the noun-phrase is often clear from the context in which it is used - but sometimes it leads to misconception and confusion. For example, people may assume the architect is talking about a model (reference number 1) when in fact they are talking about the enterprise's reality (reference number 4). Being philosophically precise, the above noun-phrase references are obviously circular and meaningless unless there is a meaning to the base concept: the thing modelled, or represented or instantiated or analysed according to a discipline.
In STREAMS the base concept of "enterprise architecture" - the thing referenced by the noun-phrase - is the detailed, abstract, real but intangible, common, structured and coherent idea of the (specific) enterprise (which itself is partly abstract). In STREAMS Ontology the enterprise architecture is a World 3 structure - meaning it is not a physical thing nor a mental thing but equally 'real' (having causal effects). The specific notion of the enterprise in an individual's head or small group of peoples heads - their mental model - may be derived from the enterprise architecture or it may be intuited from personal experiences. The mental models people have may be 'inscribed' into physical models be they diagrams printed on paper or software models developed in a suitable modelling environment and stored in a suitable repository. The mental models of the enterprise architecture are fallible (may be seriously 'incorrect') and dependent on a person's experiential history with the enterprise. [This is in line with the general principle of knowledge fallibility from Epistemology - and adopted in STREAMS.] The enterprise architecture may be described or modelled (as described in ISO/IEE 42010) in a number of physical (informational) representations -collectively referred to as The Enterprise Architecture Model or Description. The most veridical (accurate, precise) of the models/descriptions is the single, widely-shared, extensively-critiqued, common model that has been validated and verified through extensive enterprise stakeholder engagement.
The essential principle to remember is that the Model or Description is only a model or description and not the reality of the enterprise architecture. It is a 'simplified' representation - a tool - used for decision-making - it is a map, not the territory.
Enterprise Architecture (Verb) or Enterprise Architecting
"Enterprise Architecture" as a verb, or the noun-phrase "Enterprise Architecting" refers to the practise of enterprise architecture - and again there are several possible meanings (depending on context and speaker). There are at least two senses one of which may be labelled "deflationary" and the other "inflationary". Enterprise Architecture in the deflationary sense means the construction (documentation) of an enterprise model, or the development of the pre-existing enterprise model, and in particular the development of a model of the enterprises future structure. In the bigger, inflationary, view the practice includes not only developing the model, but also encompasses using the model to drive and guide change in the enterprise.
STREAMS takes the view that model-building in practice should not be a fruitless, academic exercise but should be undertaken for good reasons and with a good purpose in mind for the use of the model. STREAMS therefore inclines to the more inflationary sense of Enterprise Architecting which means building the model for normative purposes and entails a relationship with the organisational systems - such as Programme and Project Management - that deliver change in the enterprise. Enterprise Architecture therefore operates indirectly, through influence and governance, to deliver change.
Distinguishing Real Enterprise Architecture From "Folk-EA"
There is no doubt that Enterprise Architecture as a separate management discipline originated in the Information and Communications Technology world when, in the 1980s, computers became smaller and more powerful, moved out of the "backrooms" and started to be networked together and embedded in 'day-to-day' business/organizational routines. Zachman published his seminal (1987) article in the IBM Systems Journal - and it was a framework for IT systems; the 1989 (US) NIST (National Institute for Standards and Technology) was about delivering organisations founded on ICT (hence "Hardware", "Software" and "Communications" at the foundation level of the pyramidal structure), and the subtitle of Spewak's (and Hill's) 1992 book entitled "Enterprise Architecture Planning" was "Developing a Blueprint for Data, Applications and Technology".
The development of the discipline was a management response to various ICT systems implementation failures and the perceived difficulty of consistently realising either efficiency or effectiveness benefits from ICT implementation. The fundamental cause of these ICT failures was diagnosed as "complexity" - and the identified in-principle solution was to implement coordinated change in both the business routines, organisations, processes and procedures and the information, applications, computer infrastructure and data communication. Hence proper analysis and modelling of both "the business" and "the technology", planning and controlled implementation of change and an holistic approach that examined all aspects and systemic, emergent effects were founding principles of the Enterprise Architecture discipline.
However, under the influence of the rise of the Internet and the "dot-com bubble", the race-to-market (and Initial Public Offering), the decline of corporate strategy-making (and even worse strategy execution) as chartered by Mintzberg, and the prevalent "code first, think later" ethos of the late 1990s, and the perception of "the framework" as a selling point for technical and consultancy services, the practice devolved somewhat into little more than yet another ICT design method. Spewak's Enterprise Architecture planning, for example, (re-)used Porter's Value Chain concept and analytical technique - well known in strategic management - in developing the EA plan - but by the end of the 20th century the use of methods and techniques from "business management" had all but disappeared from the popular EA frameworks; they had re-focused on the ICT parts, forgotten the holism principle and neglected the business modelling parts. This form of Enterprise Architecture, however, became more popular as the significance of the Internet and 'eBusiness' rose during the first decade of the 21st century. It is this form of 'Enterprise Architecture' that STREAMS refers to as "Folk-EA" (in the same way that professional philosophers refer to "folk-philosophy" and pschologists refer to "folk-psychology").
Enterprise Architecture Management
According to the "Strategic Enterprise Architecture Management" book:
...we define EAM [Enterprise Architecture Management] as a management practice that establishes, maintains and uses a coherent set of guidelines, architecture principles and governance regimes that provide direction and practical help in the design and development of an enterprise's architecture ro achieve its vision and strategy.
Enterprise Architecture Management seeks to maintain the flexibility, cost-efficiency and transparency in the enterprise architecture. ... ...enterprise architecture consists of components that make up the fundamental structure of and organization: business processes, organisational structures, information systems and technological infrastrcuture. Enterprise architecture management includes developing, implementing and controlling these different components.
Enterprise Architecture and Enterprise Engineering
"... a major problem facing modern science is the development of a theory for addressing organized complexity. Enterprise engineering aims to comprehend enterprise complexity - and thereby master it - and can be seen as a developing discipline - domain of knowledge, concepts, theory and associated methodology - for analyzing, designing and creating enterprises. ... Enterprise Engineering intends to address the design perspective in a formal, methodological way. Two important concepts underpin enterprise engineering: Enterprise Ontology and Enterprise Architecture."
Jan Hoogervorst in "Enterprise Governance and Enterprise Engineering"
"Enterprise Engineering is an integrated set of disciplines for building or changing an enterprise, its processes, and systems. ... A new type of professional is emerging - the enterprise engineer."
James Martin in "The Great Transition: Using the Seven Principles of Enterprise Engineering to Align People Technology and Strategy"
Enterprise Engineering is an emerging discipline that seeks to take an engineering approach to the design and evolution of enterprises. Hitherto most enterprise have been subject to an haphazard, experimental, organic form of emergence and development and have been, at best, built using an heuristic, craft-like approach. This is akin to the way the first aeroplanes and automotives were built in the early decades of the twentieth century. What Hoogervorst and Martin suggest is that a more methodological approach based on the application of scientific knowledge will be the future of enterprise design and building - or 'refurbishment'. From the Hoogervorst point of view Enterprise Engineering is founded on and the logical successor to Enterprise Architecture. It may be observed that even if Enterprise Architecture is conceived as solely and analytical, modelling discipline - and not one used to guide real-world change in the enterprise - it nonetheless requires some 'ontological commitment' - about what there is in an enterprise to model. Hence even without a well-founded theory of Ontology Enterprise Architecture already incorporates some implicit enterprise ontology - and often it is explicit through the epistemic modelling conventions. In real-world practice Real Enterprise Architecture - even if practiced by novices - is well on the way to becoming Enterprise Engineering.
Enterprise Architecture and Enterprise Systems Engineering
Enterprise Architecture Methodologies
Enterprise Architecture and Systems Thinking
Systems Thinking is one of the major foundations for (Real) Enterprise Architecture. See Systems Thinking and Real Enterprise Architecture
More information about the relationship between Real Enterprise Architecture and Systems Thinking coming soon.
Enterprise Architecture and Management Science
Enterprise Architecture and Business Change Management
Enterprise Architecture and Strategic Management
Many authorities [references?] consider that Real Enterprise Architecture is a discipline of Strategy Execution and links the strategy of one or more organizations within the enterprise to a programme of actions that make the necessary changes in the enterprise (and its organizations) to realize the intended strategy.
The ARIES Framework can be considered as a methodology for explicating strategy - business / organisational strategy - into actionable elements of strategic change that can be included in well-defined change programmes. As such it is a methodology of Strategic Management.
Enterprise Architecture and Innovation
Enterprise Architecture Frameworks, Methodologies, Methods and Techniques
STREAMS takes an eclectic, multi-methodological approach to the use of Enterprise Architecture Frameworks, Methodologies, Methods and Techniques making use of the the better parts of a range of them. STREAMS rejects the idea that Enterprise Architecture practice consists of selecting a single framework/methodology and applying it prescriptively and unthinkingly. Rather STREAMS expects that professional Enterprise Architects will draw on several frameworks, and adapt their actual practice to the enterprise context whose change they are engaged in. STREAMS is naturally mutltimethdological; meaning a framework and practice appropriate for the enterprise should be synthesised from multiple "off-the-shelf" methodologies. However, STREAMS recognised the need for an overarching "meta-methodology" to ensure different methodologies and methods can be brought together coherently and be effective.
STREAMS uses the ARIES Framework (ARchitecting Innovative Enterprise Strategy) by Nightingale and Rhodes as the overarching framework for integration for two reasons: 1) it aligns and integrates better with the models and methods of Strategic management and is less ICT-Centric than the large majority of EA frameworks and 2) it is theoretically sound and empirically grounded in management research conducted at the Massachusetts Institute of Technology - unlike the majority of EA frameworks which are more 'heuristic' and propietary. This page: Enterprise Architecture Frameworks, Methodologies, Methods and Techniques - describes the frameworks from which STREAMS draws some ideas.
"Our framework draws from the fundamental theory and practice of multiple fields, including strategic management, stakeholder theory, systems architecting, innovation, scenario analysis, decision science, enterprise theory, and systems science. … ARIES provides an holistic approach to the selection of a new architecture for the future enterprise."
Enterprise Architecture Software Tools
In a modern world, models are no longer realised using "pen-and-paper" technology (including "soft" (digital) versions of "diagrams" and "documents" designed to be printed) - but are in fact realised using modern information technology; that is in a software-created modelling environment. [In principle one could practice Enterprise Architecture using only "pen-and-paper" - or indeed 20th century software tools like spreadhseets, wordprocessors and diagramming software. But in practice - and Enterprise Architecture is a discipline of practice - such an approach would be so inefficient as to be impractical; as in other fields, in organisational change, you have to use the modern software tools to do it efficiently. Hence software tools are necessary to develop, store and use coherent whole-enterprise models - although paper-like representations may be used where access to the online tools and models is not available.