Real Enterprise Architecture

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:

1. the model or description of the enterprise architecture
2. the group or organisation engaged in modelling the enterprise architecture
3. one or more representations of the enterprise architecture in some medium
4. the concrete instantiation of the enterprise architecture
5. 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 many 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 - his methodology - was a framework for IT systems (development); the 1989 the (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

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.

  "... 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"

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 Systems Engineering is a discipline that seeks to apply Systems Engineering principles and practices to "the Enterprise". An enterprise is considered a complex socio-technical system that combines people, processes, (information,) and technology in interacting and interdependent subsystems in pursuit of a common mission, objectives or purpose. The Systems Engineering Body of Knowledge (SEBoK)) considers that Systems Engineering applied at the enterprise level is different and may be constrasted with "'traditional' SE (TSE) (sometimes called 'conventional' or 'classical' SE) performed in a development project or to 'product' engineering".

INCOSE considers ESE to be an integrative discipline that combines in an "holistic manner a range of associated topics which together cover how organisations apply systems engineering and allied disciplines to the challenges of developing complex, interdependent products, as well as to designing and transforming the organisations (enterprises) themselves." Johns Hopkins consider ESE as "a multidisciplinary approach combining systems engineering and strategic management to address methods and approaches for aligning system architectures with enterprise business rules and the underlying IT architecture; development and implementation consistent with enterprise strategic objectives; and the total enterprise system and capabilities, with diverse complex subsystems." George Rebovich in a multi-volume report for the MITRE corporation published in 2005 positions ESE as a new 'mode of thought' broadly akin to Enterprise Engineering. Volume 2 of his report is entitled "Systems Thinking (New and Emerging Perspectives)" while volume 3 is entitled "Enterprise Architecture (Application Across the ESE Spectrum)".

It is clear that Enterprise Architecture and Enterprise Systems Engineering (and Enterprise Engineering, for that matter) have very much in common if they are not completely identical. Both adopt the Systemic Perspective and the Holistic Principle - and consider "an Enterprise" to be an Intelligent Complex Adaptive System Of Systems (ICASOS).

"Traditional" Enterprise Architecture practice has been somewhat ICT-centric - reflecting its origins as a better way to engineer ICT-intensive socio-technical systems that became fundamental to organisations and enterprises of all kinds during the 1990s.

   There is general recognition that Enterprise Architecting (EA) within Enterprise
   Systems Engineering (ESE) will differ somehow from “traditional” EA activities. 
   The differences relate initially to recognition that an enterprise’s interests are 
   more diverse than the interests found historically at the systems engineering level 
   and across the system-of-systems engineering area. Additionally, the skills, tools, 
   techniques, and practices supporting this different kind of “next generation” EA are
   still maturing and not fully deployable for uniform and universal use.

Wojcik, L.A., & Hoffman, K.C., (2006), Systems of Systems Engineering in the Enterprise Context: A Unifying Framework for Dynamics, Center for Enterprise Modernization, The MITRE Corporation

In STREAMS, Real Enterprise Architecture is broadened to a much wider technology-base to include all technologies and technology as a broad encompassing subject as used in enterprises. STREAMS's Real Enterprise Architecture is also founded on and incorporates much Systems Thinking, including Traditional Systems Engineering - suitably adapted to enterprise context, and not project context. STREAMS also includes elements from classic Strategic Management and positions Real Enterprise Architecture as a methodology of Strategy Execution. The STREAMS view, therefore is that Real Enterprise Architecture is a more mature, but still immature discipline that is a precursor to the burgeoning but still very immature Enterprise Systems Engineering, or Enterprise Engineering.

More on Enterprise Systems Engineering.

Enterprise Architecture Methodologies

PESTLE Analysis

PESTLE, PESTEL or LEPEST Analysis is a method for elliciting and elucidating the contextual or (business/economic) environmental factors and influences upon and enterprise based on the PESTLE checklist (or taxonomy of influences): Political, Economic, Social, Technological, Ethical, Legal (Factors). As a method it did not originate in Enterprise Architecture but rather in strategic management as a method of understanding the enterprise's (business/company/firm) strategic context and the influences in it that may drive change in it and, consequently, the enterprise. It has been adopted by a small number of Enterprise Architecture Frameworks - notably the ARIES Framework. Fundamentally as a technique the checklist is used to structure and prompt a discussion of change influences in a group of analysts.

Epoch and Era Analysis

Epoch and Era Analysis, EEA, is a method of examining what paradigmatic assumptions remain valid over strategic timescales.

More on Epoch and Era Analysis coming soon.

Enterprise Architecture Frameworks

The ARIES Framework

The ARIES framework is a framework for Enterprise Architecture - strategic change in enterprises - developed by Nightingale and Rhodes at MIT. It incorporates thinking from Systems Thinking and encapsulates some of their research in enterprise change methodologies.

Enterprise Architecture Planning (EAP)

Enterprise Architecture Planning was a methdology and framework for enterprise architecture developed

Enterprise Architecture Maturity Models

EA2MM

Enterprise Architecture and Systems Thinking

Systems Thinking is one of the major foundations for (Real) Enterprise Architecture. See Systems Thinking and Real Enterprise Architecture

Systemic Enterprise Architecture Management (SEAM)

Alain Wegmann

More information about the relationship between Real Enterprise Architecture and Systems Thinking coming soon.

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 and Systemic Innovation

Systemic 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.

Navigation

STREAMS Main Page Systems Thinking Real Enterprise Architecture Management Science Main Page#Indexes / Bibliography