<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Enterra CTO on Ruleset Automation</title>
	<atom:link href="http://www.tdaxp.com/archive/2006/08/08/enterra-cto-on-ruleset-automation.html/feed" rel="self" type="application/rss+xml" />
	<link>http://www.tdaxp.com/archive/2006/08/08/enterra-cto-on-ruleset-automation.html</link>
	<description>High-minded, fanatically malthusian perspectives</description>
	<lastBuildDate>Thu, 09 Feb 2012 19:18:06 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Mike </title>
		<link>http://www.tdaxp.com/archive/2006/08/08/enterra-cto-on-ruleset-automation.html/comment-page-1#comment-14626</link>
		<dc:creator>Mike </dc:creator>
		<pubDate>Wed, 30 Nov -0001 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.tdaxp.com/archive/2006/08/08/enterra-cto-on-ruleset-automation.html#comment-14626</guid>
		<description> &lt;p&gt;Sonny,&lt;br /&gt; &lt;br /&gt; Thanks for that great explanation and analysis!  I agree with you about unity of command not being something new.  I merely pointed out that Schwerpunkt was Boyd&#039;s example of the principle.&lt;br /&gt; &lt;br /&gt; Your point about the dangers of technology-enabled micromanagement was a good one, both in military and business terms.  They&#039;re better used for improved monitoring and appreciation (in Boyd&#039;s terms).&lt;br /&gt; &lt;br /&gt; Isn&#039;t part 4 of your defense of EBO overdue at FX-Based?&lt;br /&gt; &lt;br /&gt; Cheers,&lt;br /&gt; &lt;br /&gt; Mike&lt;/p&gt; </description>
		<content:encoded><![CDATA[<p>Sonny,</p>
<p> Thanks for that great explanation and analysis!  I agree with you about unity of command not being something new.  I merely pointed out that Schwerpunkt was Boyd&#39;s example of the principle.</p>
<p> Your point about the dangers of technology-enabled micromanagement was a good one, both in military and business terms.  They&#39;re better used for improved monitoring and appreciation (in Boyd&#39;s terms).</p>
<p> Isn&#39;t part 4 of your defense of EBO overdue at FX-Based?</p>
<p> Cheers,</p>
<p> Mike</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan tdaxp </title>
		<link>http://www.tdaxp.com/archive/2006/08/08/enterra-cto-on-ruleset-automation.html/comment-page-1#comment-14627</link>
		<dc:creator>Dan tdaxp </dc:creator>
		<pubDate>Wed, 30 Nov -0001 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.tdaxp.com/archive/2006/08/08/enterra-cto-on-ruleset-automation.html#comment-14627</guid>
		<description> &lt;p&gt;Mike, &lt;br /&gt; &lt;br /&gt; I am looking forward to your book!&lt;br /&gt; &lt;br /&gt; Sonny,&lt;br /&gt; &lt;br /&gt; Mike&#039;s right -- get cracking on part four! :-)&lt;/p&gt; </description>
		<content:encoded><![CDATA[<p>Mike, </p>
<p> I am looking forward to your book!</p>
<p> Sonny,</p>
<p> Mike&#39;s right &#8212; get cracking on part four! <img src='http://www.tdaxp.com/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike </title>
		<link>http://www.tdaxp.com/archive/2006/08/08/enterra-cto-on-ruleset-automation.html/comment-page-1#comment-14622</link>
		<dc:creator>Mike </dc:creator>
		<pubDate>Wed, 30 Nov -0001 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.tdaxp.com/archive/2006/08/08/enterra-cto-on-ruleset-automation.html#comment-14622</guid>
		<description> &lt;p&gt;Dan,&lt;br /&gt; &lt;br /&gt; BPEL is nice, but certainly nothing revolutionary.  Having built workflow applications since the early 90&#039;s, I&#039;ve seen the &#039;New Bank Account Opening&#039; process automated several times.  For some reason that seems to be every vendor&#039;s favorite example.&lt;br /&gt; &lt;br /&gt; In most workflow applications the technology has always been the easy part of the project, particularly with complex processes. [ Complex, not complicated, as in:  Designing the control system for a modern aircraft - complicated; flying that plane from LA to NY on any given day - complex ]  You know from systems theory that the control system for any process is by necessity more sophiticated than the system itself, and most organizations don&#039;t want to go to the trouble of analyzing and designing such a system.  It&#039;s easier to insert people as the control systems, since they&#039;re very adaptable and self-programming (OODA!).&lt;br /&gt; &lt;br /&gt; That decision leads to an exponential escalation in overall system control complexity, since the new control mechanism has to be more sophisticated than the brains of all of our human control points!  I think that this was the fundamental flaw of Hammer and Champy&#039;s original Reengineering model.  They tried to make complex systems into complicated ones, expecting people not to act in complex ways (which turned out to be a fatal assumption in most Reengineering projects, by Hammer&#039;s own admission).&lt;br /&gt; &lt;br /&gt; Workflow automation requires making rulesets explicit in order to be automatable/controllable.  Boyd said that explicit rulesets severely limit the adaptability of the system under control of the ruleset, which is a weakness in competition of all sorts.  Paradoxically, this is a benefit in high-volume transactional processes, such as new bank account opening, where regulatory restrictions and auditability are paramount.  Most of those applications have already been automated using previous generations  of technology.  BPEL is just an evolutionary extension of that technology.  Nice, but a very secondary factor in the success of workflow applications.&lt;/p&gt; </description>
		<content:encoded><![CDATA[<p>Dan,</p>
<p> BPEL is nice, but certainly nothing revolutionary.  Having built workflow applications since the early 90&#39;s, I&#39;ve seen the &#39;New Bank Account Opening&#39; process automated several times.  For some reason that seems to be every vendor&#39;s favorite example.</p>
<p> In most workflow applications the technology has always been the easy part of the project, particularly with complex processes. [ Complex, not complicated, as in:  Designing the control system for a modern aircraft - complicated; flying that plane from LA to NY on any given day - complex ]  You know from systems theory that the control system for any process is by necessity more sophiticated than the system itself, and most organizations don&#39;t want to go to the trouble of analyzing and designing such a system.  It&#39;s easier to insert people as the control systems, since they&#39;re very adaptable and self-programming (OODA!).</p>
<p> That decision leads to an exponential escalation in overall system control complexity, since the new control mechanism has to be more sophisticated than the brains of all of our human control points!  I think that this was the fundamental flaw of Hammer and Champy&#39;s original Reengineering model.  They tried to make complex systems into complicated ones, expecting people not to act in complex ways (which turned out to be a fatal assumption in most Reengineering projects, by Hammer&#39;s own admission).</p>
<p> Workflow automation requires making rulesets explicit in order to be automatable/controllable.  Boyd said that explicit rulesets severely limit the adaptability of the system under control of the ruleset, which is a weakness in competition of all sorts.  Paradoxically, this is a benefit in high-volume transactional processes, such as new bank account opening, where regulatory restrictions and auditability are paramount.  Most of those applications have already been automated using previous generations  of technology.  BPEL is just an evolutionary extension of that technology.  Nice, but a very secondary factor in the success of workflow applications.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan tdaxp </title>
		<link>http://www.tdaxp.com/archive/2006/08/08/enterra-cto-on-ruleset-automation.html/comment-page-1#comment-14623</link>
		<dc:creator>Dan tdaxp </dc:creator>
		<pubDate>Wed, 30 Nov -0001 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.tdaxp.com/archive/2006/08/08/enterra-cto-on-ruleset-automation.html#comment-14623</guid>
		<description> &lt;p&gt;Mike,&lt;br /&gt; &lt;br /&gt; I agree. I like your line &quot;They tried to make complex systems into complicated ones, expecting people not to act in complex ways.&quot;  I made similar comments in my post, &quot;Dashboard Confessional.&quot;&lt;br /&gt; &lt;br /&gt; What is your view of Sonny&#039;s comment on that post,&lt;br /&gt; &lt;br /&gt; &#039;&quot;Centralized control, decentralized execution&quot;. A basic doctrinal tenet of the USAF, that can - to some degree - be applied to other non-military enterprises, particularly those that deal with crisis situations like terrorist attacks, natural disasters, or reconstruction in a chaotic, hostile, or non-favorable environment. ... &#039;&lt;br /&gt; &lt;br /&gt; ?&lt;br /&gt; &lt;br /&gt; &lt;a href=&quot;http://www.tdaxp.com/archive/2006/06/14/dashboard-confessional.html&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;http://www.tdaxp.com/archive/2006/06/14/dashboard-confessional.html&lt;/a&gt;&lt;/p&gt; </description>
		<content:encoded><![CDATA[<p>Mike,</p>
<p> I agree. I like your line &#8220;They tried to make complex systems into complicated ones, expecting people not to act in complex ways.&#8221;  I made similar comments in my post, &#8220;Dashboard Confessional.&#8221;</p>
<p> What is your view of Sonny&#39;s comment on that post,</p>
<p> &#39;&#8221;Centralized control, decentralized execution&#8221;. A basic doctrinal tenet of the USAF, that can &#8211; to some degree &#8211; be applied to other non-military enterprises, particularly those that deal with crisis situations like terrorist attacks, natural disasters, or reconstruction in a chaotic, hostile, or non-favorable environment. &#8230; &#39;</p>
<p> ?</p>
<p> <a href="http://www.tdaxp.com/archive/2006/06/14/dashboard-confessional.html" target="_blank" rel="nofollow">http://www.tdaxp.com/archive/2006/06/14/dashboard-confessional.html</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike </title>
		<link>http://www.tdaxp.com/archive/2006/08/08/enterra-cto-on-ruleset-automation.html/comment-page-1#comment-14624</link>
		<dc:creator>Mike </dc:creator>
		<pubDate>Wed, 30 Nov -0001 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.tdaxp.com/archive/2006/08/08/enterra-cto-on-ruleset-automation.html#comment-14624</guid>
		<description> &lt;p&gt;Dan,&lt;br /&gt; &lt;br /&gt; I came back to see if you responded to my comment, and there are 75 new posts.  You are one prolific dude!&lt;br /&gt; &lt;br /&gt; It&#039;s funny you ask about crisis situations.  Mark Brady of Fouroboros and I are writing a book titled &quot;Moonshots and Tsunamis&quot;, and have done a fair amount of thinking about management theories.  Having decided to live my life using complex/complicated as a central model, and having said that John Boyd is THE authority on management of the complex, I have to go back to &quot;Patterns of Conflict&quot; to attribute my thinking.&lt;br /&gt; &lt;br /&gt; I think that Boyd would consider Curtis&#039; remarks to refer to the Schwerpunkt model of warfare, in which Central Command defined the overall mission and then gave subordinates the authority AND RESPONSIBILITY to successfully carry out the mission in whatever way they saw fit.  Central Command then evaluates results and changes mission objectives based on new information, but continues to delegate action to subordinates.&lt;br /&gt; &lt;br /&gt; As long as &quot;central control&quot; allows smaller unit initiative, things will work.  But the human tendancy for micromanagement in a crisis must be actively managed.&lt;br /&gt; &lt;br /&gt; Mike&lt;/p&gt; </description>
		<content:encoded><![CDATA[<p>Dan,</p>
<p> I came back to see if you responded to my comment, and there are 75 new posts.  You are one prolific dude!</p>
<p> It&#39;s funny you ask about crisis situations.  Mark Brady of Fouroboros and I are writing a book titled &#8220;Moonshots and Tsunamis&#8221;, and have done a fair amount of thinking about management theories.  Having decided to live my life using complex/complicated as a central model, and having said that John Boyd is THE authority on management of the complex, I have to go back to &#8220;Patterns of Conflict&#8221; to attribute my thinking.</p>
<p> I think that Boyd would consider Curtis&#39; remarks to refer to the Schwerpunkt model of warfare, in which Central Command defined the overall mission and then gave subordinates the authority AND RESPONSIBILITY to successfully carry out the mission in whatever way they saw fit.  Central Command then evaluates results and changes mission objectives based on new information, but continues to delegate action to subordinates.</p>
<p> As long as &#8220;central control&#8221; allows smaller unit initiative, things will work.  But the human tendancy for micromanagement in a crisis must be actively managed.</p>
<p> Mike</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sonny </title>
		<link>http://www.tdaxp.com/archive/2006/08/08/enterra-cto-on-ruleset-automation.html/comment-page-1#comment-14625</link>
		<dc:creator>Sonny </dc:creator>
		<pubDate>Wed, 30 Nov -0001 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.tdaxp.com/archive/2006/08/08/enterra-cto-on-ruleset-automation.html#comment-14625</guid>
		<description> &lt;p&gt;Mike, Dan,&lt;br /&gt; &lt;br /&gt; Air Force wise&quot; centralized command, decentralized execution&quot; is pretty much how we operate 24/7 (with very rare exceptions). And we&#039;ve been running combat ops continuosly 24/7 since 1991. This tenet, of course is not &quot;black and white&quot; meaning, there is always some flexibility built into it. Subordinates units have to operate under rules of engagement (ROE), law of armed conflict (LOAC) and other restrictions meaning that they are just not allowed (for good reason) to do whatever they please once they enter the battlespace or operational area. Of course, self-defense (and some targets of opportunity, etc) are taken into account when formulating and implementing these restrictions. Even within the centralized command, decentralized execution framework there is considerable flexibility. Different operations require different levels of attention and restrictions from the command entity. For example, an operation in an urban environment is bound to have more restrictions attached to it than one conducted in a spaserly populated area. &lt;br /&gt; &lt;br /&gt; Mike&#039;s remarks are spot on. The only thing I would add is that whenever I think of &quot;Central Command&quot; I think of the specific US Combatant Command that handles operations in the Middle East and the Horn or Africa. &quot;Command entity&quot; is probably less confusing, but that&#039;s just my quibbly preference.  &lt;br /&gt; &lt;br /&gt; Micromanagement is part of the danger (especially with all our &quot;collaboration tools&quot; and C4ISR systems), but&#039;s that&#039;s why we stress leadership over mere management. Part of being a leader requires that you trust your subordinates to do their job. This is particularly important in contigency situations. In my experience, a hazy command structure is never an advantage when it comes to a contigency. Unity of command is actually a principle that predates Blitzkrieg doctrine by thousands of years. The Greeks and the Romans operated under this pronciple. Napoleon reffered to it as &quot;the first necessity in war&quot;. &lt;br /&gt; &lt;br /&gt; Regarding the technology aspects and the snazzy tools, to run a successful operation, you need to realize that no matter how good the technology, people-to-people relations is how you get things done as a leader.&lt;/p&gt; </description>
		<content:encoded><![CDATA[<p>Mike, Dan,</p>
<p> Air Force wise&#8221; centralized command, decentralized execution&#8221; is pretty much how we operate 24/7 (with very rare exceptions). And we&#39;ve been running combat ops continuosly 24/7 since 1991. This tenet, of course is not &#8220;black and white&#8221; meaning, there is always some flexibility built into it. Subordinates units have to operate under rules of engagement (ROE), law of armed conflict (LOAC) and other restrictions meaning that they are just not allowed (for good reason) to do whatever they please once they enter the battlespace or operational area. Of course, self-defense (and some targets of opportunity, etc) are taken into account when formulating and implementing these restrictions. Even within the centralized command, decentralized execution framework there is considerable flexibility. Different operations require different levels of attention and restrictions from the command entity. For example, an operation in an urban environment is bound to have more restrictions attached to it than one conducted in a spaserly populated area. </p>
<p> Mike&#39;s remarks are spot on. The only thing I would add is that whenever I think of &#8220;Central Command&#8221; I think of the specific US Combatant Command that handles operations in the Middle East and the Horn or Africa. &#8220;Command entity&#8221; is probably less confusing, but that&#39;s just my quibbly preference.  </p>
<p> Micromanagement is part of the danger (especially with all our &#8220;collaboration tools&#8221; and C4ISR systems), but&#39;s that&#39;s why we stress leadership over mere management. Part of being a leader requires that you trust your subordinates to do their job. This is particularly important in contigency situations. In my experience, a hazy command structure is never an advantage when it comes to a contigency. Unity of command is actually a principle that predates Blitzkrieg doctrine by thousands of years. The Greeks and the Romans operated under this pronciple. Napoleon reffered to it as &#8220;the first necessity in war&#8221;. </p>
<p> Regarding the technology aspects and the snazzy tools, to run a successful operation, you need to realize that no matter how good the technology, people-to-people relations is how you get things done as a leader.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

