<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <title>Anatomy of Agile Enterprise</title>
    <link rel="alternate" type="text/html" href="http://www.ebizq.net/blogs/agile_enterprise/" />
    <link rel="self" type="application/atom+xml" href="http://www.ebizq.net/blogs/agile_enterprise/atom.xml" />
    <id>tag:www.ebizq.net,2008-10-13:/blogs/agile_enterprise/77</id>
    <updated>2012-01-02T02:20:46Z</updated>
    <subtitle>Janne J. Korhonen provides insights into how information technology can be applied strategically to catalyze organizational change and  responsiveness. Drawing from both theory and practice, he discusses agile enterprise and its governance.</subtitle>
    <generator uri="http://www.sixapart.com/movabletype/">Movable Type Pro 4.37</generator>

<entry>
    <title>When the Ground Rocks, IT Must Flex</title>
    <link rel="alternate" type="text/html" href="http://www.ebizq.net/blogs/agile_enterprise/2012/01/when-the-ground-rocks-it-must-flex.php" />
    <id>tag:www.ebizq.net,2012:/blogs/agile_enterprise//77.19319</id>

    <published>2012-01-02T02:20:36Z</published>
    <updated>2012-01-02T02:20:46Z</updated>

    <summary>&quot;When the ground rocks, structures must flex.&quot; The same is true for companies competing in today&apos;s turbulent environment, concludes a report by the Economist Intelligence Unit. In a time of impermanence, agile organizations re-emerge from the discontinuities of the business...</summary>
    <author>
        <name>Janne J. Korhonen</name>
        <uri>http://www.ebizq.net/MT4/mt-cp.cgi?__mode=view&amp;blog_id=77&amp;id=235</uri>
    </author>
    
        <category term="Enterprise IT" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="IT Strategy" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="agileenterprise" label="agile enterprise" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="agileit" label="agile IT" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="informationtechnology" label="information technology" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="iteffectiveness" label="IT effectiveness" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="organizationalagility" label="organizational agility" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="renewalcycle" label="renewal cycle" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en-us" xml:base="http://www.ebizq.net/blogs/agile_enterprise/">
        <![CDATA[<p>"When the ground rocks, structures must flex." The same is true for companies competing in today's turbulent environment, concludes a <a href="http://www.emc.com/collateral/leadership/organisational-agility-230309.pdf">report</a> by the Economist Intelligence Unit. In a time of impermanence, agile organizations re-emerge from the discontinuities of the business environment, while the less nimble ones face an uphill battle of diminishing returns. Nearly 90 % of the surveyed executives believed that organizational agility is a core differentiator in today's rapidly changing business environment, yet 27 % of respondents say that their organization is at a competitive disadvantage because it lacks the agility to anticipate fundamental marketplace shifts.</p>]]>
        <![CDATA[<p>The prevailing IT mess of large organizations, in particular, does not readily yield to the ever-changing market needs. IT is usually seen as one of the least agile departments, although technology bears potential for enabling organizations to become more agile. The knee-jerk reaction to the increasing cost and pricing pressures may be to focus on the operating costs of IT. However, this "keep the lights on" approach will be seriously misguided, as forced quick fixes render the IT landscape fragile rather than agile.</p>

<p>According to <a href="http://works.bepress.com/lee_dyer/3/">Dyer and Ericksen</a>, the requisite core meta-competence of agility is the capacity to steer organizations in and around a renewal cycle consisting of four competencies: exploration, exploitation, adaptation, and exit. IT is often focused on exploitation: enhancing operational efficiency and optimizing the delivery of solutions to present-day business needs. Consequently, IT is not as adaptive to changing business priorities as it should. <a href="http://en.wikipedia.org/wiki/Black_swan_theory">Black swans</a> may make the whole organization tailspin, and if IT cannot be maneuvered promptly enough, the cost of inertia may be prohibitive. Explorations in emerging technologies and new capabilities are essential to develop requisite <a href="http://en.wikipedia.org/wiki/Absorptive_capacity">"absorptive capacity"</a>. New modes of operation cannot be adopted overnight. It is equally important to abandon outdated technologies and capabilities. Just because something "has always been done like this down here" may just be all the more reason to change the status quo.</p>

<p>Agile organizations deliberately prune away obsolete and redundant information systems, standardize and harmonize technologies, and identify and define standard services and processes. This focus on <a href="http://www.ebizq.net/blogs/agile_enterprise/2009/11/dont-fall-in-the-alignment-trap.php">IT effectiveness</a> enables these organizations to focus on value creation in response to changing customer needs. Moreover, <a href="http://www.amazon.com/Leveraging-New-Infrastructure-Capitalize-Information/dp/0875848303">Weill and Broadbent</a> have proven that cost-focused businesses actually spend more on IT than the industry average, while businesses focused on agility have reduced IT costs.</p>

<p>Once IT has been <a href="http://www.ebizq.net/blogs/agile_enterprise/2010/02/from-fragile-to-agile-enterprise-architecture-reform-through-bpm-and-soa.php">"agilized"</a>, its value increasingly comes from how technology is used for strategic business ends. As <a href="http://www.ebizq.net/blogs/agile_enterprise/2011/02/towards-business-it-confluence.php">IT enablement</a> problems are beyond the scope of any individual, they must be dealt with by a team of people with complementary skills and a common language. An agile organization needs people with a relatively deep expertise in their principal field and a broad general understanding of other fields. Teams and governance arrangements of these <a href="http://www.fastcompany.com/magazine/95/design-strategy.html">"T-shaped people"</a> are focused on the problems at hand rather than on set solutions in their pockets. <a href="http://www.fastcompany.com/magazine/31/sgodin.html">"In the face of change, the competent are helpless."</a> Willingness to change, ability to learn and the capacity to take multiple perspectives outshine the highest of competence.</p>

<p><em>Are you a regular reader of this blog? Do you resonate with the ideas, but remain with questions? Or do you disagree on some aspects and want to express your take on things? Then this <a href="http://agile-enterprise.eventbrite.com">upcoming webinar</a> may be of interest to you. In this concise presentation, I will recapitulate many of the ideas put forth in this blog and also cover some new material. In the end, I will open the air for discussion, which will surely be very interesting.</em><br />
</p>]]>
    </content>
</entry>

