ChapterPDF Available

Why Business Should Take Enterprise Architecture Seriously

Authors:
Chapter

Why Business Should Take Enterprise Architecture Seriously

Abstract

This chapter discusses why business leaders should take EA more seriously as a truly strategic discipline. The author argues that to manage a complex enterprise you must understand how it functions, and to understand it an adequate model designed for the purpose is needed. Also, you must have the right information on which to base decisions, and for the organization to provide that information reliably, an adequate model of the organization as a system is necessary to make any sensible judgment about the informational needs of strategic decision making.
Why Business Should
Take Enterprise
Architecture Seriously
Patrick Hoverstadt
Abstract
This chapter discusses why business leaders should take EA more
seriously as a truly strategic discipline. The author argues that to manage
a complex enterprise you must understand how it functions, and to
understand it an adequate model designed for the purpose is needed.
Also, you must have the right information on which to base decisions,
and for the organization to provide that information reliably, an
adequate model of the organization as a system is necessary to make
any sensible judgment about the informational needs of strategic
decision making.
Keywords
Enterprise Architecture, Complexity, Conant-Ashby, Conway’s Law,
Viable Systems Model, VSM
The Credibility Problem
Traditionally, EA has shared the fate of many other business
disciplines that aspire to be taken seriously and listened to by
those “leading” the enterprise that sit on the board. And the
question of whether EA deserves to be taken seriously by the rest
of the business is not either a flippant one, or indeed a trivial one -
well not if you happen to be an enterprise architect anyway. In case
this is interpreted as a whinge by some disappointed and
disillusioned techie frustrated that their voice isn’t heard in the
corridors of power, let me start by pointing out that I don’t count
myself as an “Enterprise Architect” although my business is the
design of organizations.
The traditional view of the strategic role of EA rests on a view of its
relationship to strategy that itself sits within a traditional model of
the strategic process and the nature of organizational change. This
tends to start with formulating the organization’s strategy.
Typically the execution of the strategy will involve some sort of
organizational change and very often the change will have an
aspect of change to IT and EA may be engaged to: plan that
change, integrate it into the overall structure of IT in the
organization and to reconfigure the model of the organization’s IT.
All this is quite valid and clearly EA can have a useful, some would
argue even an essential role in the execution of strategy.
However, if this is the limited view that both corporate boards and
even the EA community have of EA, then its not surprising if the
discipline has an extremely limited significance for boards and
strategic decision makers. In this model, the legitimate role that
EA could or should have for the strategic decision process (as
opposed to the process of carrying out strategy) is advising on
opportunities that new technologies or information sources might
offer and on the limitations to adoption and risks of change. Again,
this is a legitimate role as an informational input to strategic
decision making, but a very limited one.
To some extent, the limitation of ambition here is in line with EA’s
history as a discipline which is often perceived - and indeed
practiced as a glorified IT requirements capture exercise. If
however we look at it from a management science and specifically
a systems perspective, then a very different picture emerges about
its potential systemic role and there are two important and distinct
arguments that can be advanced for taking EA much more
seriously as a truly strategic discipline.
3
Coping with Complexity: Conant-Ashby
We Can Only Manage What We Can
Understand
One of the core tenets of management science is Conant-Ashby
Theorem. This states that “every good regulator of a system must
contain a model of that system”. Translated into plain English this
means that our ability to manage any organization or business
situation depends directly on our understanding of the
organization or situation and that in turn depends on how good
and relevant our mental models are. We can’t manage what we
don’t understand - except by luck. Once upon a time, it was
possible for an individual at the head of an organization to be
confident that they really did understand the business. As
organizations become more complex, as business practice becomes
more complex, and as the length of time that individuals tend to
spend in the same business decreases, so the validity of relying on
such tacit models becomes increasingly problematic. It is now very
common to find organizations where as soon as you scratch the
surface you discover that nobody really understands how the
whole business works. Talking to a business architect in a large
multi-national I asked “so who apart from you has an
understanding of how the whole business works?” “nobody” was
the reply “some individual directors understand some of their
areas, but nobody, not even the CEO, understands the whole
picture.” How then can they manage the whole organization? How
can they understand the risks that activities in one area of business
may pose for other areas, or the potential synergies or
opportunities that are available?
The lessons of Conant-Ashby are simple and to some extent
obvious, but rarely taken seriously. In the recent credit crisis it
became clear that we were reliant on a financial system that
nobody had designed, nobody understood and nobody was
managing. Most of the individual components making up the
system had been designed, most were understood in their own
terms and most were managed in isolation, but the system as a
whole had evolved without design, understanding or management.
The system as a whole had become so large and complex that
nobody could see the effects in one area of changes or instability in
another part of the system. The most shocking realization is that
the drive has been to recreate the system whilst still not addressing
the need to build a model of how this works as a system that would
allow regulation to stand a chance of working.
How then does this relate to EA and its potential as a genuinely
strategic service for the organization? Well, if boards need a model
of the organization they are trying to manage if they are to manage
it successfully, then the question of how and by whom such a
model could be built and maintained is not currently clear. Nor is
the nature of the model that is necessary. Clearly it is far from
being just a model of the IT. What is needed is a genuine
architecture of the enterprise what it does, processes, people,
structures, finances, values, performance, decision making,
communications, information flows, markets, change, risks,
relationships and technology. This may seem like a tall order, but
actually is relatively straight forward and eminently do-able
provided it is structured around a core model of the organization.
Currently, no business function provides decision makers with
such a model. The informational vacuum is usually filled by purely
financial models which try to reduce the complexity of the
enterprise to a set of accounts accounts which have been
designed for quite a different purpose.
So, does it matter? This is a reasonable question. After all,
businesses have managed without such multi-faceted models of
organizations up to now, so what’s the problem? Well apart from
the theoretical argument posed by Conant-Ashby which, even if it
does have considerable face validity and read as basic common
sense is nevertheless still just a theory, I would argue that there are
compelling and brutally practical reasons for taking the need for a
model of the organization seriously. Organizations are going out of
business at an alarming and increasing rate and this includes the
largest and most successful businesses. Of the original S&P 500
the list of the top 500 companies in the US, only 15% survive. Over
the past 40 odd years, 85% have gone out of business. Of the 1000
largest companies in the world, half suffered a 20% drop in capital
value within a one month period at some point in the decade
before the 2009 credit crunch. That’s half of the ones that survived
such a dramatic drop in value. Overwhelmingly, these are
organizations that were subjected to changes in their business that
they had not foreseen. In organizations that went out of business
because of strategic threats, 35% were hit by threats that came
from directions that they had never even thought to look in.
For these organizations, their model of the enterprise was not just
deficient, but fatally deficient. They simply did not understand
their business and how it sat in its operating environment until it
was far too late. Someone, some business discipline needs to
provide adequate models of how the enterprise works that can
assist decision makers to understand the working of their
organizations as systems to manage them more effectively and
5
whatever the current role and practice of EA, what is needed is a
genuine architecture of the enterprise. This is a truly strategic role.
The implication is that EA models must be understandable by the
business, not just IT and preferably should be constructed with the
business, not just IT. If you want business leaders to take EA
seriously, then it follows that Enterprise Architects should take
business leaders seriously and engage with them on that basis.
This isn’t a battle that is likely to be won overnight and the
development of trust, credibility and a shared language will need
some work.
There are however considerable grounds for optimism. EA could
be pushing at an open door because there is evidence that not only
is dealing with complexity a serious business problem that puts
organisations out of business, but also that this is recognized by
boards as a serious issue. In a 2005 survey of 1,400 Global CEOs,
77% said that dealing with complexity was a high priority for them,
91% believed it needed special tools, only 5% believed they had
those tools. So at board level, the problem posed by Conant-Ashby
of needing models to help us deal with complexity, is already
understood as urgent and important. These CEOs know it’s a
problem and they need new tools to deal with it. All EA needs to do
is step up to the challenge.
Does Strategy drive EA, or EA drive
Strategy?
The second argument for taking EA seriously as a strategic partner
to decision makers is related to the Conant-Ashby argument and
also to both Conway’s Law and McCulloch’s “Redundancy of
Potential Command Principle”. Conway’s law states that:
“organizations which design systems are constrained to produce
designs which are copies of the communication structures of these
organizations”. Conway was referring to the design of IT systems,
but the same principle also applies to the formulation of strategy
by organizations strategy will mirror the structures that
produced it. McCulloch’s Redundancy of Potential Command
Principle states that “in any complex decision network the ability
to act effectively depends on an adequate concatenation of
information”. In other words, we need the right information to
take effective decisions. This is in one sense obvious, but its
implications are profound. The corollary I draw from this is that
the “concatenation of information” confers the ability to act.
The argument here is quite simple, but disconcertingly radical. The
decisions that organizations take tend to depend on the
information available. This means that strategic decisions are
often driven by the structure of information which is very clearly
in the domain of EA. Management science laws and theorems
aside, the argument has good common sense underpinning it. Any
strategy worthy of the name has to be built from information
available to the decision makers. If it isn’t, is it any more than a
fantasy?
And of course, the information available to the decision makers is
a function of the structure of the information system (in its
broadest sense) and of the structure of the organization.
Organizations are structured to take in, process, understand and
store particular types of information and not others. Organizations
can only hear what they are structured to hear and learn what they
are structured to learn. If you doubt this, then try complaining to a
company that doesn’t have a complaints process and structured
resources to deal with it. You very soon become aware that whilst
the individual listening (or pretending to listen) to your complaint
may hear what you are saying, there is nowhere for that
information to go and it is dissipated through the organizational
system. The individual may hear it, but the organization as a
system cannot hear it unless it has been structured to do so. The
structure determines what information the organization can hear
and specifically what information is available to strategists.
According to this view then, the design of information systems
(EA’s domain) is a driver of strategy and can determine the
strategic options that decision makers are capable of seeing. In
practice this can be clearly seen despite the fact that it can be both
very subtle almost insidious and is often invisible to the
organization itself. By definition, our blind spots are often blind to
us. The scale of the distortion of strategy, purpose and values and
its impact can be truly chilling.
An analysis of the use of business intelligence in decision making
for commissioning in the UK National Health Service is a good
example. The role of commissioning was to analyze health needs in
the community and then commission a set of health providers to
deliver services to meet those needs. At the time, the bodies
charged with fulfilling this critical role were Primary Care Trusts
PCTs. This was an explicit attempt by the government to build a
mechanism for breaking the cycle of year on year contracting of
the same health services that existing providers were already
providing irrespective of need and to ensure that services were
7
provided that did actually cover the full range of needs in the
community.
This is a classic strategic decision making process in which the
organization was supposed to recognize and address the strategic
gap - the gap between what the organization is capable of doing
now and what it needs to be doing to fulfill health needs, both
existing and future, in the environment. And fulfilling this
strategic role for the NHS was precisely the reason for setting up
PCTs. It is also a role that is of fundamental importance this isn’t
simply a question about which drug should be used to treat a
particular illness, it is about whether certain illnesses get treated
or not, its about whether we carry on relying on treating diabetes,
or switch resources instead to prevent it. It is about taking real
strategic decisions which for some are literally a matter of life and
death.
The information needs are clear and as with most strategic
decisions, fall into two broad classes of information: information
which we can generically refer to as “performance measurement” –
information which tells us about the internal capability of the
system in question to deliver what it currently does and
information which tells us about need outside, both current and
future. The two sorts of information come from two different
directions, are about completely different things and are quite
different in quality and analysis. Information about future health
needs is necessarily more speculative and qualitative than
performance management information about how many hip
operations were done last year needs to be. Given the two sorts of
information, the strategy process or in this case the
commissioning process is “simply” one of comparing current
capability against expected future demand and taking some
admittedly difficult and uncomfortable decisions about how best to
deploy limited resources to address those needs how many hip
operations versus how many heart by-passes.
That’s the theory. The practice was very far from this. In practice
what we found, when we looked at this situation, was a massive
imbalance in information provision. Performance management
information was in plentiful supply, so the principal providers of
acute care hospital trusts had copious information on levels of
activity and even sometimes on the quality of outcomes. The data
quality of this information and the interpretation of it were both
highly questionable as one director of commissioning said “for
over 80% of services we contract, we don’t understand them well
enough to even know what questions we should be asking to find
out if they’re any good”. Nevertheless, there was information of
sorts and lots of it available to commissioners. On the other side of
the equation, in the information to understand health needs,
information was very scarce, extremely patchy, had to be sought
and specifically sourced, and the data quality was extremely poor,
so the information wasn’t trustworthy.
The result was entirely predictable. Commissioners took the
decisions that they had the information to take and these were to
do with using performance management data to try to control
hospital services in increasing levels of detail. They started to try to
micro-manage service delivery. At an operational level of course
this meant by-passing hospital management to try to dictate
directly to clinicians what they should be doing, and when and how
they should be doing it. The by-passing of hospital management
reduced the ability of hospitals to manage themselves effectively
and exacerbated the problem of control of clinicians which is one
of the problems that PCTs had been set up to address. Because of
course, the PCTs were too far removed from service teams in
hospitals both geographically and in time to be able to exercise any
responsible managerial control of operations in systems
terminology, they lacked requisite variety.
Much more serious was the strategic deficit. PCTs largely failed to
break the cycle of year on year contracting. So the central problem
they were set up to solve assessing health needs and
commissioning services to match those needs was largely
ignored. In fact of course the reverse happened, existing services
became more entrenched as the focus of PCTs fell on managing the
relationship with them more and more tightly.
The reality then was that the strategic direction for health
provision had switched from that intended creating new services
to address known health needs - to managing existing services
more efficiently. This strategy shift was driven and determined by
the availability of information. The architecture of the system was
dictating the strategy. This wasn’t a single example remember, this
was replicated across all the PCTs investigated.
It was also invisible. Those taking these decisions were aware that
they were supposed to be taking cycle breaking decisions and
changing provision, but they pushed this to the back of their minds
and got on with the job they could do, rather than worrying about
the job they couldn’t. The problem was largely undiscussable. The
psychological trap for those engaged in decision making was
difficult for them to see and of course was extremely
uncomfortable when it was made visible. Not just the strategy
9
itself was being dominated by the availability of information which
was in turn determined by the enterprise architecture, but even the
thinking processes of the strategists. At a more mundane level, the
clarity that there were two types of information necessary for
effective decision making external information on health needs
and internal information on performance was lost. Information
was just information, numbers were just numbers and their
meaning and significance were largely lost.
Looking from the outside in this case, the outcome seems perverse
organizations set up with huge budgets to do a fairly specific
strategic job, not only do not do so, but also manage to create a
situation where they can remain largely unaware that they are not
doing it. And yet it is hard to see what else the outcome could have
been. With a highly unbalanced information system, decision
makers took the only decisions they were able to take given the
information available. The strategy was determined by the
architecture. The NHS isn’t an isolated example; the same effect
can be seen in all sorts of organization, public sector, private
sector, large and small.
In this view then, Enterprise Architecture can be seen as not
merely a tool of strategy, as something deployed to help execute
strategy, but as a “meta-discipline” something that needs to be
done right for the strategy formulation process to function reliably.
The story that the design of information systems may determine
the thinking of strategists may not be as attractive to boards as the
argument about the ability to manage complexity, but is critically
important. As a value proposition for EA, this can be framed as
“we design the information systems that provide you with the
information you need to take more effective decisions”.
Towards business led EA
So, this begs the question of what sort of EA approach is needed to
address this sort of meta-strategic need? The need for an
architectural model that provides business leaders with a model of
the enterprise that they can genuinely use to understand how it
operates the Conant-Ashby requirement and an architecture that
has the capability to ensure that the information strategic decision
makers need is actually made available to them (or at the very least
information shortfalls known and identified rather than genuine
blind spots).
One option is to use Stafford Beer’s Viable System Model (VSM) as
a core structural model of the enterprise on which to hang a variety
of information generated by specific disciplines: financial, HR, IT,
operations, marketing etc.
Governance
Development Mgmt
Delivery Mgmt
Co-ordination
Monitoring
Environment
Future
Environment
Local
Local
Local
Management
Operations Units
Ops 3
Ops 2
Ops 1
Viable
Systems
Model
The VSM has a number of key features which make it almost
uniquely suited for this role. Firstly it has a fractal structure which
means that a relatively simple rule set can be used to model
enterprises of any size or complexity in as much or little detail as
necessary. It is applicable to any type of organization in any sector
and of any size. It models both operational activities and
management functions and shows the systemic role of different
management disciplines. So for example, not only can it be used to
model financial flows in an organization where revenue and
profits are generated, but also where financial management
functions sit in relation to other activities such as operations.
Critically in view of the arguments made above, it provides a way
of modeling the structure of decision making throughout the
organization, the information needed to make those decisions,
where that needs to come from and how it needs to be integrated
in decision making. And of course from a more traditional EA
perspective, it provides a blueprint of the organization and its
information sources and needs that can be used to plan IT. From a
technical point of view, VSM ticks a number of critical boxes.
11
Then there are the issues of accessibility and utility.
One other advantage of VSM in particular and organizational
models in general is that they provide a very different way for EA
to do its business and to engage with the organisation. In a study
of a small number of classic business issues that EA might be
expected to engage with and the tools that might be employed to
deal with these, organizational models (particularly VSM) came
out top in terms of the number of problem topics to which they
were applicable. That’s hardly surprising as any significant change
will involve the organisation (whereas not all will touch the
process architecture, the information architecture the technical
architecture etc.)
There are two consequences of this. First is that if we build EA
practice using organizational models as the “spine” and building
other approaches as the ribs off that, the spinal organizational
model can help to integrate other tools and provide continuity of
language and approach it simplifies modeling for both EA and
the organisation. Second is that it provides EA with a much more
business friendly interface. The interface with the organisation is a
model of … the organisation.
This provides a very different set of opportunities to engage with
the business. If the interface EA presents is recognizable by the
business, then it becomes easy and natural for the business to pick
it up and use it for solving their own problems. Our experience is
that if these models are presented in the right way, exec teams in
multi-nationals are not just capable of picking them up and using
them, but are eager to do so. Since they solve the CEO’s problem of
understanding complexity, why would they not?
Conclusions
Looked at from a systems and management science perspective,
there are at least two arguments that can be advanced for why
business leaders should take EA much more seriously as a truly
strategic discipline. Comfortingly both these arguments have the
ring of common sense about them. How can you hope to manage a
complex enterprise if you don’t understand how it functions and
how could you understand it without an adequate model designed
for the purpose? And how can you take strategic decisions if you
don’t have the right information on which to base those decisions
and how will the organization provide that information reliably if it
isn’t designed to do that? Of course the two arguments are
mutually supporting because it is only with an adequate model of
the organization as a system that we can make any sensible
judgment about the informational needs of strategic decision
making.
There is then a credible claim that can be made on behalf of EA for
it to be taken seriously as critically important at a strategic or
meta-strategic level by business leaders. However, this requires EA
to start to take this sort of role seriously and to raise its own sights
from that of playing an IT centered role to a truly enterprise level
role.
About the author
Patrick Hoverstadt is a leading writer and practitioner of systems
approaches to organization. He has worked as consultant for 17
years, is a research fellow at Cranfield School of Management and
guest lecturer at several business schools in the UK and Europe.
He has developed a number of innovative approaches to common
organizational problems.
References
Ashby, W. R. (1957). An Introduction To Cybernetics. London: Chapman
& Hall.
Beer, S. (1979). The Heart of Enterprise, John Wiley, London and New
York
Beer, S. (1981). Brain of the firm. Wiley.
Conant, R. C. & Ashby W.R. (1970) Every good regulator of a system
must be a model of that system Int. J. Systems Sci. vol. 1, No. 2, 89-
97
Conway, M. E. (1968), "How do Committees Invent?", Datamation 14:
2831
Hoverstadt, P. (2008). The Fractal Organization : Creating Sustainable
Organizations with the Viable Systems Model. Chichester, West
Sussex: John Wiley & Sons.
Mculloch W. (1965) Embodiments of Mind. MIT Press
... This includes a limitation on resources in terms of budget, calendar time, time the stakeholders can devote to explaining their business and problems, and the usual lack of documentation covering the important aspects of the business. Moreover, we also consider the point of view of [31] that no individual knows all aspects of business operations in a large organisation. The latter requires combining the views of different stakeholders to reach a holistic picture. ...
... The practical insights gained in the project can be helpful for other business analysts planning to use FEM in similar projects. It needs to be kept in mind, though, that completing a project with a similar scope requires considerable experience and knowledge in different disciplines, such as business analysis [5], requirements engineering [33], business process management [32], enterprise architecture management [31]. Also, such a project requires combining several different techniques. ...
... The analyst has no prior experience in the Confl-info. Information, such as the needs of different stakeholders or software requirements, might be conflicting[31][33]. 8. Lim-persp. ...
Conference Paper
Full-text available
Managing organisational change is becoming increasingly important in an ever-changing world. A novel "lightweight" enterprise modelling technique called Fractal Enterprise Model (FEM) can be helpful in this effort. This technique is formally established, but the range of application areas for it is not yet fully explored. This paper aims to fill the gap, at least partially. This goal is being achieved by using FEM in an industrial project in which a water utility company wants to digitalise its business operations and external communication. The paper follows the Action Design Research paradigm, which combines theory generation with solving organisational problems. The project was structured along a generic Business Analysis process and contained elements from a number of fields, such as requirements engineering, information systems engineering, enterprise architecture management, and business process management. The paper describes 11 different generic problems that were solved with the help of FEM, the project-specific constraints and how FEM was applied in the process. As the same person carried out both the research and the practical work, the usefulness of FEM is examined via reflecting on the experience and generalising the knowledge. FEM supported the business analysis activities by enabling quick and systematic information gathering and comprehensible communication with various internal stakeholders. These insights can be used as a guideline for future practitioners planning to use FEM and for conducting further research regarding the applicability of FEM.
... Enterprise Models (EMs) have a wide area of application, one of them is to be used by management for decision-making. In this case, the model should present the details of how an organization operates in a way understandable for the management [1]. As a model always simplifies the reality, the type of models to be employed depends on which type of decision-making the model should be used in. ...
Conference Paper
Full-text available
If an Enterprise Model is to be used in the strategic decision-making, it should represent the connections between the elements of internal structure, like processes, machines, people, and the elements of the business environment, like market segments, competitors, regulators. The paper presents and discusses a modeling technique – Fractal Enterprise Model (FEM) – that allows to represent such connections, and a computerized toolkit – FEM toolkit – that supports the modeling process. The presentation is done based on a running example. The attendees will learn about an innovative presentation of a business environment in an enterprise model.
... According to (Hoverstadt, 2013) modern organizations have become so complex that no one in the management of an organization fully understand how it operates. The paper also states that for Enterprise Architecture to be taken seriously, it should provide the business with models that the management understands. ...
... Note also, that the results of our project support the statement of Patrick Hoverstadt for the need of an architectural model that shows the management of how the company works presented in [11]. Namely, many managers found the strength of FEM in giving them a holistic view of the company's business activities, and especially on the importance of taking into consideration interconnectedness of processes and assets. ...
Chapter
Full-text available
The paper presents an experience of evaluating the usefulness of a particular modeling technique called Fractal Enterprise Model (FEM). FEM connects enterprise processes with assets that are used in and are managed by these processes. The evaluation has been conducted in a somewhat unusual manner. A model that covers an essential part of an enterprise's activities has been built without any practical goal in mind, e.g. finding a cause of a problem, designing or completing a transformational change, etc. Then, it was presented to and dis-cussed with the stakeholders that helped to build it. During the discussions, the stakeholders were asked to elaborate on the potential usages of the model in the practice of the enterprise. The result was a comprehensive list of possible usage of the model.
... Patric Hoverstadt, in [1] writes "It is now very common to find organizations where as soon as you scratch the surface you discover that nobody really understands how the whole business works". In the same article, he also highlights "the need for an architectural model that provides business leaders with a model of the enterprise that they can genuinely use to understand how it operates". ...
Chapter
Full-text available
The paper suggests using a business process canvas as a model of a process in a nutshell that presents the essential properties of the process and the context in which it is run, including the position of the process in the business process eco-system. The canvas consists of three sections: positioning, operations and re-sources. A positioning section, called Outside, includes such components, as the purpose of the process existence, strategic goals (to be) achieved by having the process, related processes and mechanisms of initiation of new process instances. The operations sections, called Inside, gives an overview of the work of the pro-cess instance, and it includes such components as operational goal, participants, milestones, main events and activities, outcomes and constraints. The resources sections, called Resources, describes resources/assets used in the process in-stances, and includes such components, as participants, tools, methods, etc. The paper proposes a canvas layout, describes its components, and presents an exam-ple. In conclusion, the paper discusses areas where the canvas could be used in practice.
... This phase can effectively address and mitigate the all-too-common problem of lag time in alignment due to constant changes occurring in the organization (Chan & Reich 2007). This phase ultimately concludes with the achievement of robust Enterprise Information System Models that will remain highly stable for the great majority of the subsequent EA implementation steps (Hoverstadt 2013). ...
Article
Full-text available
An organization's fundamental need to respond to influencing forces in its environment is very likely to require some transformation of the enterprise to align itself with new business strategies. Enterprise Architecture (EA) can play a crucial role to increase the chances of implementing such initiatives in a timely and effective manner throughout all layers of the organization. This article presents a Systems Theory-inspired EA model that predicts over the EA implementation lifecycle fundamental dynamic patterns induced by the various EA components and the influence that they have on each other. With an improved understanding of the dynamic behavior of key enterprise components, EA practitioners become better equipped to effectively lead organizational transformation endeavors towards more predictable and beneficial outcomes.
... Patrick Hoverstadt in his paper "Why Business should take Enterprise Architecture seriously" [31] highlights "the need for an architectural model that provides business leaders with a model of the enterprise that they can genuinely use to understand how it operates". Until this happens, the Enterprise Architecture field will not be taken by business leaders as seriously as it should. ...
Article
Full-text available
Paper is in open access: http://bit.ly/2c3RI8P This paper suggests a new type of enterprise models called fractal enterprise models (FEM), with accompanying methodological support for their design. FEM shows interconnections between the business processes in an enterprise by connecting them to the assets they use and manage. Assets considered in the model could be tangible (buildings, heavy machinery, etc.) and intangible (employees, business process definitions, etc.). A FEM model is built by using two types of patterns called archetypes: a process-assets archetype that connects a process with assets used in it, and an asset-processes archetype that connects an asset with processes aimed to manage this asset (e.g., hiring people, or servicing machinery). Alternating these patterns creates a fractal structure that makes relationships between various parts of the enterprise explicit. FEM can be used for different purposes, including finding a majority of the processes in an enterprise and planning business change or radical transformation. Besides discussing FEM and areas of its usage, the paper presents results from a completed project in order to test the practical usefulness of FEM and its related methodological support.
Article
The design of a complex regulator often includes the making of a model of the system to be regulated. The making of such a model has hitherto been regarded as optional, as merely one of many possible ways.In this paper a theorem is presented which shows, under very broad conditions, that any regulator that is maximally both successful and simple must be isomorphic with the system being regulated. (The exact assumptions are given.) Making a model is thus necessary.The theorem has the interesting corollary that the living brain, so far as it is to be successful and efficient as a regulator for survival, must proceed, in learning, by the formation of a model (or models) of its environment.
The Heart of Enterprise Brain of the firm
  • S Beer
Beer, S. (1979). The Heart of Enterprise, John Wiley, London and New York Beer, S. (1981). Brain of the firm. Wiley.