Tuesday, October 11, 2011
'Corporate-Subweb' Paradigm
Post Classification ---------------------------------------
Section CORPORATE / Category WHAT TO AVOID
Section GOVERNANCE / Category WHAT TO DO
Section TECHNOLOGY / Category WHAT TO KNOW
--------------------------------------------------------
Preliminary Remark
With the 'Floating-Enterprise' paradigm, we have - at the corporate (strategic) level - a novel, extremely powerful framework for Business Development, whose validity will remain intact permanently, due to its deep-rooted foundation.
To render this paradigm operational at the governance (organizational) level, we can rely on the 'Corporate-Collaboration-Market' paradigm, as an equally powerful framework for Organizational Development, in particular improvement of collaboration management.
Finally, to render the 'Corporate-Collaboration-Market' paradigm operational at the technological (systems) level, we can build on a third exceptionally robust framework for System Development, particularly for conceptual improvement of IT, to settle the persistent problem of Business-IT mis-alignment, at long last.
You may want to get the definitions of the Floating-Enterprise Paradigm and the Corporate-Collaboration-Market Paradigm from the related Posts in my Corporate and Governance Blog, respectively.
1. Business-IT Relationship - A Technology-Transfer Problem
IT is not properly aligned to the Business, since directed to a wrong target, which, in fact, does not exist at all, but – according to strategy propagated by IT – must be created, by a major organizational change in collaboration management, in order for computing technology to be applicable.
The target, IT-people recommend to address, is what they call 'Business Processes'. The organizational change, claimed to be conditional for computing-technology transfer, is transformation of (current kinds of) Collaboration Management into what IT-technologists call 'Business Process Management'.
The truth is: IT did not manage, to understand the pre-requisite for computing-technology application, nor to find out, where this pre-requisite is found in Collaboration management.
2. Proper Computing-Technology Transfer to Collaboration
Management
The pre-requisite for any computing-technology application is that there is already some automatism. Since computing technology can only be used to automate the handling of automata by individuals. The target for computing-technology application can only be the human interface of some automatism.
The big problem is to identify such an interface in Collaboration Management. Only after it is found, computing-technology can be applied to Collaboration Management. This problem is solved with the Corporate-Collaboration-Market Paradigm:
- The automatism we are searching for is the primordial
Collaboration Market, in its two appearances: public and
corporate. The primordial Market is nothing but automated mutuality.
(The core problem with IT is that the 'Business Processes',
IT intents to automate, by means of computing technology,
are not automats, thus don't provide the control interface,
needed for the application of computing technology.)
- The interface for computing-technology application, in turn, is the
point, where individuals access this market; (a) as Market Makers,
and (b) as Market Participants. Again, there are two kinds of
Market-Makers and corresponding Market-Participants: public and
corporate.
3. Identifying the Transfer Interface
Thus, for transferring computing-technology porperly to the enterprise, it's necessary to go back to the Market in its primordial meaning, as automatism, in fact, as automated mutuality or sociality.
In so doing, we realize that Market Making by individual humans and Market Participation of individual humans indicate the two-fold interface, through which we are accessing the Market automatism (which, itself is not human made).
Handling this two-fold interface is what can be (partially) automated by computing technology, in the domain of Collaboration Management. The result of this tranfer of computing-technology to Collaboration Management is computer-aided Market Making and Market-Participation.
4. Understanding the Public Web
Surprisingly, we find, that in the public domain computing-technology has long been properly applied to Collaboration Management:
The public appearance of computer-aided Market Making and Market-Participation is the Public Web, where it is used for Googling: Google is the Market Maker of a global collaboration market, through which everyone can freely offer and request information.
Thus, in the public domain we have a very successful implementation of a computer-aided mutuality-automatism. Googling is the respective paradigm. In the corporate domain, a corresponding implementation is still missing – due to the failure of IT.
5. Conceiving the Corporate Subweb
The COROPORATE SUBWEB PARADIGM is providing guidelines, how to achieve a computer-aided mutuality-automatism, i.e., a computer-aided Corporate Collaboration Market for the enterprise.
The idea of this paradigm is simple: Just take the Public Web, with its request-response philosophy (REST- architecture), and account for corporate governance by imposing additional restrictive rules, to govern details of access and request-response behaviour in the Corporate Subweb .
What you get, is a Corporate Subweb, freely floating in the Public Web, as a stronger regulated computer-aided island in the weaker regulated strongly global Collaboration Market.
Summary
All three paradigms refer to the primordial Market:
FLOATING ENTERPRISE PARADIGM
referring to the enterprise, as corporate (more strongly regulated) subdivision of the global (more weakly regulated) Market, in its primordial meaning as a Collaboration Market
CORPORATE COLLABORATION MARKET
referring to HR-Management (Organization), as corporate subdivision of the non-institutionalized public collaboration, in its primordial meaning as concrete implementation of the primordial (Collaboration) Market
CORPORATE SUBWEB
referring to IT, as corporate subdivision of the public, global Web, in its primordial meaning as computer-assistance for the implementation of the primordial (Collaboration) Market
Therefore, if all three kinds of officers involved,
- Enterprise Developer
CEO as Maker of corporate division of Collaboration Market,
- Organization Developer
COO as Operator of corporate division of Collaboration Market,
- System Developer
CIO as Operations Supporter of corporate Collaboration Market
adhere to their respective paradigm, corporate coherence, including Business/'IT' alignment, will emerge, definitely.
Turn to the special-interest group 'Art-Invest-Open / Corporate Subweb' at LinkedIn, to follow or enter discussion.
Go to Art-Invest Website
Tuesday, August 16, 2011
In what respect the Workflow Way is a Blind Alley
REPLY TO DAVID CHAPPELL
(David Chappell & Associates)
Post Classification ---------------------------------------
Section CORPORATE / Category WHAT TO AVOID
Section GOVERNANCE / Category WHAT TO DO
Section TECHNOLOGY / Category WHAT TO KNOW
--------------------------------------------------------
I am commenting on a whitepaper by David Chappell, who explains the philosophy of Microsoft's latest version of Windows Workflow Foundation (www.davidchappell.com > Writing > White Papers > Windows Workflow Foundation > The Workflow Way: Understanding Windows Workflow Foundation), since this is a good example, how even experienced and carefully arguing technologists are stumbling over the threshold between technology and organization - across the border separating the strata of technology and organization, T- and O-stratum, respectivly.
TECHNOLOGY IS NOT SUFFICIENT
Why should we be concerned? Because, not handling properly the interplay of these two strata is at the root of the mis-alignment of IT to busisness – according to my opinion. In fact, IT and business are living in two fundamentally different, though inseparably connected strata, the T- and O-stratum, respectively. Thus, in order to achieve a seamless interaction of IT and business, we have to make sure that either respects the specific regularities of the other's stratum.
In particular, if computing technology is developing to Web-technology and, as such, is transgressing role and departmental scope to become operative in overall business (striving at so-called end-to-end applications, under the EAI/BPM/SOA-regime), technology is taken beyond the limits of T-stratum into O-stratum, and it is – therefore – exceedigly important to ensure that the basic rules governing the O-stratum are accounted for.
VOLITION UTTERANCE - VOLITION EXECUTION
Typically, software technologists, even if aware of the T/O-border's existence, do not pay proper attention to it, when designing programs and writing code. This might be due to a lack of knowledge, of how the T/O-border is appearing in code. To get control of this issue, think of programs – of their code – as manifestations of human volition utterance. Think of developers as trying hard to keep hold of humans' volition utterance, by casting it in a proper code-construct. Typically, volition-utterance is de-composed into elementary volition-acts, which in turn are re-composed by means of so-called application logic to match the original utterance.
After the elementary volition acts have been 'coded', and the application logic, assembling the corresponding code parts, has been stated in terms of straight-forward control-flow components, we are on the safe territory of T-stratum – and need not care about whatever 'deviant' features of the O-stratum. This is true, as long as we limit our attention in software manufacturing to human volition utterance, which - however - is only part of the overall volition reification, required as a pre-condition for automation by means of computing technology.
Obviously, volition reification consist of two parts: (a) volition utterance, and (b) volition execution. Now, ordinary program code can capture volition expression only, never volition execution. You may write as many sophisticated programs as you like, nothing at all will happen, as long as you do not start processors, capable of executing your programs, thus making volition execution, in itself, happen.
From this reasoning, a caveat derives: To capture volition reification properly, i.e., completely, including utterance and execution, always consider 'program & processor' as an inseparable complex. (In fact, neither a program without a processor, nor a processor without a program will make volition automation happen as a real-world event.)
THREADING
Thus, a software product, to be fully operative, cannot be restricted to program-code, it must include processor-design, as well. Of course, I am not speaking of the processor as a piece of hardware, but as a topic relevant for software development. From this point of view, the relevent feature of a processor is that it is running threads – a single pocessor is running one thread at a time.
Thus, a software developer to fully cope with human volition reification has to capture two things: volition utterance in terms of executable code, and volution execution in term of starting threads in which the code executes. In short: a full fletched software developer, besides coding, must do 'threading'. But, how does threading look like?
SINGLE-THREADED VERSUS MULTI-THREADED APPLICATIONS
If volition utterance can be executed by a single processor, running a single program from its beginning to its end, without interruption, we have the single-threaded case. The corresponding, single-threaded, program does not have, in its code-body, any explicit reference to volition execution. Its code is not addressing any processor to be started, thus no threading. Only the thread, in which the program's own execution is happening, must be kicked off. But, of course, the volition-execution act required to start this thread, is external to the program. The developer need not care about particular O-stratum features correlating with thread-starting (threading), since this is a matter of program-usage, not program-design.
If, on the other hand, the thread, in which an application is starting, is handing over control to one or more additional threads, i.e., if an application is multi-threaded, the starting of additional threads (threading) is managed by progam code. In this case, the developer is writing program code that explicitly addresses at least one thread and processor. Now, starting threads, corresponding to volition-execution acts, is no longer external to the application and its developers. It's now part of their responsibility.
This means, that in the multi-threaded case, developers are not merely dealing with volition utterance, but also with the execution-component of human volition, in terms of thread-starting (threading). Thus, writing program-code for multi-threaded applications implies that coding volition-utterance is complemented by something like coding threading, i.e., something like organizing volition-execution. Multi-threaded software development, inevitably, penetrates O-stratum territory.
WORKFLOW TECHNOLOGY IS ABOUT THREAD MANAGEMENT
The issue is, that today's developers do not pay attention to their operating in the O-stratum. They do hardly account for the specific rules of the O-stratum. To me, it seems that here we are at the root of the mis-alignment misery. What kind of rules are these? And why is it detrimental to ignore them?
The answer is, that in a multi-threaded application we deal with two or more volition execution acts, refering to the same problem (whose solution is to be supported by the intended application). In general, if there are several volition acts addressing the same problem, there is some conflict potential, calling for organization to grant coordinated volition execution in favour of uninterrupted workflow.
PROPER AND IMPROPER THREAD-MANAGEMENT
In fact, the written and un-written rules, governing the O-stratum, are all about the coordinated interplay of volition utterance and execution, which a priori are potentially diverse. Effectively, O-stratum rules give rise to a subtle balance between governed (dirigistic) cooperation and self-organized collaboration, a balance fundamental to corporate identity and success.
If developers write multi-threaded programs, interspersing 'coding' with 'threading', without paying due attention to O-stratum rules, chances are that balance of dirigistic cooperation and self-organized collaboration is perturbed. In fact, by means of coded volition-execution, i.e., hard-coded threading, it's only possible to automate dirigistic cooperation, never self-organized collaboration, to the effect, that inevitably collaboration will be repressed in favour of more cooperation of assembly-line character.
The lesson to be learned is: If writing multi-threaded applications, always treat the code-parts, starting a new thread, with the greatest care possible by asking explicitly, whose volition is going to be executed by the thread under consideration, and how this volition is related to volition-execution by all other threads of the application, including the principal thread, which starts the application as a whole.
WINDOWS WORKFLOW FOUNDATION - ASSESSMENT
If you now look at Windows Workflow Foundation, Microsoft's flagship developer-tool for writing multi-threaded enterprise applications (counterpart of Oracle's BPM-Suite), you will find that even in the latest version, WF4, there is no support at all for such a practice. In fact, the workflow designer of WF4 handles threads like any other 'activity', simply as a technological component.
While in WF4, there is a separate technology for threating (workflow, workflow-coding language XAML, and workflow-runtime), the rules for workflow-coding are much the same as those for activity coding: just ordinary programming rules - though 'coding' thread-starting properly must take into account O-stratum rules and, therefore is basically different from ordinary T-stratum coding.
In summary it can be stated that WF4 is deficient, because of its lack of any technology to account for O-stratum compliant threading.
GETTING THE WHOLE PICTURE
Coming back to David Chappell's whitepaper, I am asking myself, why does he not address this severe shortcoming of WF4? Why is he speaking, instead, of "the beauty of the workflow way"?
Of course, it's a rhetoric question, since David gave me his answer, some years ago, during one of his shining talks at the 'World-Trade Center' at Zurich-Oerlikon. In a personal discussion, when I brought up an organizational (O-stratum) issue, he conceded: Well, you are considering the whole picture, while I am speaking here about technology.
Today, in regard of David's WF4 whitepaper and my above reasoning, I would respond: You may well restrict your reasoning to technology, but you will miss the whole picture ...
... so urgently required to assess the quality of multi-threaded enterprise applications and their impact on productivity and creativity.
Go to Art-Invest Website
(David Chappell & Associates)
Post Classification ---------------------------------------
Section CORPORATE / Category WHAT TO AVOID
Section GOVERNANCE / Category WHAT TO DO
Section TECHNOLOGY / Category WHAT TO KNOW
--------------------------------------------------------
I am commenting on a whitepaper by David Chappell, who explains the philosophy of Microsoft's latest version of Windows Workflow Foundation (www.davidchappell.com > Writing > White Papers > Windows Workflow Foundation > The Workflow Way: Understanding Windows Workflow Foundation), since this is a good example, how even experienced and carefully arguing technologists are stumbling over the threshold between technology and organization - across the border separating the strata of technology and organization, T- and O-stratum, respectivly.
TECHNOLOGY IS NOT SUFFICIENT
Why should we be concerned? Because, not handling properly the interplay of these two strata is at the root of the mis-alignment of IT to busisness – according to my opinion. In fact, IT and business are living in two fundamentally different, though inseparably connected strata, the T- and O-stratum, respectively. Thus, in order to achieve a seamless interaction of IT and business, we have to make sure that either respects the specific regularities of the other's stratum.
In particular, if computing technology is developing to Web-technology and, as such, is transgressing role and departmental scope to become operative in overall business (striving at so-called end-to-end applications, under the EAI/BPM/SOA-regime), technology is taken beyond the limits of T-stratum into O-stratum, and it is – therefore – exceedigly important to ensure that the basic rules governing the O-stratum are accounted for.
VOLITION UTTERANCE - VOLITION EXECUTION
Typically, software technologists, even if aware of the T/O-border's existence, do not pay proper attention to it, when designing programs and writing code. This might be due to a lack of knowledge, of how the T/O-border is appearing in code. To get control of this issue, think of programs – of their code – as manifestations of human volition utterance. Think of developers as trying hard to keep hold of humans' volition utterance, by casting it in a proper code-construct. Typically, volition-utterance is de-composed into elementary volition-acts, which in turn are re-composed by means of so-called application logic to match the original utterance.
After the elementary volition acts have been 'coded', and the application logic, assembling the corresponding code parts, has been stated in terms of straight-forward control-flow components, we are on the safe territory of T-stratum – and need not care about whatever 'deviant' features of the O-stratum. This is true, as long as we limit our attention in software manufacturing to human volition utterance, which - however - is only part of the overall volition reification, required as a pre-condition for automation by means of computing technology.
Obviously, volition reification consist of two parts: (a) volition utterance, and (b) volition execution. Now, ordinary program code can capture volition expression only, never volition execution. You may write as many sophisticated programs as you like, nothing at all will happen, as long as you do not start processors, capable of executing your programs, thus making volition execution, in itself, happen.
From this reasoning, a caveat derives: To capture volition reification properly, i.e., completely, including utterance and execution, always consider 'program & processor' as an inseparable complex. (In fact, neither a program without a processor, nor a processor without a program will make volition automation happen as a real-world event.)
THREADING
Thus, a software product, to be fully operative, cannot be restricted to program-code, it must include processor-design, as well. Of course, I am not speaking of the processor as a piece of hardware, but as a topic relevant for software development. From this point of view, the relevent feature of a processor is that it is running threads – a single pocessor is running one thread at a time.
Thus, a software developer to fully cope with human volition reification has to capture two things: volition utterance in terms of executable code, and volution execution in term of starting threads in which the code executes. In short: a full fletched software developer, besides coding, must do 'threading'. But, how does threading look like?
SINGLE-THREADED VERSUS MULTI-THREADED APPLICATIONS
If volition utterance can be executed by a single processor, running a single program from its beginning to its end, without interruption, we have the single-threaded case. The corresponding, single-threaded, program does not have, in its code-body, any explicit reference to volition execution. Its code is not addressing any processor to be started, thus no threading. Only the thread, in which the program's own execution is happening, must be kicked off. But, of course, the volition-execution act required to start this thread, is external to the program. The developer need not care about particular O-stratum features correlating with thread-starting (threading), since this is a matter of program-usage, not program-design.
If, on the other hand, the thread, in which an application is starting, is handing over control to one or more additional threads, i.e., if an application is multi-threaded, the starting of additional threads (threading) is managed by progam code. In this case, the developer is writing program code that explicitly addresses at least one thread and processor. Now, starting threads, corresponding to volition-execution acts, is no longer external to the application and its developers. It's now part of their responsibility.
This means, that in the multi-threaded case, developers are not merely dealing with volition utterance, but also with the execution-component of human volition, in terms of thread-starting (threading). Thus, writing program-code for multi-threaded applications implies that coding volition-utterance is complemented by something like coding threading, i.e., something like organizing volition-execution. Multi-threaded software development, inevitably, penetrates O-stratum territory.
WORKFLOW TECHNOLOGY IS ABOUT THREAD MANAGEMENT
The issue is, that today's developers do not pay attention to their operating in the O-stratum. They do hardly account for the specific rules of the O-stratum. To me, it seems that here we are at the root of the mis-alignment misery. What kind of rules are these? And why is it detrimental to ignore them?
The answer is, that in a multi-threaded application we deal with two or more volition execution acts, refering to the same problem (whose solution is to be supported by the intended application). In general, if there are several volition acts addressing the same problem, there is some conflict potential, calling for organization to grant coordinated volition execution in favour of uninterrupted workflow.
PROPER AND IMPROPER THREAD-MANAGEMENT
In fact, the written and un-written rules, governing the O-stratum, are all about the coordinated interplay of volition utterance and execution, which a priori are potentially diverse. Effectively, O-stratum rules give rise to a subtle balance between governed (dirigistic) cooperation and self-organized collaboration, a balance fundamental to corporate identity and success.
If developers write multi-threaded programs, interspersing 'coding' with 'threading', without paying due attention to O-stratum rules, chances are that balance of dirigistic cooperation and self-organized collaboration is perturbed. In fact, by means of coded volition-execution, i.e., hard-coded threading, it's only possible to automate dirigistic cooperation, never self-organized collaboration, to the effect, that inevitably collaboration will be repressed in favour of more cooperation of assembly-line character.
The lesson to be learned is: If writing multi-threaded applications, always treat the code-parts, starting a new thread, with the greatest care possible by asking explicitly, whose volition is going to be executed by the thread under consideration, and how this volition is related to volition-execution by all other threads of the application, including the principal thread, which starts the application as a whole.
WINDOWS WORKFLOW FOUNDATION - ASSESSMENT
If you now look at Windows Workflow Foundation, Microsoft's flagship developer-tool for writing multi-threaded enterprise applications (counterpart of Oracle's BPM-Suite), you will find that even in the latest version, WF4, there is no support at all for such a practice. In fact, the workflow designer of WF4 handles threads like any other 'activity', simply as a technological component.
While in WF4, there is a separate technology for threating (workflow, workflow-coding language XAML, and workflow-runtime), the rules for workflow-coding are much the same as those for activity coding: just ordinary programming rules - though 'coding' thread-starting properly must take into account O-stratum rules and, therefore is basically different from ordinary T-stratum coding.
In summary it can be stated that WF4 is deficient, because of its lack of any technology to account for O-stratum compliant threading.
GETTING THE WHOLE PICTURE
Coming back to David Chappell's whitepaper, I am asking myself, why does he not address this severe shortcoming of WF4? Why is he speaking, instead, of "the beauty of the workflow way"?
Of course, it's a rhetoric question, since David gave me his answer, some years ago, during one of his shining talks at the 'World-Trade Center' at Zurich-Oerlikon. In a personal discussion, when I brought up an organizational (O-stratum) issue, he conceded: Well, you are considering the whole picture, while I am speaking here about technology.
Today, in regard of David's WF4 whitepaper and my above reasoning, I would respond: You may well restrict your reasoning to technology, but you will miss the whole picture ...
... so urgently required to assess the quality of multi-threaded enterprise applications and their impact on productivity and creativity.
Go to Art-Invest Website
IT being off the Track
Post Classification ---------------------------------------
Section CORPORATE / Category WHAT TO AVOID
Section GOVERNANCE / Category WHAT TO DO
Section TECHNOLOGY / Category WHAT TO KNOW
--------------------------------------------------------
It should come as no surprise that IT is at variance with business, since IT is - in strongest terms - off the track. As a matter of fact, off the track
- dictated by the laws of automation, inherent in evolution,
- and observable in the realm of technology transfer.
1. Understanding Automation
According to the laws of automation
(1) automatization, by means of computing technology,
is only feasable to ease the handling of already existing
automata, thereby mutating them into higher-degree
automata, characterized by embedded computing.
(2) automatization comes in strictly-different, though
inseparably connected strata, including the strata
of machine-type, functional, and social automation,
whereby
(a) machine-type automation is well-known,
(b) functional automation comprises the totality of
algorithms, in the most general sense (from elementary
mathematics to most abstract theories), while
(c) social automation, consisting of a single-one global
automat, which is the machinery of publishing, publicly
storing and retrieving script/sign-based documents of
whatever format, not normally called automat.
2. Understanding the Web
In terms of technology transfer, this means that computing-technology, is resulting in
- computer-aided manufacturing (CAM - in the widest sense),
if transferred to machine automation
- good old electronic data processing (EDP),
if transferred to functional automation
- the Web, if transferred to social automation,
which, therefore, may be called Pre-Web
Accordingly, the Web is just the single-one (global) social automat, with its handling automated (in part) by means of computing technology. In short: The Web is something like computer-aided handling of the Pre-Web.
As you may have noticed, this means: With the appearance of the Web, transfer of computing technology to the single-one, global social automat, the Pre-Web, is completed.
3. Impact on IT
Now, what has all that got to do with IT?
If you agree: IT's mission is transfer of computing technology to the limited segment of the Pre-Web, pertaining to the enterprise, the answer is straight forward:
To the most part, IT's mission is completed. In fact, since more than a decade. The task remaining for IT is
(1) to delimit the particular segment of the Pre-Web, interferring
with the enterprise, let's call it Corporate Pre-Web, against
the basic Pre-Web, not related to the enterprise, to be
called Public Pre-Web, in terms of a distinguishing feature,
(2) to parallel the completed step from Public Pre-Web to Web,
by an analogous step from Corporate Pre-Web to Corporate
Web, taking into account this distinguising feature.
If you agree that the distinguisign feature is governance, meaning that
- the Public Pre-Web is intrisically self-organizing, and so is the
Web,
- in the Corporate Pre-Web, self-organization is inhibited,
to a varying degree, by governance, which enterprise leaders
are executing
the specific task of IT is to build into the self-organizing Web some supplementing piece of computing-technology, automating the handling of just the inhibiting part of the otherwise Public Pre-Web, without touching any of its self-organizing parts.
4. Path to Take by IT
This amounts to re-construct the public Web, in all its self-organizing parts, but supplemented with some computing technology accounting for governance by selectively inhibing self-organization to take effect.
At this stage of reasoning, the path of solution is discernible: Where a user of the Web, accessing it via his/her Browser, is sending a request, to either load up some information for others or to receive such information, the request may be intercepted to verify if upload or downlod of respective information is compliant with rules enforcing governance.
In short, the path to take for IT in order to satisfy their mission is, technically speaking, input validation at the browser side, properly adjusted to the kind and degree of governance required in a given company.
What I call Proper Coporate Web Usage or Proper Corporate Usage of Web-Technology is referring to precisely this path.
5. Deviant IT
However, current IT is off this path. In fact, to account for governance, IT-vendors do not branch off properly adjusted Corporate Webs, as more sophisticated island within the ordinary (public) Web, but instead develop a new construct, the so-called Intranet, a kind of 'proprietary Web'.
The single-one global Web is paralleled by an unlimited number of Intranets, whose access is no longer thesingle-one, globally reachable Browser, but a special proprietary entrance, the so-called Portal.
The new proprietary setup is introduced to account for governance, in fact, to automate what IT-vendors are mistaking for governance. Corresponding governance applications are executed. Their programs are running at the Web-Server, and their Input/Output, directives and responses, are sent and received through the Portals.
Sticking to the Intranet/Portal architecture, handling the Web-Server as just an Application server, and the Portal as its I/O-device, means giving up Web-technology altogether, and returning to the paradigma of functional programming. It means to leave the stratum of social atomation and to fall back into the stratum of Functional automation.
6. Automation of Governance does not work
Thus, current IT suffers from a severe deviation off the path, it has to take, to establish the Corporate Web, i.e., to properly tranfer computing technology to the Corporate Pre-Web.
The reason for this derailment is that IT-vendors mistakenly try to automate governance, tacitely assuming governance to be of purely functional nature, while in reality it is falling into the stratum of Social automation.
Automation of governance (by means of computing technology) does not work at all, since there is no 'Stratum of Governance-automation' to which computing technology could be brought.
Governance is living in the Social stratum and, therefore, cannot be isolated from self-organization. It must be treated as a restriction imposed on self-organization.
Accordingly, in the Corporate Web, governance is arising only in terms of company-sepcific Validation rules, applying to corporate 'Knowledge Workers', uploading and requesting information at their ordinary browsers. There can be no talk any more of Intranets, Portals, or Application Servers.
Turn to the special-interest group 'Art-Invest-Open / Corporate Subweb' at LinkedIn, to follow or enter discussion.
Go to Art-Invest Website
Subscribe to:
Posts (Atom)