<entry>
    <title>Work Systems and Requisite Inquiry</title>
    <link rel="alternate" type="text/html" href="http://www.ebizq.net/blogs/agile_enterprise/2011/12/work-systems-and-requisite-inquiry.php" />
    <id>tag:www.ebizq.net,2011:/blogs/agile_enterprise//77.19292</id>

    <published>2011-12-07T14:53:59Z</published>
    <updated>2011-12-07T14:53:44Z</updated>

    <summary>In my previous post, I expounded upon Hoebeke&apos;s (1994) notion that work is vertically organized as recursively interlinked work system domains and postulated a link between these structural domains and the ontological domains of the Cynefin framework (Kurtz and Snowden,...</summary>
    <author>
        <name>Janne J. Korhonen</name>
        <uri>http://www.ebizq.net/MT4/mt-cp.cgi?__mode=view&amp;blog_id=77&amp;id=235</uri>
    </author>
    
        <category term="Enterprise Engineering" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="Organizational Development" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="epistemology" label="epistemology" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="inquiringsystem" label="inquiring system" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="knowledge" label="knowledge" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="reflectivejudgmentmodel" label="reflective judgment model" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="requisiteorganization" label="Requisite Organization" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="worksystem" label="work system" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en-us" xml:base="http://www.ebizq.net/blogs/agile_enterprise/">
        <![CDATA[<p>In my <a href="http://www.ebizq.net/blogs/agile_enterprise/2011/10/taming-the-chaos-is-a-spiritual-deed.php">previous post</a>, I expounded upon <a href="http://en.wikipedia.org/wiki/Luc_Hoebeke">Hoebeke</a>'s (<a href="http://www.amazon.com/Making-Work-Systems-Better-Practitioners/dp/0471942480/">1994</a>) notion that work is vertically organized as recursively interlinked work system domains and postulated a link between these structural domains and the ontological domains of the <a href="http://en.wikipedia.org/wiki/Cynefin">Cynefin</a> framework (Kurtz and <a href="http://en.wikipedia.org/wiki/Dave_Snowden">Snowden</a>, <a href="http://alumni.media.mit.edu/~brooks/storybiz/kurtz.pdf">2003</a>). In the following, I will further posit what the epistemological underpinnings of the work system domains would be. To this end, I will turn to <a href="http://en.wikipedia.org/wiki/Charles_West_Churchman">Churchman</a> (<a href="http://www.amazon.com/Design-Inquiring-Systems-Concepts-Organization/dp/0465016081">1971</a>), for a systems point of view, and <a href="http://www.soe.umich.edu/people/profile/patricia_king/">King</a> and <a href="http://myprofile.cos.com/kitchenk88">Kitchener</a> (<a href="http://www.amazon.com/Developing-Reflective-Judgment-Jossey-Bass-Education/dp/1555426298">1994</a>), for a developmental-psychological point of view. In the end, I will take a look at some practical implications of the ideas.</p>
]]>
        <![CDATA[<h2>Churchman: Inquiring Systems</h2>

<p>
Churchman (1971) looked at the history of <a href="http://en.wikipedia.org/wiki/Epistemology">epistemology</a> from a systems point of view and distinguished five archetypal inquiring systems -- epistemological viewpoints from which people inquire into knowledge and truth. He named these inquiring systems after great philosophical minds as Leibnizian, Lockean, Kantian, Hegelian, and <a href="http://en.wikipedia.org/wiki/Edgar_A._Singer,_Jr.">Singerian</a>.
</p><p>
<a href="http://www.interdevelopmentals.org/about-otto-laske.php">Laske</a> (<a href="http://www.amazon.com/Measuring-Hidden-Dimensions-Human-Systems/dp/0977680061/">2008</a>) sees the Churchmanian inquiring systems as related by a developmental logic and hence contextualizable with <a href="http://www.ebizq.net/blogs/agile_enterprise/2010/05/stratification-underlies-agility-preface.php">Requisite Organization</a> (<a href="http://en.wikipedia.org/wiki/Elliott_Jaques">Jaques</a>, <a href="http://www.amazon.com/Requisite-Organization-Effective-Managerial-Leadership/dp/1886436045">1998</a>), the metatheoretical backdrop for Hoebeke's (1994) scheme. I concur with the general notion, but differ slightly in the conjecture of how the inquiring systems would pertain to requisite strata, specifying that each vertical work system domain (cf. <a href="http://www.ebizq.net/blogs/agile_enterprise/2011/10/taming-the-chaos-is-a-spiritual-deed.php">my prior post</a>) would have its "requisite inquiring system" as follows:
</p><p>
<ul>
    <li>Value-added domain: Lockean</li>
    <li>Innovation domain: Kantian</li>
    <li>Value systems domain: Hegelian</li>
    <li>Spiritual domain: Singerian</li>
</ul>
</p><p>
(The Leibnizian inquiring system is a closed system with a set of axioms that, along with formal logic, are used to generate fact nets or tautologies. It is thereby a relatively uninteresting inquiring system from the organization's point of view.)
</p>

<h2>King and Kitchener: Reflective Judgment Model</h2>

<p>
As individuals are constitutive of the collective, their cognitive abilities must be on a par with the inquiring system they are engaging with. A commensurate model of epistemic position at the micro-level appears to be the Reflective Judgment Model (RJM) (King and Kitchener, 1994).
</p><p>
The Reflective Judgment Model describes the development of complex reasoning in late adolescents and adults, focusing on individuals' underlying assumptions about knowledge and how it is gained. The RJM identifies seven stages in the development of reflective thinking, each stage representing a qualitatively different epistemological perspective: what are the limits of one's knowing, what is the notion of truth, how are beliefs justified.
</p><p>
Laske (2008) also suggests a mapping between the Reflective Judgment Model and the inquiring systems of Churchman. With the aforementioned adjustment to requisite strata, I would align the two models with Hoebeke's (1994) work system domains as illustrated in Figure 1.
</p>

<p><span class="mt-enclosure mt-enclosure-image" style="display: inline;"><a href="http://www.ebizq.net/blogs/agile_enterprise/assets_c/2011/12/inquiring_systems.php" onclick="window.open('http://www.ebizq.net/blogs/agile_enterprise/assets_c/2011/12/inquiring_systems.php','popup','width=1613,height=1113,scrollbars=no,resizable=no,toolbar=no,directories=no,location=no,menubar=no,status=no,left=0,top=0'); return false"><img src="http://www.ebizq.net/blogs/agile_enterprise/assets_c/2011/12/inquiring_systems-thumb-500x345.jpg" width="500" height="345" alt="inquiring_systems.jpg" class="mt-image-none" style="" /></a></span></p>

<p>
<b>Figure 1. Work system domains (Hoebeke, 1994), stages of reflective judgment (King and Kitchener, 1994), and respective inquiring systems (Churchman, 1971).</b>
</p><p>
Stages 4 and 5 of RJM represent <i>quasi-reflective thinking</i>. Knowledge is not simply accepted from others as in prereflective thinking of stages 1 to 3, but seen as an abstraction that is internally constructed. Uncertainty and evidence are recognized as parts of the knowing process.
</p><p>
Stages 6 and 7of RJM represent <i>reflective thinking</i>. Reflective thinkers understand knowledge claims in relation to the context in which they were generated, while remaining open to reevaluating their conclusions in the face of new evidence.
</p>

<h2>Requisite Inquiring Systems</h2>

<p>
In the following, I will discuss the requisite epistemological underpinnings of each work system domain (Hoebeke, 1994) in terms of the Churchmanian inquiring systems (Churchman, 1971) and the stages of reflective judgment (King and Kitchener, 1994).
</p>

<h3>Added-Value Domain: Consensual</h3>

<p>
A Lockean inquiring system (Churchman, 1971) is empirical and consensual. It is an open system that inductively learns from external observations. A network of increasingly more general "facts" is deduced from elementary sense data (Wood, 1990). The exploratory ways in which other concepts can be derived from the base concepts are not directly tied to empirical evidence or even logical inference (Laske, 2008). The guarantor of the system is the consensus by the Lockean community on the labels that are assigned to the system inputs (Courtney et al., 1998).
</p><p>
The convergent and consensus building emphasis of the Lockean inquiry system is suited for stable and predictable organizational environments (Malhotra, 1997), i.e. within the added-value domain (Hoebeke, 1994).
</p><p>
The view of knowledge is that it is uncertain, characterized by ambiguity due to situational variables (e.g. incorrect reporting of data, lost data, disparities in information access), and that knowledge claims are idiosyncratic to the individual. Beliefs are justified by giving idiosyncratic reasons and evidence. (King and Kitchener, 1994).
</p>

<h3>Innovation Domain: Contextual</h3>

<p>
A Kantian inquiring system (Churchman, 1971) synthesizes rationalism and empiricism, reconciling the Leibnizian and Lockean inquiry modes. It is able to interpret inputs and generate hypotheses based on what the system already knows and to create and incorporate new knowledge. The guarantor of the system is the fit between data and model (Courtney et al., 1998). However, due to multiple alternative models, an input is subject to different interpretations and there is no guarantee that the model represents the best solution. The plurality of complementary solutions may cause a "competency trap" (Malhotra, 1997).
</p><p>
Kantian inquiry systems are best suited for moderate ill-structured problems (Malhotra, 1997) that characterize the innovation domain (Hoebeke, 1994).
</p><p>
Knowledge is viewed as contextual, subjective and interpretative. It is filtered through a person's perceptions and criteria for judgment, i.e. Kantian categories. Beliefs are justified within a particular context by means of context-specific rules of inquiry and interpretations of evidence. (King and Kitchener, 1994).
</p>

<h3>Value Systems Domain: Constructive</h3>

<p>
A Hegelian inquiring system (Churchman, 1971) is dialectical in the sense that knowledge is created through a conflictual thesis-anti-thesis-synthesis pattern, which "is a soaring to greater heights, to self-awareness, more completeness, betterment, progress" (Churchman, 1971). The guarantor of the system is synthesis that opposes the conflict between the thesis and its anti-thesis (Courtney et al., 1998). 
</p><p>
"Taken-for-granted" interpretations of "pre-packaged" best practices are problematic when multiple and contradictory viewpoints need to be generated. The Hegelian process ensures that knowledge is subjected to continual re-examination and modification vis-à-vis the changing reality (Malhotra, 1997) characteristic to the value systems domain (Hoebeke, 1994).
</p><p>
Knowledge is constructed into individual conclusions about illustrated problems based on cross-domain information.  Interpretations are based on evaluations of evidence across contexts and on the evaluated opinions of reputable others. Beliefs are justified by comparing evidence and opinion from different perspectives and contexts. Categories of comparison and evaluation are constructed. (King and Kitchener, 1994).
</p>

<h3>Spiritual Domain: Considerate</h3>

<p>
A Singerian inquiring system (Churchman, 1971) is progressive like the Hegelian one, but more precise and explicit. Singer chose as his starting point metrology, the science of measurement. There are two basic principles guiding Singerian inquiry (Courtney et al., 1998): First, a system of measures specifies steps to be followed in resolving disagreements among members of a community. Second, the strategy of agreement intensifies the dialectical process: through refinement of measurement the inquiring system is brought to a stage where previously contrary hypotheses, both consistent at a specified level of refinement, will fail to be consistent (Churchman, 1971). "Sweeping in" new concepts, variables and laws governing them, inconsistencies in the model can be overcome.
</p><p>
To reconstruct the inquiring system, Singer calls for the "whole scope of inquiry", transcending any one discipline. As the Singerian inquiring system has no controller but authority and control are pervasive throughout the system, it must consider the whole breadth of inquiry in its attempt to authorize and control its procedures. As the inquiring system requires a cooperative environment, in which inquiry is needed to create cooperation and cooperation is needed to create inquiry, ultimately the design of a Singerian inquiring system becomes the design of the whole social system. (Churchman, 1971). This is the realm of the spiritual domain (Hoebeke, 1994).
</p><p>
Knowledge is the outcome of a process of reasonable inquiry, evaluating what is most reasonable or probable according to the evidence at hand, and it is reevaluated when relevant new evidence, perspectives, or tools of inquiry become available (King and Kitchener, 1994). The common ground of opposites is considered, and used to construct holistic perspectives (Laske, 2008). Beliefs are justified probabilistically on the basis of a variety of interpretive considerations, e.g. the weight of the evidence, the explanatory value of the interpretations, the risk of erroneous conclusions, consequences of alternative judgments, and the interrelationships of these factors. (King and Kitchener, 1994).
</p>

<h2>So What?</h2>

<p>
Each organizational work system and design artifact shall be conceived from the point of view of its meta-level epistemological foundations. The inquiring system must be at high enough level of abstraction, lest the modeling of the "object-level" system (van Gigch, 1993) can lead to dysfunctions and to system failures. The more wicked, or ill-structured, the problems faced, the higher level inquiring system is required. 
</p><p>
Just as a scientific discipline must undergo a "revolution" (cf. Kuhn, 1962) to stay alive, organizational and social paradigms must evolve. Unless the very epistemological foundations are questioned, the inherent limitations of the hegemonic <i><a href="http://en.wikipedia.org/wiki/World_view">Weltanschauung</a></i> cannot be surfaced and overcome. For instance, when the complexity of business environment mounts to the value systems domain in lieu of the innovation domain, context-specific knowledge falls short in the face of discontinuous change that calls for a more encompassing common ground, e.g. value innovation vs. product innovation -- a Hegelian inquiring system must then transcend the Kantian one. 
</p><p>
Different vertical work system domains also place different demands on the people working in those domains. The cognitive development of a person along the epistemic dimension must be at a requisite level for him/her to adequately engage in the inquiring system of their predominant works system domain. For instance, a manager promoted to a higher level of complexity and abstraction may not be up to their task at the new level of inquiry. Working from his/her prior epistemic position in the more complex context may throw a monkey wrench into the work system and bring down the entire organization. 
</p><p>
Strategic challenges of the organization are not effectively tackled with context-specific knowledge and understanding. The current predicament of the entire society is not addressed within any single discipline but requires a holistic, cross-paradigmatic approach and <a href="http://en.wikipedia.org/wiki/Transdisciplinarity">transdisciplinary</a> measures. Recognizing the requisite inquiring system and respective epistemic demands for a work system at the level of its complexity and abstraction helps prevent systemic design faults and resulting dysfunctions.
</p>

<h2>References</h2>

<dl>
<dt><b>Churchman, C.W. (1971).</b> The design of inquiring systems: Basic concepts of systems and organization. New York: Basic Books.</dd>
<dt><b>Courtney, J.F., Croasdell, D.T. and Paradice, D.B. (1998).</b> "Inquiring Organizations", Australian Journal of Information Systems, 6(1).
<dt><b>Gigch, J.P. van (1993).</b> "Metamodeling: The Epistemology of System Science", Systems Practice, 6(3), pp. 251-258.
<dt><b>Hoebeke, L. (1994).</b> Making Work Systems Better: A Practitioner's Reflections. John Wiley & Sons.
<dt><b>Jaques, E. (1998).</b> Requisite Organization: A Total System for Effective Managerial Organization and Managerial Leadership for the 21st Century, Revised second ed. Baltimore, MD: Cason Hall & Co. Publishers.
<dt><b>King, P.M. and Kitchener, K.S. (1994).</b> Developing Reflective Judgment. San Francisco: Jossey-Bass Publishers.
<dt><b>Kuhn, T. (1962).</b> The Structure of Scientific Revolutions. Chicago: Chicago University Press.
<dt><b>Kurtz, C.F. and Snowden, D.J. (2003).</b> "The new dynamics of strategy: Sense-making in a complex and complicated world", IBM Systems Journal, 42(3), pp. 462-483.
<dt><b>Laske, O. (2008).</b> Measuring Hidden Dimensions of Human Systems: Foundations of Requisite Organization. IDM Press.
<dt><b>Malhotra, Y. (1997).</b> "Knowledge Management in Inquiring Organizations," in the Proceedings of 3rd Americas Conference on Information Systems (Philosophy of Information Systems Mini-track), Indianapolis, IN, August 15-17, 1997, pp. 293-295.
<dt><b>Ulrich, W. (1985).</b> The Way of Inquiring Systems: "The Design of Inquiring Systems" by C. West Churchman, The Journal of the Operational Research, 36(9), pp. 873-876.
<dt><b>Wood, P.K. (1990).</b> "Construct validity and theories of adult development: Testing for necessary but not sufficient relationships". In Commons, M.L., Armon, C., Kohlberg, L., Richards, F.A., Grotzer, T.A., and Sinnott, J.D. Adult Development, vol. 2. New York: Praeger.
</dl>
]]>
    </content>
</entry>

<entry>
    <title>Taming the Chaos Is a Spiritual Deed</title>
    <link rel="alternate" type="text/html" href="http://www.ebizq.net/blogs/agile_enterprise/2011/10/taming-the-chaos-is-a-spiritual-deed.php" />
    <id>tag:www.ebizq.net,2011:/blogs/agile_enterprise//77.19242</id>

    <published>2011-10-24T20:51:00Z</published>
    <updated>2011-10-24T20:51:28Z</updated>

    <summary>Work is Organized as a Holarchy of Viable Systems In his excellent book &quot;Making Work Systems Better&quot;, Luc Hoebeke (1994) develops a work systems framework that provides an alternative to monolithic, hierarchic models of organizations. Arguing that the &apos;span of...</summary>
    <author>
        <name>Janne J. Korhonen</name>
        <uri>http://www.ebizq.net/MT4/mt-cp.cgi?__mode=view&amp;blog_id=77&amp;id=235</uri>
    </author>
    
        <category term="Enterprise Engineering" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="Leadership" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="causaltexture" label="causal texture" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="cynefin" label="Cynefin" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="environment" label="environment" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="holarchy" label="holarchy" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="organization" label="organization" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="recursion" label="recursion" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="requisiteorganization" label="Requisite Organization" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="sensemaking" label="sense-making" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="viablesystem" label="viable system" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="worksystem" label="work system" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en-us" xml:base="http://www.ebizq.net/blogs/agile_enterprise/">
        <![CDATA[<h3>Work is Organized as a Holarchy of Viable Systems</h3>
<p>
In his excellent book "Making Work Systems Better", Luc Hoebeke (1994) develops a work systems framework that provides an alternative to monolithic, hierarchic models of organizations. Arguing that the 'span of relations' constraints the size of natural work systems to three process levels, he identifies four recursively-linked domains, each with its own language, interests and other emergent characteristics. Each domain constitutes a <em><a href="http://en.wikipedia.org/wiki/Viable_System_Model">viable system</a></em> (Beer, 1972) that <a href="http://en.wikipedia.org/wiki/Holarchy">holarchically</a> contains and is contained in a viable system. The higher domain is not managing or controlling the lower one, but rather creating conditions for its viability.
</p>]]>
        <![CDATA[<p><span class="mt-enclosure mt-enclosure-image" style="display: inline;"><a href="http://www.ebizq.net/blogs/agile_enterprise/assets_c/2011/10/four_domains.php" onclick="window.open('http://www.ebizq.net/blogs/agile_enterprise/assets_c/2011/10/four_domains.php','popup','width=2756,height=2067,scrollbars=no,resizable=no,toolbar=no,directories=no,location=no,menubar=no,status=no,left=0,top=0'); return false"><img src="http://www.ebizq.net/blogs/agile_enterprise/assets_c/2011/10/four_domains-thumb-500x375.jpg" width="500" height="375" alt="four_domains.jpg" class="mt-image-none" style="" /></a></span><br />
<strong>Figure 1. The causal texture of the environment (Emery and Trist, 1965), the respective work system domain (Hoebeke, 1994), and sense-making lens (Kurtz and Snowden, 2003).</strong></p>

<p>The first recursion level is the <strong>added-value domain</strong> that consists of activities ranging from stratum I to stratum III (in terms of Jaques's (1998) <a href="http://www.ebizq.net/blogs/agile_enterprise/2010/05/stratification-underlies-agility-preface.php">Requisite Organization</a>), encompassing a time span from 1 day to 2 years. The work systems in this domain are specialized in serving those customers, whose rather limited requirements match the capabilities of the system.</p>

<p>It can be argued that work at this level of complexity is requisite in the <em>placid, randomized environments</em> (Emery and Trist, 1965), in which organizations can exist adaptively as single and small units with no need to differentiate between tactics and strategy. </p>

<p>The second recursion level is the <strong>innovation domain</strong>, whose work system is in the process of consciously sensing and proactively creating the future. Its activities range from stratum III to stratum V, encompassing a time span from 1 to 10 years. Stratum III forms a hinge between the added-value domain and the innovation domain, as the relations between two domains need an overlapping set of common activities.</p>

<p>This level of complexity appears to be required in the <em>placid, clustered environments</em> (Emery and Trist, 1965), in which the need arises to distinguish strategy from tactics. Organizations grow in size, becoming multiple and tending towards centralized control and coordination. </p>

<p>The third recursion level is the <strong>value systems domain</strong> that is "involved in the permanent creation of the elements of a new culture by creating new languages and new descriptions and prescriptions about the world through a permanent debate between carriers of different world views, traditions and cultures." It consists of activities ranging from stratum V (again as the hinging level) to stratum VII, encompassing a time span from 5 to 50 years.</p>

<p>Following the earlier analogy, the work system at this level of complexity would face the <em>disturbed-reactive environment</em> (Emery and Trist, 1965), in which there is more than one system of the same kind and stability requires "a certain coming-to-terms between competitors". In this self-similar system-of-systems setting (Boardman and Sauser, 2006), the independence of change in constituent systems adds significantly to the complexity of the interactions and calls for explicit recognition of evolution of systems, which in turn encourages more frequent changes (Fisher 2006).</p>

<p>The fourth domain is the <strong>spiritual domain</strong> with time span beyond 20 years. Somewhat paradoxically, the processes in this domain are strongly linked to individuals, but have a universal component. Another paradox lies in the fact that what people in the spiritual domain are actually doing cannot easily be differentiated from the activities at the first process level.</p>

<p>Correspondingly, the spiritual domain would pertain to the <em>turbulent field</em> (Emery and Trist, 1965), in which the dynamic properties arise not only from the interactions of the organizations but also from the field itself - the 'ground' is in motion. The complexity exceeds individual organizations' capacities for prediction and control; they cannot adapt to the turbulent environment through their direct interactions but must rely on commonly held values as the control mechanism in the field.</p>

<h3>Cynefin: Making Sense of Increasing Complexity</h3>

<p>The <a href="http://en.wikipedia.org/wiki/Cynefin">Cynefin</a> framework (Kurtz and Snowden, 2003) is a phenomenological framework of sense-making, addressing how people perceive and make sense of situations in order to make decisions. It distinguishes five domains, of which four are discussed below: the ordered domains of "Known" (or "Simple") and "Knowable" (or "Complicated"), and the un-ordered domains "Complex" and "Chaos". The fifth domain of disorder has a distinct role as helping understand the conflict among different points of view. As such it is not considered herein. </p>

<p>In the <strong>"Known"</strong> domain, cause and effect relationships are generally linear, empirical in nature, and not open to dispute. Structured techniques and processes such as single-point forecasting, field manuals and operational procedures ensure repeatability and predictability. The decision model is to sense incoming data, categorize the data, and then respond in accordance with predetermined practice. The focus is on reliability and efficiency. This is arguably the paradigmatic mode of sense-making in the value-added domain.</p>

<p>In the <strong>"Knowable"</strong> domain, cause and effect relationships are separated over time and space in chains that may not be fully known or are understood only by a limited group of experts. This domain favors systems thinking and methods that seek to identify cause-effect relationships through the study of properties hypothetically associated with qualities, e.g. experiment, expert opinion, fact-finding, scenario planning. The decision model is to sense incoming data, analyze the data, and then respond in accordance with expert advice or interpretation of that analysis. The focus is on validity and effectiveness. Sense-making of this kind is characteristic to the innovation domain.</p>

<p>In the <strong>"Complex"</strong> domain, cause and effect relationships between interacting agents can be perceived as emergent patterns, but only in retrospect. Any attempts to categorize or analyze the retrospectively coherent patterns in a structured way are futile, as the underlying sources of the patterns cannot be readily inspected. The decision model is to create probes to elicit the patterns, then sense those patterns and respond by stabilizing the desirable patterns, while destabilizing the undesired ones. Creating a space that is conducive to desirable patterns requires multiple perspectives on the nature of the system. The methods, tools and techniques of the known and knowable domains render inadequate here. Narrative techniques are powerful, as they convey a large amount of knowledge or information in a very succinct way. The complex adaptive systems nature of the "Complex" lens appears applicable to the value systems domain.</p>

<p>In the <strong>"Chaos"</strong> domain, there are no perceivable cause and effect relationships. As the system is turbulent, there is no response time to investigate change. The potential for order is there, but only few can see it and have the courage to act thereupon. The decision model in this space is to act, quickly and decisively, to reduce the turbulence, sense the reaction to the intervention and respond accordingly. Taming the chaos appears to call for such symbol-system-transcending present-centered awareness that one might call spiritual, indeed.</p>

<h2>References</h2>
<ul>
	<li><strong>Beer, S. (1972).</strong> Brain of the Firm. Penguin Press, London.
	<li><strong>Boardman, J. and Sauser, B. (2006).</strong> System of systems - the meaning of of. 2006 IEEE/SMC International Conference on System of Systems Engineering. pp. 118-123.
	<li><strong>Emery, F.E., and Trist, E.L. (1965).</strong> "The causal texture of organisational environments", Human Relations, 18, pp. 21-32.
	<li><strong>Fisher, D.A. (2006).</strong> An Emergent Perspective on Interoperation in Systems of Systems. Technical report. Carnegie Mellon University, Software Engineering Institute.
	<li>Hoebeke, L. (1994). Making Work Systems Better: A Practitioner's Reflections. John Wiley & Sons.
	<li><strong>Jaques, E. (1998).</strong> Requisite Organization: A Total System for Effective Managerial Organization and Managerial Leadership for the 21st Century, Revised second ed. Cason Hall & Co. Publishers, Baltimore, MD.
	<li><strong>Kurtz, C.F. and Snowden, D.J. (2003).</strong> "The new dynamics of strategy: Sense-making in a complex and complicated world", IBM Systems Journal, 42(3), pp. 462-483.
</ul>]]>
    </content>
</entry>

<entry>
    <title>Levels of Governance</title>
    <link rel="alternate" type="text/html" href="http://www.ebizq.net/blogs/agile_enterprise/2011/09/levels-of-governance.php" />
    <id>tag:www.ebizq.net,2011:/blogs/agile_enterprise//77.19203</id>

    <published>2011-09-28T22:34:33Z</published>
    <updated>2011-09-28T22:35:14Z</updated>

    <summary>In my previous post, I put forth the general -- and trivial -- idea that the increasing complexity of the strategic context calls for increasingly sophisticated governance models. In the following, I will further develop the notion and outline five...</summary>
    <author>
        <name>Janne J. Korhonen</name>
        <uri>http://www.ebizq.net/MT4/mt-cp.cgi?__mode=view&amp;blog_id=77&amp;id=235</uri>
    </author>
    
        <category term="Governance" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="Organizational Development" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="capabilitymaturity" label="capability maturity" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="governance" label="governance" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="governancemodel" label="governance model" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="maturitymodel" label="maturity model" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="requisiteorganization" label="Requisite Organization" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="requisitestrata" label="requisite strata" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en-us" xml:base="http://www.ebizq.net/blogs/agile_enterprise/">
        <![CDATA[<p>In my <a href="http://www.ebizq.net/blogs/agile_enterprise/2011/09/it-governance-is-contingent-on-the-strategic-context.php">previous post</a>, I put forth the general -- and trivial -- idea that the increasing complexity of the strategic context calls for increasingly sophisticated governance models. In the following, I will further develop the notion and outline five levels of governance. The levels both represent the capability maturity of governance and pertain to a normative structural level (i.e. requisite stratum) of the organization. The more advanced the governance capabilities, the larger organizational scope can be encompassed and the greater complexity can be addressed.</p>]]>
        <![CDATA[<p>The contours outlined below provide a terse, meta-level account of the paradigmatic governance vehicles and primary purpose at each level. The model is, of course, of high generality, yet as such instantiable to a wide variety of aspect-systems (e.g. IT Governance).</p>

<p><span class="mt-enclosure mt-enclosure-image" style="display: inline;"><a href="http://www.ebizq.net/blogs/agile_enterprise/levels_of_gov.jpg"><img alt="levels_of_gov.jpg" src="http://www.ebizq.net/blogs/agile_enterprise/assets_c/2011/09/levels_of_gov-thumb-500x192.jpg" width="500" height="192" class="mt-image-none" style="" /></a></span></p>

<h3>I: Incipient</h3>
<p>
At this level, real governance does not exist, but idiosyncratic activities are guided by fixed target standards for performance. Mutual expectations and responsibilities are informal, and policies and processes still <em>incipient</em>.
</p>
<h3>II: Ordained</h3>
<p>
<em>Ordained governance</em> relies on vertical lines of command and standardization for coordination. It aims at optimizing work practices and quality standards and managing deviations from the acceptable limits of performance. Teams are endowed discretion to differentiate services to different customer groups.
</p>
<h3>III: Connective</h3>
<p>
<em>Connective governance</em> connects multiple teams across functions to rethink work systems and processes within an operational domain. Key mechanisms include structural means such as formal roles, committees and councils. Policies are set to regulate open-ended, discretionary decision-making and ensure systematic work.
</p>
<h3>IV: Coordinative</h3>
<p>
<em>Coordinative governance</em> coordinates functions and projects beyond operational domains to set goals and to devise new systems and structures. This is attained through organization-wide programs and strategic systems (e.g. balanced scorecard, critical success factor analysis, service-level agreements, performance management, profit sharing schemes, etc.). Rules are established to govern policy-making.
</p>
<h3>V: Collaborative</h3>
<p>
<em>Collaborative governance</em> integrates organizational functions to a coherent business entity to reshape the business model and establish respective norms. It calls for relational capabilities: informal collaborative relationships, value-based practices and normative controls. Vision guides the establishment of governance rules.
</p>]]>
    </content>
</entry>

<entry>
    <title>IT Governance is Contingent on the Strategic Context</title>
    <link rel="alternate" type="text/html" href="http://www.ebizq.net/blogs/agile_enterprise/2011/09/it-governance-is-contingent-on-the-strategic-context.php" />
    <id>tag:www.ebizq.net,2011:/blogs/agile_enterprise//77.19182</id>

    <published>2011-09-12T10:30:00Z</published>
    <updated>2011-09-12T10:25:37Z</updated>

    <summary>Peterson (2004) identifies three basic value drivers of IT governance: service infrastructure, solution integration and strategic innovation. In service infrastructure, the value lies in IT operations and services that are delivered with maximum reliability and availability. It focuses on standardization...</summary>
    <author>
        <name>Janne J. Korhonen</name>
        <uri>http://www.ebizq.net/MT4/mt-cp.cgi?__mode=view&amp;blog_id=77&amp;id=235</uri>
    </author>
    
        <category term="Enterprise IT" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="Governance" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="centralization" label="centralization" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="complexity" label="complexity" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="decentralization" label="decentralization" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="itgovernance" label="IT governance" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="recentralization" label="recentralization" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en-us" xml:base="http://www.ebizq.net/blogs/agile_enterprise/">
        <![CDATA[<p>Peterson (2004) identifies three basic value drivers of IT governance: service infrastructure, solution integration and strategic innovation.</p>

<p>In <em>service infrastructure</em>, the value lies in IT operations and services that are delivered with maximum reliability and availability. It focuses on standardization and synergies across the enterprise.<br />
</p>]]>
        <![CDATA[<p><em>Solution integration</em> is about offering business with IT solutions in alignment with business needs. The focus is on timely and cost-effective delivery of IT applications, business-IT alignment and IT responsiveness.</p>

<p><em>Strategic innovation</em> targets business value drivers and focuses on operational, product or customer excellence such as reduced transaction costs, improved time-to-market, improved customer satisfaction and retention, revenue growth, improved ROA, or profitability.</p>

<p><span class="mt-enclosure mt-enclosure-image" style="display: inline;"><a href="http://www.ebizq.net/blogs/agile_enterprise/itg-contingency.jpg"><img alt="itg-contingency.jpg" src="http://www.ebizq.net/blogs/agile_enterprise/assets_c/2011/09/itg-contingency-thumb-500x343.jpg" width="500" height="343" class="mt-image-none" style="" /></a></span><br />
<strong>Figure 1. IT governance architecture is contingent on the complexity of the strategic context.</strong></p>

<p>As illustrated in Figure 1, the complexity of IT governance model is contingent on the value drivers (Peterson 2004), which, in turn, reflect the complexity of the strategic context. An organization that operates in a relatively static, simple, and predictable environment (i.e. stratum I-III complexity) has routine technology and a mechanistic structure (Volberda 1996). It is well off pursuing the service infrastructure value driver that, according to Peterson (2004), calls for a <em>centralized</em> IT governance model.</p>

<p>An organization that operates in a dynamic and/or complex but largely predictable environment (i.e. stratum III-V complexity) requires operational flexibility and more nonroutine technology (Volberda 1996). It needs to pursue both the service infrastructure and solution integration value drivers and adopt an IT-centric federal model to meet both enterprise-wide and business-specific demands (Peterson 2004). IT governance architectures tend to <em>decentralize</em>.</p>

<p>A fundamentally unpredictable environment, which may also be dynamic and complex (i.e. stratum V+ complexity), calls for broad flexibility, organic structure and nonroutine technology (Volberda 1996). All three value drivers need to be pursued: service infrastructure, solution integration, and strategic innovation. In this context, a business-centric federal model is required (Peterson 2004): IT decision-making authority over customer business applications is allocated to local business executives to address the demands for strategic innovation. Fragmentation due to increasing differentiation of IT decision-making must be counter-balanced with respective governance <em>recentralization</em>.</p>

<h3>References</h3>
<ul>
	<li>Peterson, R. (2004). "Crafting Information Technology Governance", EDPACS - The EDP Audit, Control, and Security Newsletter, December 2004, 2-24.</li>
	<li>Volberda, H.W. (1996). "Toward the flexible form: How to remain vital in hypercompetitive environments", Organization Science, 7 (4), 359-374.</li>
</ul>

<p><br />
</p>]]>
    </content>
</entry>

<entry>
    <title>Organizational Transformations: Changing to Stay the Same</title>
    <link rel="alternate" type="text/html" href="http://www.ebizq.net/blogs/agile_enterprise/2011/08/organizational-transformations-changing-to-stay-the-same.php" />
    <id>tag:www.ebizq.net,2011:/blogs/agile_enterprise//77.19155</id>

    <published>2011-08-21T18:04:03Z</published>
    <updated>2011-08-21T18:01:26Z</updated>

    <summary>In my previous post, I discussed how a system must undergo a transformation to persist and to develop. As the notion of ecosystem resilience, introduced therein, may have remained somewhat abstract and elusive, I will here attempt to exemplify systemic...</summary>
    <author>
        <name>Janne J. Korhonen</name>
        <uri>http://www.ebizq.net/MT4/mt-cp.cgi?__mode=view&amp;blog_id=77&amp;id=235</uri>
    </author>
    
        <category term="Organizational Development" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="adaptivecycle" label="adaptive cycle" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="organizationalecology" label="organizational ecology" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="organizationalgrowth" label="organizational growth" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="organizationaltransformation" label="organizational transformation" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en-us" xml:base="http://www.ebizq.net/blogs/agile_enterprise/">
        <![CDATA[<p>In my <a href="http://www.ebizq.net/blogs/agile_enterprise/2011/07/when-less-is-too-much.php">previous post</a>, I discussed how a system must undergo a transformation to persist and to develop. As the notion of <em>ecosystem resilience</em>, introduced therein, may have remained somewhat abstract and elusive, I will here attempt to exemplify systemic transformations in the context of organizations. To this end, I will draw from some classical literature in population and organizational ecology and in organizational growth. Some implications are suggested in conclusion.</p>]]>
        <![CDATA[<h2>Environmental Selection of Organizations</h2>

<p>According to Hawley (1968), the diversity of organizational forms is isomorphic to the diversity of environments, i.e. each organizational form is optimally adapted to the respective environmental configuration. Hannan and Freeman (1977) supplement the principle of isomorphism by a criterion of selection and a competition theory. They point out that, from a population ecology perspective, the environment selects out optimal combinations of organizations. The equilibrium of very similar resource-limited competitor populations is inherently unstable -- the greater the similarity of resource-limited competitors, the less feasibly a single environment can support them in equilibrium.</p>

<p>Thereby, the saturation of markets, resulting from the diffusion of innovations (Rogers, 1962), exhausts the resilience of the industry and causes some organizations to find "greener grass" at the higher level of ordering and some to be eliminated by the competition. Pure environmental selection (survival or failure of entire organizations) pertains mainly to small businesses, whereas structural overhauls exist for all organizations (Aldrich and Pfeffer, 1976).</p>

<h2>Ecological Dynamics: The Adaptive Cycle</h2>

<p>The Adaptive Cycle framework by Gunderson and Holling (2002) is a metaphor that attempts to provide a general account of the organization and dynamics of complex adaptive systems. Originating from experience with productive biotic ecosystems, the concept has tentatively been considered also in other contexts, including human organizations.</p>

<p>The Adaptive Cycle circles in three dimensions: the potential available for change, the degree of connectedness, and the resilience of the system. The accumulating potential can be manifested as things like skills, networks of human relationships, and mutual trust. Connectedness refers to the degree of internal control that a system can exert over external variability. The third property, ecosystem resilience, represents the capacity of a system to experience disturbance and still maintain its ongoing functions and controls. The first two of these dimensions, potential and connectedness, are depicted in Figure 1.</p>

<p><span class="mt-enclosure mt-enclosure-image" style="display: inline;"><a href="http://www.ebizq.net/blogs/agile_enterprise/adaptive_cycle.jpg"><img alt="adaptive_cycle.jpg" src="http://www.ebizq.net/blogs/agile_enterprise/assets_c/2011/08/adaptive_cycle-thumb-500x366.jpg" width="500" height="366" class="mt-image-none" style="" /></a></span></p>

<p><strong>Figure 1. Adaptive Cycle (adapted from Gunderson and Holling, 2002).</strong></p>

<p>In addition to the two traditional ecosystem functions of exploitation and conservation, constituting the "front loop" of the cycle, Gunderson and Holling (2002) propose two additional phases of the "back loop": release and reorganization.</p>

<p>In the <strong>reorganization (α)</strong> phase, the system's connectedness is low and potential and resilience are high. This allows reassembling elements that have previously been tightly connected and creates auspicious conditions for creative experimentation: a favorable substrate for the appearance and initial establishment of entities that otherwise would be out-competed. Random new constellations of elements can generate unexpected processes of growth, but the α phase is also vulnerable to unexpected crises. Variation may be introduced into the organizational population through the creation of new organizations as well as through innovation. </p>

<p>The <strong>exploitation</strong>, or <strong>r</strong> phase, represents a period of competition among pioneers, such as start-up organizations, and survivors from previous cycles. Stable configurations are retained, while unstable ones are eliminated. Once the system has found its new structure, it starts a progression from r to K, exploiting stable configurations and sustaining <a href="http://pespmc1.vub.ac.be/AUTOCAT.html">autocatalytic growth</a>. Connectedness between interrelated entities increases and potential accumulates, while resilience of the system decreases.</p>

<p>In the <strong>conservation (K)</strong> phase, markets for products saturate, profit margins decrease, technologies diffuse, and organizations become bureaucratized and rigid. The resilience of the system shrinks and makes it vulnerable to external variability that exceeds its controllability and triggers the next cycle. The system reaches a critical threshold, where the contracting stability domain makes the structure vulnerable to crisis and subject to transformation.</p>

<p>The <strong>release (Ω)</strong> phase denotes a sudden increase in uncertainty. After a long period of somewhat predictable behavior, chaotic behavior ensues. This phase starts the rapid back-loop from Ω to α, the outcomes of which can be highly unpredictable and uncertain.</p>

<h2>Phases of Growth</h2>

<p>In his model of how organizations develop, Greiner (<a href="http://ils.unc.edu/daniel/131/cco4/Greiner.pdf">1998</a> [1972]) identifies five phases of evolution punctuated by five revolutionary crises. Each phase has inherent limits for growth exploiting its dominant logic. At some point, a crisis of some sort ensues and needs to be resolved through a new logic within which the growth of the organization can continue, lest the organization implodes. Each phase is a result of the previous phase as well as a cause for the next phase.</p>

<p>In Table 1, Greiner's model is associated with the phases of the Adaptive Cycle.</p>

<p><strong>Table 1. Adaptive Cycle and Phases of Organizational Growth.</strong></p>

<p><span class="mt-enclosure mt-enclosure-image" style="display: inline;"><a href="http://www.ebizq.net/blogs/agile_enterprise/phases.jpg"><img alt="phases.jpg" src="http://www.ebizq.net/blogs/agile_enterprise/assets_c/2011/08/phases-thumb-600x471.jpg" width="600" height="471" class="mt-image-none" style="" /></a></span></p>

<h3>Phase 1: Creativity</h3>

<p>The emphasis of an upstart company is on making and selling a new product or service rather than on management activities. Things are done creatively, idiosyncratically and informally, but this entrepreneurial logic holds only to a certain point. Sooner or later the founders face the crisis of leadership: increasing management responsibilities that they are unwilling and unable to successfully take on. They need to find and install a strong business manager who will introduce business discipline to pull the organization together. The enterprising founders of foundering enterprises find the enterprise of finding a leader futile. The founders of leading enterprises find it utile to enter one.</p>

<h3>Phase 2: Direction</h3>

<p>Under directive leadership of the new manager, a functional organizational structure is introduced and formal systems such as budgeting, accounting and work standards are adopted. The efficiency improvements drive sustained growth until the crisis of autonomy: the centralized hierarchy renders rigid in the increasingly diverse and complex organization. The lower-level managers and employees need to be empowered to take initiative on their own. Continued adherence to centralized methods inhibits growth, as the top-level lacks direct knowledge about local context and the lower-level managers do not learn to make decisions for themselves.</p>

<h3>Phase 3: Decentralization [Delegation]</h3>

<p>The decentralization phase (or delegation phase in Greiner's original terminology) allows the organization to expand to larger markets, respond faster to customers and develop new products or services. Decentralization, however, is sowing the seeds of the next crisis: the crisis of control. The increasing autonomy and freedom of operations develops to a point, where the control over the organization as a whole is lost. At this point, attempts to return to centralized management are doomed to fail, while new growth can be found through coordination between managers.</p>

<h3>Phase 4: Coordination</h3>

<p>In this phase, the reorganization takes place through coordinative means such as organization-wide programs, federated governance mechanisms and profit sharing schemes. The organization's limited resources can be allocated better to enable further growth. However, the many systems and programs outgrow their original intention and become overly bureaucratic. The ensuing red-tape crisis can be resolved through less formal, normative control and interpersonal collaboration, whereas sticking with rigid and formal procedures and failing to collaborate gets one nowhere.</p>

<h3>Phase 5: Collaboration</h3>

<p>The organization reorganizes around problem-solving teams and other collaborative bodies. Greiner does not specify how the new collaborative logic supports growth in this phase, but it can be argued that the organization renews itself through value innovation. No internal solution stimulates further growth, but the organization needs to look outside for extra-organizational arrangements (e.g. corporate form, network organization). Otherwise, growth is capped within the organizational system.</p>

<h2>Concluding Implications</h2>

<p>The development of an organization transpires through phases of steady evolution punctuated by phases of rapid, radical revolution. Each phase of growth has its distinctive organizing logic that has limited applicability in other phases. Paraphrasing <a href="http://en.wikipedia.org/wiki/Willem_de_Kooning">Willem de Kooning</a>: the organization has to change to stay the same. In a way, the revolution devours its parents, as the solutions that managers introduce in one phase sow the seeds of the revolution that renders them obsolete in the next. It is no wonder then that resistance to change is so pervasive: the managers at the top may be a perfect match with the status quo, but just not fit with where the organization is stretching next. The challenge is to ensure "requisite alignment" of leadership capabilities and work complexity in and across the organizational growth phases.</p>

<p>Strategic growth calls for a conscious approach to the underlying developmental dynamics in the organization: sensitivity to both the phase of growth and the phase of the Adaptive Cycle the organization is in. The board and CEO should ensure that business planning, performance measurement, organization/work design, executive development and talent management are all integrated to a coherent organizational system with consideration to these dynamics.</p>

<h2>References</h2>
<ul>
<li>Aldrich, H.E., Pfeffer, J., 1976. "Environments of organizations". Annual Review of Sociology, 2, pp. 79-105. 
<li>Greiner, L.E., 1998 [1972]. "<a href="http://ils.unc.edu/daniel/131/cco4/Greiner.pdf">Evolution and revolution as organizations grow</a>". Harvard Business Review, May-June 1998 [originally published in the July-August 1972 issue]. 
<li>Gunderson, L.H., Holling, C.S. (Eds.), 2002. <a href="http://www.amazon.com/Panarchy-Understanding-Transformations-Natural-Systems/dp/1559638575">Panarchy: Understanding transformations in human and natural systems</a>. Island Press, Washington, DC.
<li>Hannan, M.T., Freeman, J., 1977. "The population ecology of organizations". The American Journal of Sociology, 82, pp. 929-964.
<li>Hawley, A.H., 1968. "Human Ecology", in: Sills, D.L. (Ed.): International encyclopedia of the social sciences. Macmillan, New York, pp. 328-337.
<li>Rogers, E.M. 1962. Diffusion of innovations. Free Press, New York.
</ul>]]>
    </content>
</entry>

<entry>
    <title>When Less Is Too Much</title>
    <link rel="alternate" type="text/html" href="http://www.ebizq.net/blogs/agile_enterprise/2011/07/when-less-is-too-much.php" />
    <id>tag:www.ebizq.net,2011:/blogs/agile_enterprise//77.19094</id>

    <published>2011-07-09T18:10:15Z</published>
    <updated>2011-07-09T18:10:54Z</updated>

    <summary>Sometimes less is too much. Inexorably, at some point, the organization or logic of a system that has worked well in the past turns out inadequate in the face of changing environmental circumstances. The inherent limits of system resilience --...</summary>
    <author>
        <name>Janne J. Korhonen</name>
        <uri>http://www.ebizq.net/MT4/mt-cp.cgi?__mode=view&amp;blog_id=77&amp;id=235</uri>
    </author>
    
        <category term="Organizational Development" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="bifurcation" label="bifurcation" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="complexity" label="complexity" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="dissipativestructure" label="dissipative structure" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="resilience" label="resilience" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="systemsthinking" label="systems thinking" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en-us" xml:base="http://www.ebizq.net/blogs/agile_enterprise/">
        <![CDATA[<p>Sometimes less is too much. Inexorably, at some point, the organization or logic of a system that has worked well in the past turns out inadequate in the face of changing environmental circumstances. The inherent limits of system resilience -- the ability of the system to absorb perturbations in its stability domain -- are reached and the system must transform to survive. This can occur at any scale. For instance, a person cannot quite cope with his/her new job role but needs to grow to the new demands; an organization cannot grow indefinitely and maintain its original form; or the very underpinnings of the economy are threatened, as is now alarmingly apparent.</p>]]>
        <![CDATA[<p>The "<a href="http://www.eoht.info/page/Bifurcation">bifurcation point</a>" at the "<a href="http://en.wikipedia.org/wiki/Edge_of_chaos">edge of chaos</a>" is a revolutionary moment that opens a "window of opportunity" for reorganizing a system at a higher, more differentiated and coherent order of functioning. This "<a href="http://pespmc1.vub.ac.be/ASC/Dissip_struc.html">dissipative structure</a>" requires more energy to sustain it than the simpler structure, which it replaced, but its resilience in the new stability domain is higher. It is also possible that the bifurcation point leads to the disintegration of the system into chaos: the person suffers a setback; the organization falls; or the economy collapses.</p>

<p>The ecological literature identifies two very different notions of resilience. The traditional notion of <em>engineering resilience</em> is focused on maintaining efficiency of function and stability near an equilibrium steady state. It is measured by resistance to disturbance and speed of return to the equilibrium. The second definition, termed as <em>ecosystem resilience</em>, comes into play in far-from-equilibrium conditions, where the system may enter another stability domain. This type of resilience is focused on maintaining existence of function and measured by the magnitude of disturbance that can be absorbed before the system changes its structure. (<a href="http://www.amazon.com/Panarchy-Understanding-Transformations-Natural-Systems/dp/1559638575">Gunderson and Holling, 2002</a>).</p>

<p>Gunderson and Holling (2002) point out that exclusive emphasis on engineering resilience "reinforces the dangerous myth that the variability of natural systems can be effectively controlled, that the consequences are predictable, and that sustained maximum production is an attainable and sustainable goal". It is based on the assumption of global stability -- that the system's local variables should be manipulated to maintain the target steady state, notwithstanding alternative operating states. While the variability can be successfully limited to stay on target, the ignorance to slowly changing variables in the overall stability landscape subtly shrinks the system's ecosystem resilience.</p>

<p>Equilibrium-seeking <a href="http://www.ebizq.net/blogs/agile_enterprise/2011/03/requisite-system-view-to-enterprise-architecture.php">system views</a> (static, reactive and responsive) must necessarily ignore or attempt to suppress anomalies that bear the seeds of future patterns of behavior. With the primary goal of protecting and sustaining the status quo for as long as possible, the still-prevalent command-and-control approaches to management and governance often fall seriously short in today's increasingly <a href="http://en.wikipedia.org/wiki/Volatility%2C_uncertainty%2C_complexity_and_ambiguity">volatile, uncertain, complex and ambiguous</a> business environment.</p>

<p>To fully <a href="http://en.wikipedia.org/wiki/Grok">grok</a> multiple systems and their interrelationships and systems that undergo radical transformation, a (co-)evolving system view is required. Rather than seeking stability and avoiding disruptions, this view acknowledges the reality of multiple equilibria (potential alternative states) and embraces resilient renewal, as the circumstances require. It emphasizes creating auspicious conditions for adaptive self-organization and endogenous emergence of new structures, not on rigid imposition of any predetermined orderly system.</p>

<p>Intentional design, implementation and maintenance of pertinent organizational and governance (meta-)structures does dissipate energy, but under certain conditions any less is simply too much.<br />
</p>]]>
    </content>
</entry>

<entry>
    <title>Requisite Cognitive Logics in Enterprise Architecture</title>
    <link rel="alternate" type="text/html" href="http://www.ebizq.net/blogs/agile_enterprise/2011/07/requisite-cognitive-logics-in-enterprise-architecture.php" />
    <id>tag:www.ebizq.net,2011:/blogs/agile_enterprise//77.19087</id>

    <published>2011-07-05T14:03:15Z</published>
    <updated>2011-07-05T14:03:13Z</updated>

    <summary>In my last two blog posts, I have outlined a five-scale classification of system views and elaborated on the systemic-structural underpinnings of each view. As these systemic views are increasingly expressive and powerful, they also call for progressively sophisticated levels...</summary>
    <author>
        <name>Janne J. Korhonen</name>
        <uri>http://www.ebizq.net/MT4/mt-cp.cgi?__mode=view&amp;blog_id=77&amp;id=235</uri>
    </author>
    
        <category term="Enterprise Architecture" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="Enterprise Engineering" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="cognitivelogic" label="cognitive logic" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="modelofhierarchicalcomplexity" label="model of hierarchical complexity" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="systemview" label="system view" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="systemsthinking" label="systems thinking" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en-us" xml:base="http://www.ebizq.net/blogs/agile_enterprise/">
        <![CDATA[<p>In my last two blog posts, I have <a href="http://www.ebizq.net/blogs/agile_enterprise/2011/03/requisite-system-view-to-enterprise-architecture.php">outlined a five-scale classification of system views</a> and <a href="http://www.ebizq.net/blogs/agile_enterprise/2011/05/system-views-revisited-systemic-structural-underpinnings.php">elaborated on the systemic-structural underpinnings</a> of each view. As these systemic views are increasingly expressive and powerful, they also call for progressively sophisticated levels of cognitive sense-making. In the following, I will suggest how the different cognitive logics, as identified in stage-based approaches of adult developmental psychology, pertain to the five systemic views. Further, I will discuss what cognitive capabilities would be required from an (enterprise/business/solution/system) architect or a system engineer with respect to different systemic lenses and respective work levels. These conjectures are summarized in Table 1.</p>]]>
        <![CDATA[<p><strong>Table 1. Cognitive logics pertaining to different system views.</strong></p>

<p><span class="mt-enclosure mt-enclosure-image" style="display: inline;"><a href="http://www.ebizq.net/blogs/agile_enterprise/table1.jpg"><img alt="table1.jpg" src="http://www.ebizq.net/blogs/agile_enterprise/assets_c/2011/07/table1-thumb-500x295.jpg" width="500" height="295" class="mt-image-none" style="" /></a></span></p>

<h3>Static System View</h3>
<p>
In static system view, the output of design and implementation work is clearly <em>prescribed</em> (cf. Rowbottom and Billis, 1987) by specifications, requirements, quality standards and acceptance criteria. It is even desirable that the system engineer reacts to provided stimuli without understanding and questioning the broader business context. This type of work can be readily outsourced and offshored.
</p><p>
Successful operation at this level calls for at least <em>primary</em> stage (7) logic in terms of <a href="http://en.wikipedia.org/wiki/Model_of_Hierarchical_Complexity">Model of Hierarchic Complexity (MHC)</a> (e.g. Commons et al., 1998). There is no need to connect events and perceptions (Fowler et al., 2004); information processing has a disjunctive, declarative quality (Jaques and Cason, 1994).
</p>

<h3>Reactive System View</h3>
<p>
In reactive system view, the response to each case of work is <em>situational</em> (cf. Rowbottom and Billlis, 1987) and depends on judgment and interpretation. The work of the system architect involves assessment of and adjustment to the varying requirements within specified architectural standards and work practices.
</p><p>
<em>Concrete</em> stage (8) (Commons et al., 1998) logic required at this level allows coordination of primary stage operations. Information processing has a pulled-together, conjunctive quality (Jaques and Cason, 1994). The person must be able to construct a series of events; classify, group and compare things; and comprehend cause-and-effect relationships. The focus is on concrete, visible aspects of reality that are empirically tested. Reasoning is inductive and based on concrete experience. (Fowler et al., 2004).
</p>
<h3>Responsive System View</h3>
<p>
In responsive system view, work is conceptualized as a system that accommodates to the varying needs of today as well as those of tomorrow. Rowbottom and Billis (1987) refer to this abstraction as <em>systematic provision</em>. The solution architect must be able to construct new, systemic resource assemblies towards ends as predefined in functional requirements.
</p><p>
In the <em>abstract</em> stage (9) (Commons et al., 1998), required at this level, the person must be able to construct hypothetical entities, simple theories and generalizations; think beyond the present moment and imagine possibilities; and make deductions from observable results (Fowler et al., 2004). This logic entails abstract thought and operations -- multiple views, permutations and careful comparison between pairs of items (Cook-Greuter, 2005) -- but there is usually no second-order reflection on thought itself (Fowler et al., 2004).
</p><p>
Up to this point, the problem space has been relatively well-structured: procedural, linear, deterministic and within a single domain. Beyond this level, problems become increasingly ill-structured: explorative, non-linear, probabilistic and crossing several domains.
</p>
<h3>Proactive System View</h3>
<p>
In proactive system view, work entails <em>comprehensive provision</em> (Rowbottom and Billis, 1987), where the means and ends of underlying work systems are adjusted to reshape profitability. The business architect must be able to translate high-level business requirements to conceptual functional requirements that specify the solutions
</p><p>
This work requires the cognitive logic of <em>formal operational</em> stage (10) (Commons et al., 1998): ability to construct systems, to analyze multi-dimensional problems and to be aware of contradictions and inconsistencies, alternatives and contingencies. Thought processes are systematic and reflective on thought itself. The person at this level shall appreciate inherent conceptual complexity; be capable of rigorous hypothesis testing, assessment and reorientation towards new goals; and logically justify worldviews. He or she is concerned about consequences and priorities and planful about actions. (Fowler et al., 2004; Cook-Greuter, 2005).
</p>
<h3>Co-Evolving System View</h3>
<p>
In co-evolving system view, the scope extends to a framework that specifies a general field of need (cf. Rowbottom and Billis, 1987). The entire unified complex system is objectified and seen from the outside. Likewise, the (lead) enterprise architect, operating at this level, must be able to holistically understand the enterprise system in its entirety within the larger context.
</p><p>
This view calls for <em>systematic</em> (11) logic (Commons et al., 1998): ability to understand phenomena in all their complexity, to coordinate several aspects of multiple abstractions simultaneously from different perspectives, and to recognize the relativity of all positions (Fowler et al., 2004). The logic aims at holistic understanding of things. The tendency to define system boundaries gives way to a more "open systems" approach. Paradoxes and contradictions are embraced, not explained away or resolved towards a closure around a preconceived system (Cook-Greuter, 2005).
</p>
<h3>References</h3>
<p>
<ul>
<li>Commons, M.L., Trudeau, E.J., Stein, S.A., Richards, F.A. and Krause, S.R. (1998).  "The existence of developmental stages as shown by the hierarchical complexity of tasks".  <em>Developmental Review</em>, 8(3), 237-278.
<li>Cook-Greuter, S. (2005). "Ego Development: Nine Levels of Increasing Embrace".
<li>Fowler, J.W., Streib, H. and Keller, B. (Eds.) (2004). <em>Manual for Faith Development Research</em>. 3rd edition.
<li>Jaques, E. and Cason, K. (1994). <em>Human Capability: A Study of Individual Potential and Its Application</em>. Falls Church, VA: Cason Hall & Co Publishers Ltd.
<li>Rowbottom, R.  and Billis, D. (1987). <em>Organisational Design: The Work-Levels Approach</em>. Gower, Aldershot, UK.
</ul>
</p>]]>
    </content>
</entry>

<entry>
    <title>System Views Revisited: Systemic-Structural Underpinnings</title>
    <link rel="alternate" type="text/html" href="http://www.ebizq.net/blogs/agile_enterprise/2011/05/system-views-revisited-systemic-structural-underpinnings.php" />
    <id>tag:www.ebizq.net,2011:/blogs/agile_enterprise//77.19002</id>

    <published>2011-05-08T11:58:00Z</published>
    <updated>2011-05-08T11:58:10Z</updated>

    <summary>In my latest blog post, I outlined a five-scale classification of system views and discussed tentatively how those system views would pertain to Enterprise Architecture. In the following, I will elaborate on the systemic-structural underpinnings of each view and relate...</summary>
    <author>
        <name>Janne J. Korhonen</name>
        <uri>http://www.ebizq.net/MT4/mt-cp.cgi?__mode=view&amp;blog_id=77&amp;id=235</uri>
    </author>
    
        <category term="Enterprise Engineering" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="systemview" label="system view" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="systemicorganization" label="systemic organization" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="systemicstructure" label="systemic structure" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="systemsthinking" label="systems thinking" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en-us" xml:base="http://www.ebizq.net/blogs/agile_enterprise/">
        <![CDATA[<p>In my <a href="http://www.ebizq.net/blogs/agile_enterprise/2011/03/requisite-system-view-to-enterprise-architecture.php">latest blog post</a>, I outlined a five-scale classification of system views and discussed tentatively how those system views would pertain to Enterprise Architecture.  In the following, I will elaborate on the systemic-structural underpinnings of each view and relate the ideas to a business organization.</p>]]>
        <![CDATA[<p>In their groundbreaking work in systems biology, Humberto Maturana and Francisco Varela made an important distinction between the <em>organization</em> and the <em>structure</em> of the system. The organization of the system defines its identity in terms of inter-component relationships. It specifies a category, which can be realized through specific structures. A system is organized of subsystems, each of which, from the parent system's point of view, represents the externally manifest structure, and, from its own perspective, recursively, has an internal organization. A system may change its structure without loss of identity, as long as its organization is maintained. The concepts of organization and structure are illustrated in Figure 1.</p>

<p>In the context of a business organization, for instance, the systemic structure would comprise of relatively independent yet interrelated organizational sub-domains, e.g. capabilities, business processes, business system domains -- depending on how you slice it. Change any of these subsystems or replace it with a commensurate structure -- an improved capability, an outsourced business function -- and the system retains its systemic organization and its fundamental identity. Remove such a subsystem, however, add one and/or fundamentally alter the constellation of subsystems, and you will essentially change the organization of the system.</p>

<p><span class="mt-enclosure mt-enclosure-image" style="display: inline;"><a href="http://www.ebizq.net/blogs/agile_enterprise/assets_c/2011/05/sys-org-struct.php" onclick="window.open('http://www.ebizq.net/blogs/agile_enterprise/assets_c/2011/05/sys-org-struct.php','popup','width=2626,height=1462,scrollbars=no,resizable=no,toolbar=no,directories=no,location=no,menubar=no,status=no,left=0,top=0'); return false"><img src="http://www.ebizq.net/blogs/agile_enterprise/assets_c/2011/05/sys-org-struct-thumb-500x278.jpg" width="500" height="278" alt="sys-org-struct.jpg" class="mt-image-none" style="" /></a></span></p>

<p><strong>Figure 1. Systemic-structural underpinnings of system views</strong></p>

<p>It appears that the progressively sophisticated system views can be described in terms of structural and organizational change and transformation:</p>

<p>In the <strong>Static</strong> view, both the systemic structure and organization are invariant. This can be characterized as "stability in change". In this view, change is limited to optimizing the existing structure to produce a prescribed output. </p>

<p>The <strong>Reactive</strong> view is about "change in stability". Change is seen as something external that needs to be "managed". This view recognizes structural change -- improvement and adaptation of work practices and quality standards -- but does not yet allow for re-conceptualization of work systems (i.e. structural transformation).</p>

<p>The <strong>Responsive</strong> view could be characterized as "adaptability in change". Change is imposed from the outside and calls for effective adaptation. The view allows for major structural transformations, e.g. introduction of an ERP system, but the systemic organization remains invariant.</p>

<p>The <strong>Proactive</strong> view represents "change in adaptability". Change can be endogenously initiated by the system and directed to developmental ends. In this view, change in the systemic organization is possible. In the context of a business organization, this could, for instance, be manifested as re-engineering end-to-end business processes or introducing new products and services.</p>

<p>The <strong>Evolving</strong> system view addresses organizational transformation. Change, in this view, is an incessant, all-permeating reality. The system is able to transform its systemic organization, accordingly. For instance, a business organization may transform its very business model and propagate requisite organizational and structural changes throughout the system.</p>]]>
    </content>
</entry>

<entry>
    <title>Requisite System View to Enterprise Architecture</title>
    <link rel="alternate" type="text/html" href="http://www.ebizq.net/blogs/agile_enterprise/2011/03/requisite-system-view-to-enterprise-architecture.php" />
    <id>tag:www.ebizq.net,2011:/blogs/agile_enterprise//77.18934</id>

    <published>2011-03-27T17:44:08Z</published>
    <updated>2011-03-27T17:44:19Z</updated>

    <summary>Enterprise Architecture (EA) provides a representation of the business in terms of its components and component relationships in order to facilitate business change. It mediates our knowledge and understanding of the underlying organizational system and focuses our attention to the...</summary>
    <author>
        <name>Janne J. Korhonen</name>
        <uri>http://www.ebizq.net/MT4/mt-cp.cgi?__mode=view&amp;blog_id=77&amp;id=235</uri>
    </author>
    
        <category term="Enterprise Architecture" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="businesschange" label="business change" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="enterprisearchitecture" label="enterprise architecture" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="systemsthinking" label="systems thinking" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en-us" xml:base="http://www.ebizq.net/blogs/agile_enterprise/">
        <![CDATA[<p>Enterprise Architecture (EA) provides a representation of the business in terms of its components and component relationships in order to facilitate business change. It mediates our knowledge and understanding of the underlying organizational system and focuses our attention to the relevant aspects thereof. Thereby, the systemic lens through which EA is conceptualized determines the leverage of change that it supports. It is of essence that EA requisitely reflects the degree of business change that it is purported to support. "<a href="http://en.wikipedia.org/wiki/Map%E2%80%93territory_relation">The map is not the territory</a>", but it is useful insofar it is structurally isomorphic to the territory.</p>]]>
        <![CDATA[<p>In the following, I will put forth a five-scale classification of system views, discuss the leverage of change characteristic to each view, and suggest the respective requisite approach to EA. Figure 1 illustrates these conjectures.</p>

<p><span class="mt-enclosure mt-enclosure-image" style="display: inline;"><a href="http://www.ebizq.net/blogs/agile_enterprise/assets_c/2011/03/requisite_system_views.php" onclick="window.open('http://www.ebizq.net/blogs/agile_enterprise/assets_c/2011/03/requisite_system_views.php','popup','width=2751,height=1421,scrollbars=no,resizable=no,toolbar=no,directories=no,location=no,menubar=no,status=no,left=0,top=0'); return false"><img src="http://www.ebizq.net/blogs/agile_enterprise/assets_c/2011/03/requisite_system_views-thumb-500x258.jpg" width="500" height="258" alt="requisite_system_views.jpg" class="mt-image-none" style="" /></a></span><br />
<strong>Figure 1. Progressive system views pertain to increasing levers of change.</strong></p>

<h3>Static System</h3>
In the static system view, the structural properties, the state and the throughput of the system do not display consequential change over time. The focus is on context: how the parts are related to the whole. The system can be adequately conceptualized as a closed system, i.e. as a self-contained system with no interaction with external elements.

<p>The static system view is hardly enough to conceptualize any organization as a whole, but it has some applicability in optimizing the structure and performance of organizational subsystems under relatively steady-state conditions. EA that reflects this view serves the purpose of reducing costs and improving efficiency, mostly at the infrastructure level.</p>

<h3>Reactive System</h3>
In the reactive system view, the organization exhibits dynamic stability: it seeks internal stability and retains its state in a changing environment by internal adjustments.  The reaction to changes is deterministic: when perturbed, the system will seek internal equilibrium through negative feedback. As the system interacts with and is affected by its environment, the closed system view is inadequate and open system characteristics come into play.

<p>The reactive system view is requisite in a "business as usual" setting. It is required when the situational variety calls for some degree of assessment and adaptation, but the basic means towards the ends need not be changed. EA reflects the reactive system view with its emphasis on processes, work practices and quality standards: architectural support of implementation projects, development guidelines, change management practices, etc. Reactive EA supports reliable business-IT alignment and focuses on changes in the information systems landscape.</p>

<h3>Responsive System</h3>
In the responsive system view, the system is able to learn. Whereas a reaction is deterministically caused by an event, a response entails a choice of behavior. The responsive system is able to counter large displacements from equilibrium and even enter a new equilibrium domain as the resilience of its prior equilibrium domain becomes exhausted.

<p>The responsive system view is required to address not only the tried-and-true but also the conceivable future contingencies. The view allows devising new means to achieve the goals, but not changing those goals. In the responsive system view, EA emphasizes effectiveness. The importance of inter-domain relationships is heightened. Reusable architecture building blocks enable expeditious reassembly of business processes and solution architecture practice facilitates capability improvement.</p>

<h3>Proactive System</h3>
In the proactive system view, the organization initiates change and reinforces it through positive feedback rather than reacts or responds to events and dampens change through negative feedback mechanisms. The organization is autonomous with respect to setting its goals. The proactive system exhibits <em>chaordic</em> properties: its behavior is unpredictable yet patterned, chaotic and orderly, simultaneously.

<p>The proactive system view is required when introducing new products or services and changing the means and ends of respective work systems within the overall business purpose. Proactive EA embraces business architecture, linking enterprise assets and capabilities with BA elements such as products, services, organizational goals, core competencies and strategic change programs.</p>

<h3>Evolving System</h3>
In the evolving system view, the system and its constituents co-evolve with and co-adapt to other systems and their components at all levels of scale. The stability landscape is dynamically changing as each agentic system strives to increase its fitness function vis-à-vis other agents, and the overall behavior of the "system of systems" emerges through this self-organization.

<p>The evolving system view is required when the organization is endogenously generating its goals and transforming itself accordingly. It is needed when the very value proposition and the respective business model of the organization, including an entire range of products and services, must be changed. EA, as per this view, must enable continuous transformative change at the SBU level and ensure sustained resilience (cf. "<a href="http://blogs.gartner.com/nick_gall/2011/01/24/panarchitecture-architecting-a-network-of-resilient-renewal/">panarchitecture</a>").<br />
</p>]]>
    </content>
</entry>

<entry>
    <title>Towards Business-IT Confluence</title>
    <link rel="alternate" type="text/html" href="http://www.ebizq.net/blogs/agile_enterprise/2011/02/towards-business-it-confluence.php" />
    <id>tag:www.ebizq.net,2011:/blogs/agile_enterprise//77.18847</id>

    <published>2011-02-13T18:00:00Z</published>
    <updated>2011-02-13T18:01:11Z</updated>

    <summary>Information technology has traditionally been seen as mere &quot;cost of doing business&quot; that is &quot;aligned&quot; with business at best. As IT infrastructure has commoditized at operational levels and the business environment has become increasingly complex, however, the focus of IT...</summary>
    <author>
        <name>Janne J. Korhonen</name>
        <uri>http://www.ebizq.net/MT4/mt-cp.cgi?__mode=view&amp;blog_id=77&amp;id=235</uri>
    </author>
    
        <category term="Enterprise IT" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="businessitalignment" label="business-IT alignment" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="businessitconfluence" label="business-IT confluence" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="itenablement" label="IT enablement" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en-us" xml:base="http://www.ebizq.net/blogs/agile_enterprise/">
        Information technology has traditionally been seen as mere &quot;cost of doing business&quot; that is &quot;aligned&quot; with business at best. As IT infrastructure has commoditized at operational levels and the business environment has become increasingly complex, however, the focus of IT has shifted to more strategic considerations: effective enablement of business change and renewal resilience in the face of incessant transformations.
        <![CDATA[<p>The evolving relationship between business and IT is depicted in Table 1. Herein below, I will discuss each type of business-IT relationship in more detail: IT Alignment, IT Enablement, and Business-IT Confluence.
</p>
<p><strong>Table 1. The evolving relationship between business and IT.</strong></p>
<table border="1">
<th><td><strong>Alignment with Business</strong></td><td><strong>Enablement of Business</strong></td><td><strong>Confluence with Business</strong></td></th>
<tr><td><strong>IT Focus</strong></td><td>Reliability</td><td>Validity</td><td>Resilience</td></tr>
<tr><td><strong>Value Creation Leverage</strong></td><td>Value realization</td><td>Value engineering</td><td>Value innovation</td></tr>
<tr><td><strong>Time Orientation</strong></td><td>Present</td><td>Near future</td><td>Far future</td></tr>
<tr><td><strong>Governance Characteristics</strong></td><td>Internal control and risk management</td><td>Distributed, competence-based</td><td>Network governance</td></tr>
</table>
<br>
<br>
<h3>IT Alignment</h3>
<p>
The notion of business-IT alignment actually exacerbates the business-IT divide, by sharpening the distinction between the two. IT is seen as a separate, value-adding function, relegated to a subordinate role that needs to be aligned with business. Such languaging implies support rather than unity; as if IT is asking for a permission to be on the board -- or at least on board.
</p><p>
When IT is "aligned" with business, IT function is seen as a mere service and cost center. The emphasis is on present-day value realization: only IT projects that are "aligned" with the current enterprise strategy are approved, financed and prioritized. IT may satisfy all the idiosyncratic and sometimes conflicting business requirements, but does not accommodate any future contingencies. The traditional approach of "IT follows business" gives little consideration to strategic IT capabilities and systemic competencies needed to create new IT-driven business opportunities.
</p><p>
The focus of IT is on operational quality and reliability - producing predictable outcomes on a consistent basis. Consequently, human judgment and error is removed from work that is codified, digitized and automated through IT. Variance is eliminated through cascaded goals, metrics and controls that are ultimately passed down to the IT function in top-down, deterministic manner. This results in clearly separated, relatively independent sub-functions and sub-systems that have their own goals and ways of working. It is assumed to be enough to know how the constituents integrate with each other and work together. The internal logic of the components is considered irrelevant.
</p><p>
Respective governance arrangements focus on minimally required compliance, internal control and risk management.
</p>
<h3>IT Enablement</h3>
<p>
Whereas IT alignment is about supporting the current enterprise strategy "top-down", IT enablement means enabling the future enterprise strategies in a "bottom-up" fashion. IT is designed to enable (re-)engineering value and produce relevant outcomes with some trade-off for consistency; it balances the focus on reliability with focus on validity to create value, not only today, but also in the unfolding near future. The value of IT comes increasingly from how it is used rather than from the technology itself. Human judgment and discretion increase in importance.
</p><p>
IT enablement creates enterprise flexibility and capability to change. IT is effectively arranged in anticipation of changes, whose exact nature cannot be accurately predicted. Pertinently designed enterprise architecture is an essential means for enabling expeditious business redesign. Rather than tightly following the enterprise strategy, IT <a href="http://pespmc1.vub.ac.be/vicarsel.html">"vicariously selects"</a> components, competencies and capabilities likely to accommodate future contingencies. Service-Oriented Architecture is a case in point of an attempt to enable flexible reassembly of processes, capabilities and services in new, innovative ways.
</p><p>
IT enablement perspective calls for a distributed, competence-based view on governance, in which IT solutions are led by business, enabled by enterprise architecture and IT infrastructure.
</p>
<h3>Business-IT Confluence</h3>
<p>
Whereas IT enablement is about enabling enterprise effectiveness through a design-oriented approach, business-IT confluence transcends the mere equilibrial and adaptive stance and embraces resilience in the face of transformative, unpredictable change. The <a href="http://en.wikipedia.org/wiki/Wicked_problem">"wicked problems"</a> of today's interdependent and rapidly changing environments call for <a href="http://www.gartner.com/DisplayDocument?doc_cd=209217&ref=g_fromdoc">hybrid thinking</a> and confluence of business and IT.
</p><p>
Not only must enterprise architecture address the initial design and building of a robust system but also the successive designs and continual renewal of a resilient system. As business models are periodically reinvented in alignment with the continually shifting value proposition, the architecture must allow for major overhauls from a balance state to a reorganized new balance. Gartner has already coined the term <a href="http://www.gartner.com/DisplayDocument?doc_cd=209754">"panarchitecture"</a> for this emerging approach.
</p><p>
IT not only enables business change, but creates the very vital conditions for new, transformative business models. The upsurge in e-business, facilitated by the Internet, in the 1990s, for instance, represented a major disruption to incumbent businesses, as unconventional exchange mechanisms and transaction architectures suddenly enabled entirely new ways to innovate, create and deliver value. Business increasingly follows IT, not the other way around.
</p><p>
Business-IT confluence perspective requires network governance that relies on shared goals and values in coordinating highly interdependent work.
</p>]]>
    </content>
</entry>

<entry>
    <title>Maturity Begets Agility</title>
    <link rel="alternate" type="text/html" href="http://www.ebizq.net/blogs/agile_enterprise/2011/01/maturity-begets-agility.php" />
    <id>tag:www.ebizq.net,2011:/blogs/agile_enterprise//77.18809</id>

    <published>2011-01-25T17:26:01Z</published>
    <updated>2011-01-25T17:26:52Z</updated>

    <summary>Counterintuitive it may seem, agility does not come with an abandonment of rules, but actually requires more organizational discipline. Mature organizations do things systematically, while immature organizations achieve their outcomes as a result of the heroic efforts of individuals (Harmon,...</summary>
    <author>
        <name>Janne J. Korhonen</name>
        <uri>http://www.ebizq.net/MT4/mt-cp.cgi?__mode=view&amp;blog_id=77&amp;id=235</uri>
    </author>
    
        <category term="SOA" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="Service-Oriented Architecture" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="agility" label="agility" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="architecture" label="architecture" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="businessprocessmanagement" label="business process management" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="maturity" label="maturity" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="maturitymodel" label="maturity model" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="serviceorientedarchitecture" label="service-oriented architecture" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en-us" xml:base="http://www.ebizq.net/blogs/agile_enterprise/">
        Counterintuitive it may seem, agility does not come with an abandonment of rules, but actually requires more organizational discipline. Mature organizations do things systematically, while immature organizations achieve their outcomes as a result of the heroic efforts of individuals (Harmon, 2004). As illustrated in Figure 1, the agility of an organization co-evolves with its architectural maturity.
        <![CDATA[<span class="mt-enclosure mt-enclosure-image" style="display: inline;"><a href="http://www.ebizq.net/blogs/agile_enterprise/assets_c/2011/01/arch_maturity.php" onclick="window.open('http://www.ebizq.net/blogs/agile_enterprise/assets_c/2011/01/arch_maturity.php','popup','width=1437,height=844,scrollbars=no,resizable=no,toolbar=no,directories=no,location=no,menubar=no,status=no,left=0,top=0'); return false"><img src="http://www.ebizq.net/blogs/agile_enterprise/assets_c/2011/01/arch_maturity-thumb-500x293.jpg" width="500" height="293" alt="arch_maturity.jpg" class="mt-image-none" style="" /></a></span><br>
<b>Figure 1. Architectural maturity begets enterprise agility.</b>
<p>
In my <a href="http://www.ebizq.net/blogs/agile_enterprise/2010/12/soa-not.php">previous blog post</a>, I discussed how organizations face the need to co-develop both their organizational and technological capabilities to varying degrees. Of course, it is not that an organization is either agile or not, or that architectural maturity is either the most advanced or nonexistent. There are several shades of gray in between.
</p>
<p>
A common approach to assess and develop a specific capability in an organization is to devise a respective maturity model that provides an evaluative and comparative basis for improvement (Rosemann et al., 2006). The common base for the majority of maturity models is the <a href="http://en.wikipedia.org/wiki/Capability_Maturity_Model">Capability Maturity Model (CMM)</a> framework (SEI, 1995) by the Software Engineering Institute (SEI) of Carnegie Mellon University (CMU). CMM defines five levels of maturity with '5' representing the highest level. Higher degrees of maturity are likely to lead to higher agility, but as each organization has an ideal level of maturity, higher does not necessarily mean "better" (OSIMM, 2009).
</p>
<p>
In the following, I will subscribe to the five-scale ordination of maturity and outline a view of architectural maturity levels with regard to <a href="http://en.wikipedia.org/wiki/Service-oriented_architecture">Service-Oriented Architecture (SOA)</a> and <a href="http://en.wikipedia.org/wiki/Business_process_management">Business Process Management (BPM)</a>. Each maturity level builds cumulatively on the foundation of previous levels.
</p>
<h3>Level 1: Initial</h3>
<p>
The organization at this level is siloed. Each unit, be it functional, geographic or focused on a product, optimizes its own efficiency without end-to-end coordination of efforts across the organization (Fisher, 2004). There is no awareness of aligning business strategies, drivers and principles and IT strategies, drivers and principles (IFEAD, 2004).
</p>
<p>
The application landscape is largely unintegrated, consisting of "islands of automation" and "green screen" legacy. There is no integration of data, processes, standards, or technologies, and the IT systems cannot be integrated without significant manual intervention, such as re-keying and re-interpretation of data (OSIMM, 2009).
</p>
<p>
Business processes are performed in inconsistent, sometimes ad hoc ways with results that are difficult to predict. There is no explicit process or organizational support. (OMG, 2008). The processes are characterized by high levels of manual interventions and workarounds. Approaches to methodology, tools and techniques are various and not consolidated. (Rosemann et al., 2006).
</p>
<h3>Level 2: Managed</h3>
<p>
The organization is still built around functions and suffers from the lack of alignment around end-to-end, enterprise-wide processes. IT provides some level of cross-functional efficiency through data integration and process standards, but there is little or no enterprise-wide governance that provides the structure necessary for end-to-end alignment (Fisher, 2004).
</p>
<p>
The applications are integrated to support key business functions. EAI approach (Enterprise Application Integration) is adopted but with proprietary connections and integration points (Arsanjani and Holley, 2005). Thereby, integration does not extend to common standards in data or business processes (OSIMM, 2009).
</p>
<p>
The organization starts to recognize the importance of BPM and the executives and top management become increasingly involved. First business processes are documented and modeled and first attempts with a structured methodology and common standards are made. (Rosemann et al., 2006). The work can be performed in a repeatable way, yet work units performing similar tasks may use different procedures (OMG, 2008).
</p>
<h3>Level 3: Defined</h3>
<p>
Here, the organization undergoes an important mind-shift from functionally oriented to process driven. This step requires a top-down mandate: "enterprise-wide leadership and a supporting team that will be responsible for end-to-end process optimization, as well as the controls and governance needed to enforce the decisions of this leadership team" (Fisher, 2004).
</p>
<p>
The organization is implementing first Web services for SOA: low-level entity services "fine-grain" orchestrations over native endpoints to automate STP parts of its business processes. The IT systems have been analyzed and broken down into discrete and re-usable component parts, but these components are often replicated and redundant (OSIMM, 2009).
</p>
<p>
Business Process Management focuses on the management of the early phases of the process lifecycle employing a combination of different methods and tools (e.g. process re-design, workflow management, process-oriented EAI). Standard processes are synthesized from best practices identified in the work groups and provide an economy of scale and a foundation for learning from common measures and experience (OMG, 2008).
</p>
<h3>Level 4: Quantitatively Managed</h3>
<p>
The organization at this level has established its focus on processes, is committed to continuous improvement and utilizes business-focused metrics to increase its efficiency and effectiveness (Fisher, 2004).
</p>
<p>
The organization has started to adopt Service-Oriented Architecture, is SOA-enabling its application and integration legacy and is implementing new business functions as SOA services. Composite services are being orchestrated within a BPMS process implementation. The organization is using ESB and service registry as well as requisite security, logging and monitoring faculties for SOA. Through virtualization, the service is more closely coupled to the infrastructure (OSIMM, 2009).
</p>
<p>
Work processes are managed quantitatively to establish predictable results (OMG, 2008). The IT and business perspectives on process management are merged. Process orientation is a mandatory project component and process management initiatives are continuously extended and consolidated. There are formal, designated process management positions and the reliance on external expertise is minimal. (Rosemann et al., 2006).
</p>
<h3>Level 5: Optimizing</h3>
<p>
The organization extends its improved capabilities throughout the end-to-end value chain involving its partners that also adhere to the optimal characteristics (Fisher, 2004).
</p>
<p>
The organization has adopted a full-fledged SOA and extended the service management to the enterprise scale. It may employ service choreography on an end-to-end business process scale. The organization is using advanced BPM/SOA technologies such as BAM (Business Activity Monitoring), BRE (Business Rules Engine), WSM (Web Services Management), and CEP (Complex Event Processing). The assembly of business processes may be performed at runtime (OSIMM, 2009).
</p>
<p>
Process management becomes business as usual -- a part of managers' activities, accountabilities and performance measurements. Business process lifecycle management is established and there is one organization-wide approach to business process management that incorporates customers, suppliers, distributors and other stakeholders. (Rosemann et al., 2006). Both proactive and opportunistic improvement actions seek innovations that can close gaps between the organization's current capability and the capability required to achieve its business objectives (OMG, 2008).
</p>
<h3>References</h3>
<strong>Arsanjani, A. and K. Holley (2005). </strong><a href="http://www.ibm.com/developerworks/webservices/library/ws-soa-simm/">"Increase flexibility with the Service Integration Maturity Model (SIMM)"</a>. IBM developerWorks white paper.<br>
<strong>Fisher, D. M. (2004).</strong> <a href="http://www.bptrends.com/publicationfiles/10-04%20ART%20BP%20Maturity%20Model%20-%20Fisher.pdf">"The Business Process Maturity Model: A Practical Approach for Identifying Opportunities for Optimization"</a>. BP Trends. September 2004.<br> 
<strong>Harmon, P. (2004). </strong><a href="http://www.bptrends.com/publicationfiles/03-04%20NL%20Eval%20BP%20Maturity%20-%20Harmon.pdf">"Evaluating an Organization's Business Process Maturity"</a>. BP Trends. March 2004.<br>
<strong>IFEAD (2004). </strong><a href="http://www.enterprise-architecture.info/Images/E2AF/E2AMMv2.PDF">"Extended Enterprise Architecture Maturity Model"</a>. Version 2.0. Institute for Enterprise Architecture Developments<br>
<strong>OMG (2008). </strong><a href="http://www.omg.org/spec/BPMM/1.0/PDF">Business Process Maturity Model (BPMM), v. 1.0.</a><br>
<strong>OSIMM (2009). </strong>The Open Group Service Integration Maturity Model (OSIMM). Technical Standard. The Open Group.<br>
<strong>Rosemann, M., de Bruin, T. and B. Power (2006). </strong>"A Model to Measure Business Process Management Maturity and Improve Performance". In: Jeston, J. & J. Nelis (2006): Business Process Management, Chapter 27. Butterworth-Heinemann.<br>
<strong>SEI (1995). </strong>The Capability Maturity Model: Guidelines for Improving the Software Process. Software Engineering Institute. Reading, MA: Addison-Wesley.
]]>
    </content>
</entry>

<entry>
    <title>SOA Not?</title>
    <link rel="alternate" type="text/html" href="http://www.ebizq.net/blogs/agile_enterprise/2010/12/soa-not.php" />
    <id>tag:www.ebizq.net,2010:/blogs/agile_enterprise//77.18698</id>

    <published>2010-12-07T00:15:28Z</published>
    <updated>2010-12-07T00:18:43Z</updated>

    <summary>Service-Oriented Architecture (SOA) is touted as a &quot;must have&quot;. Cherish it, or perish, says the IT analyst, as if SOA could be attributed some absolute normative value. However, SOA, as a technology, does not bring about business agility. In fact,...</summary>
    <author>
        <name>Janne J. Korhonen</name>
        <uri>http://www.ebizq.net/MT4/mt-cp.cgi?__mode=view&amp;blog_id=77&amp;id=235</uri>
    </author>
    
        <category term="Enterprise Engineering" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="IT Strategy" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="Service-Oriented Architecture" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="businessitalignment" label="business-IT alignment" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="enterpriseengineering" label="enterprise engineering" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="servicedominantlogic" label="service-dominant logic" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="serviceorientedarchitecture" label="service-oriented architecture" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en-us" xml:base="http://www.ebizq.net/blogs/agile_enterprise/">
        <![CDATA[<p>Service-Oriented Architecture (SOA) is touted as a "must have". Cherish it, or perish, says the IT analyst, as if SOA could be attributed some absolute normative value. However, SOA, as a technology, does not bring about business agility. In fact, deploying a SOA stack in an organization that is not agile to start with may be seriously misguided and downright detrimental. At worst, SOA does not disentangle the technology mess but only creates new nightmares at just higher level.</p>]]>
        <![CDATA[<p>In an <a href="http://www.ebizq.net/blogs/agile_enterprise/2010/02/paradigm-shift-in-it-implications-of-service-dominant-logic.php">earlier blog post</a>, I have discussed the implications of <a href="http://www.sdlogic.net/">Service-Dominant Logic</a> on IT. As the overall business perspective is shifting from the relatively stable, closed and controllable system of a self-sufficient enterprise to the relatively fluid, open and transformational system of networked co-adaptive entities, so is information technology moving from centralized, siloed, proprietary and monolithic enterprise information systems to peer-to-peer, service-oriented, standards-based and modular inter-enterprise composite applications.</p>

<p>However, different industries are embracing the new dominant logic to varying degrees. Not all markets are dynamic. Not all businesses need to be the most agile. Traditional business-IT alignment works reasonably well in relatively stable and predictable environments. As illustrated in Figure 1, the cost-benefit balance of IT investments within Goods-Dominant Logic favors traditional IT -- up-front investments in business technologies may be "technological overkill".</p>

<p>In complex, competitive and non-linear business environments, in contrast, new business technology is imperative; otherwise there will be "technological deficiency". A more encompassing approach to enterprise governance is called for -- one, in which business and IT converge. Change must be addressed from the constructional perspective that entails coherent and consistent design principles and holistically integrates various business and organizational aspects. SOA underlies this convergence and integration but necessitates an agile organization.<br />
 <br />
<span class="mt-enclosure mt-enclosure-image" style="display: inline;"><a href="http://www.ebizq.net/blogs/agile_enterprise/assets_c/2010/12/business-it.php" onclick="window.open('http://www.ebizq.net/blogs/agile_enterprise/assets_c/2010/12/business-it.php','popup','width=870,height=478,scrollbars=no,resizable=no,toolbar=no,directories=no,location=no,menubar=no,status=no,left=0,top=0'); return false"><img src="http://www.ebizq.net/blogs/agile_enterprise/assets_c/2010/12/business-it-thumb-500x274.jpg" width="500" height="274" alt="business-it.jpg" class="mt-image-none" style="" /></a></span><br />
<strong>Figure 1. Requisite alignment of business and technology.</strong></p>

<p>Neither technological overkill nor technological deficiency is desirable.</p>

<p>At any rate, the general trend is towards increasingly complex and competitive business environment across all industries. Even the organizations that can still afford to follow Goods-Dominant Logic must take deliberate steps to increase their <a href="http://en.wikipedia.org/wiki/Absorptive_capacity">"absorptive capacity"</a> by building higher-level organizational and IT capabilities in step with the increasing market dynamism, lest they be fallen to technological deficiency. Failure to increase the capacity requisitely is likely to lead to a self-reinforcing "lock-out" from further technology adoption.</p>

<p>As discussed in my <a href="http://www.ebizq.net/blogs/agile_enterprise/2010/11/what-is-your-service-strategy.php">previous blog post</a>, the focus of IT is shifting from mere information systems development to systemic competencies and more encompassing enterprise engineering. To fully harness the power of business technology, the entire organization ought to be recast according to the overarching service strategy that permeates its every facet.</p>

<p>Technological overkill may also give rise to misapplication of business technology. If the organization works from its traditional, functional stance, the technology tends to be applied according to the same outlook. A case in point is BPM (Business Process Management) that is said to be the "killer app" of SOA. However, BPM runs the risk of killing the agility that it purports to achieve. Only a fraction of processes are rigid enough to allow themselves to be "managed" through BPM. Most business processes are considerably varied from time to time and would require the very degrees of freedom that imperative BPM eliminates. In many cases, <a href="http://en.wikipedia.org/wiki/Informating">informating</a> rather than automating processes would increase agility.</p>

<p>IT infrastructure vendors want to sell you SOA, or if they cannot sell it, rename it and try again. However, SOA cannot be bought. It also cannot be built in a one-off development project. SOA pertains to a fundamentally new way of conducting business and calls for sustained organizational learning to adopt a new worldview altogether.</p>

<p>SOA not? Not if you are not ready. Think big, but start small. Create your service strategy and build the SOA roadmap that integrates business, organizational and technological aspects. Establish enterprise governance and align enterprise architecture therewith. Develop pertinent capabilities. Only then invest in technology to the requisite extent, avoiding the stalling with technological overkill as well as the foundering with technological deficiency.</p>]]>
    </content>
</entry>

<entry>
    <title>What is your service strategy?</title>
    <link rel="alternate" type="text/html" href="http://www.ebizq.net/blogs/agile_enterprise/2010/11/what-is-your-service-strategy.php" />
    <id>tag:www.ebizq.net,2010:/blogs/agile_enterprise//77.18642</id>

    <published>2010-11-10T18:27:15Z</published>
    <updated>2010-11-10T18:27:28Z</updated>

    <summary>With the frantic pace of business today, value propositions and respective business models are in constant flux. The organizations need to reconfigure their resources dynamically and integrate them with complementary resources of their ecosystem. The strategic focus is back on...</summary>
    <author>
        <name>Janne J. Korhonen</name>
        <uri>http://www.ebizq.net/MT4/mt-cp.cgi?__mode=view&amp;blog_id=77&amp;id=235</uri>
    </author>
    
        <category term="Enterprise IT" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="Service-Oriented Architecture" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="servicestrategy" label="service strategy" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="serviceorientedarchitecture" label="service-oriented architecture" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en-us" xml:base="http://www.ebizq.net/blogs/agile_enterprise/">
        <![CDATA[<p>With the frantic pace of business today, value propositions and respective business models are in constant flux. The organizations need to reconfigure their resources dynamically and integrate them with complementary resources of their ecosystem. The strategic focus is back on internal competencies of an enterprise, while heeding the relative position vis-à-vis competitive and collaborative forces.</p>]]>
        <![CDATA[<p>In this setting, services are the means for providing value to customers and fundamental to economic exchange. What separates a strategic service provider from a commodity supplier is the focus on successful customer outcomes. The key is to sense what differentiates the offered value from the alternatives perceived by the customer and act on the opportunities by reconfiguring the enterprise's assets accordingly.</p>

<p>IT has traditionally focused on developing information systems to support business goals. The emphasis has been on <em>reliability</em>: producing predictable outcomes on a consistent basis. This has worked adequately well in a relatively stable environment, but in the face of increasing engagement, collaboration and value co-creation with the customers, IT needs to achieve more <em>validity</em>: producing relevant outcomes at the cost of consistency. Accordingly, the focus of IT needs to shift from planning and deploying idiosyncratic information systems to developing discretionary measures and systemic competencies that effectively address the changing requirements.</p>

<p>Optimally, Service-Oriented Architecture (SOA) is about re-architecting the entire organization, its engineering and governance, including the IT aspect-system, around business services. More often than not, however, SOA undertakings are lacking a systemic view, strategic perspective and necessary governance considerations. They start sporadically across various projects and often only add to the existing complexity, rather than help disentangling it.</p>

<p>Who are your customers? What are their most important and enduring needs? What would be of lasting business value for them? What services should you provide to them? What differentiates you from the competition? How would you exceed your customers' expectations? Do you have requisite existing and potential service resources and capabilities? What assets are owned and what activities conducted in-house? What is bought or rented from the open market?</p>

<p>In short: What is your service strategy?</p>

<p><em>These </em>are the questions that should drive SOA.<br />
</p>]]>
    </content>
</entry>

<entry>
    <title>Get the Decision-Making Right</title>
    <link rel="alternate" type="text/html" href="http://www.ebizq.net/blogs/agile_enterprise/2010/10/get-the-decision-making-right.php" />
    <id>tag:www.ebizq.net,2010:/blogs/agile_enterprise//77.18527</id>

    <published>2010-10-03T09:38:35Z</published>
    <updated>2010-10-03T09:40:16Z</updated>

    <summary>I came across and found great resonance with the June 2010 Harvard Business Review article titled &quot;The Decision-Driven Organization&quot;, authored by Marcia W. Blenko, Michael C. Mankins and Paul Rogers. Based on a recent Bain &amp; Co. study of reorganizations,...</summary>
    <author>
        <name>Janne J. Korhonen</name>
        <uri>http://www.ebizq.net/MT4/mt-cp.cgi?__mode=view&amp;blog_id=77&amp;id=235</uri>
    </author>
    
        <category term="Organizational Development" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="decisionmaking" label="decision-making" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="reorganization" label="reorganization" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="restructuring" label="restructuring" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en-us" xml:base="http://www.ebizq.net/blogs/agile_enterprise/">
        <![CDATA[<p>I came across and found great resonance with the June 2010 Harvard Business Review article titled <a href="http://hbr.org/2010/06/the-decision-driven-organization/ar/1">"The Decision-Driven Organization"</a>, authored by Marcia W. Blenko, Michael C. Mankins and Paul Rogers. Based on a recent Bain & Co. study of reorganizations, they maintain that, contrary to popular belief, structural changes, per se, will not lead to better performance.</p>]]>
        <![CDATA[<p>What drives performance instead is the effectiveness of making and executing critical decisions. Sometimes improving decision effectiveness may entail and justify structural changes, but exclusively structural interventions that lack attention to the organization's decision-making ability can actually deteriorate performance.</p>

<p>The authors advise to reorganize around decisions through six steps:</p>

<p> 1.  Identify your organization's key decisions.<br />
 2.  Determine where in the organization those decisions should happen.<br />
 3.  Organize a macrostructure around sources of value.<br />
 4.  Figure out what level of authority decision makers need.<br />
 5.  Align other elements of the organizational system with those related to decision-making.<br />
 6.  Develop skills and behaviors necessary to make and execute decisions quickly and well.</p>

<p>They also argue for organization overlays such as councils and boards that facilitate collaboration, accelerate decision-making, and reduce the number of "decision nodes" -- the interfaces between regions, functions and layers required to make and execute important decisions.</p>

<p>These ideas appear to be in perfect line with the notions of <a href="http://www.ebizq.net/blogs/agile_enterprise/2010/05/stratification-underlies-agility-preface.php">Requisite Organization</a> and <a href="http://www.ebizq.net/blogs/agile_enterprise/2010/09/the-future-of-governance-is-circular.php">circular governance</a>, discussed in my earlier posts.<br />
</p>]]>
    </content>
</entry>

</feed>

