Month: July 2013

For Who The Heck is Enterprise Architecture Not?

Thinker Practitioner

While thinking of ideas discussed in this blog, have been probing the tenants that creates the fundamental characteristics of the system such as :-

  • Division Of Labor – the most important idea that revolutionized industrialization and for rise of capitalism
  • Commodiitization vs Specialization
  • Production of cost by Economy Of Scale by Division vs Multiplexing (manual vs automation)
  • Holistic vs Reductionist
  • Organic vs Inorganic (natural dichotomy)
  • Autonomy (increased self sufficiency) vs Corporate Sovereignty
  • Natural Selection leading into Adaptive vs Self Regulation leading into Generative
  • Centralization vs Polycentrism; and Federation
  • Simplicity vs Complicated (not to be confused with Complex System)

The above premise must be used as background in probing the discipline EA – which is essentially a System Theory being an integrative of several disciplines such as sociology, economics, business management, information technology etc

Defeating Cognitive Bias and Instant Gratification

https://www.cia.gov/library/center-for-the-study-of-intelligence/csi-publications/books-and-monographs/psychology-of-intelligence-analysis/art12.html

Basically have been battling within my head why this discipline Enterprise Architecture went so whacky in the corridors of corporates. I think all the below discussed stuff are symptoms. The core reasons I think is basically in the deviant behavior that corporate culture tends to promote driven by short term gains. Lets call this deviant theory (Corporate) Anomie a concept developed by Emile Durkheim, a French sociologist, who introduced this concept of Anomie in his book The Division of Labor in Society, published in 1893. Later expanded in the book Suicide published in 1897. Emile Durkheim is considered as the “father of sociology”.

1. Not for those Not solving Systemic Concerns

https://ingine.wordpress.com/2012/08/03/transformative-enterprise-architecture-framework-connecting-strategy-tactical-operational-execution-implementation/

https://ingine.wordpress.com/2007/08/22/enterprise-architecture-economic-model-system-dynamics/

Enterprise Architecture (EA) as a discipline is engaged to solve problems within systemic context. Where the (a) challenge of realizing business strategy by enabling relevant business capabilities (b) delivered by set of tactical objectives (operational) achieved by (c) making informed and decisive investments in technologies. When such systemic concerns are not being addressed, then EA is overkill. EA while it strives to solve macro concerns it does so by aligning well designed several sets of micro objectives.

2. Not for those who lack appreciation for Order and Maturity 

Generally, EA as a discipline is better desired when an enterprise strives to scale order of maturity to manage complexity by rational means. To develop organizational skills, a decisive competencies framework is desired.

https://ingine.wordpress.com/2010/03/17/enterprise-architecture-maturity-model-framework-federal/

https://ingine.wordpress.com/2012/08/01/developing-enterprise-architecture-practitioner-competamcies/

https://ingine.wordpress.com/2012/08/02/dod-ea-competencies-development-framework/

3. Not for those who cannot deal with Abstraction

https://ingine.wordpress.com/2007/08/01/teaching-an-elephant-to-dance/

EA is not for those who have not trained their mind to think in abstraction. Especially those who find themselves comfortable in dealing with physicality and forms will require head wrenching exercise to hone mind to develop abilities to deal with varieties of abstractions, while representing them with varying semantics that help in  delineation, thus leading into layered representation in terms of a framework.

“Separation of Concerns” is one such technique that achieve delineation by introduction of semantics and eventually it also helps in the design of EA Framework.

https://ingine.wordpress.com/2007/08/17/christopher-alexander-father-of-pattern-language/

https://ingine.wordpress.com/2008/03/12/ciao-interesting-pursuit-after-ea-ontology/

EA is not for those, who in abstraction find it difficult to delineate contextual from conceptual; and conceptual from logical and logical from physical.

4. Not for Reductionist; instead suited for Holistic Thinkers

https://ingine.wordpress.com/2007/08/08/the-black-swan/

https://ingine.wordpress.com/2008/03/15/six-sigma-aids-only-linear-transformation-not-non-linear-radical-transformation/

EA is not for those who are only reductionists in approach and who think everything in the world can be reduced to simple set of objects or objectives. EA is not necessarily Cartesian and certainly not for linear thinkers. EA is not about immediately discovering implementation; in fact it is delayed gratification by introducing decisive rationalizing process before subjective strategy turn into executable objective actions yielding the best business results by leverage.

5. Not for those who pursue Transformation without Goals

Although EA might help manage both organic and inorganic growth of an organization; by itself it is a disciple dealing with inconsistencies owing to structure and mechanism found within and their impact on transformation augmenting enterprise growth

https://ingine.wordpress.com/2008/12/06/enterprises-in-generative-transformation-akin-to-universe-life-cycle/

6. Not for those who pursue merely Functional Goals and NOT be concerned with Ecosystem’s Harmony 

https://ingine.wordpress.com/2007/08/03/huichols-shamanic-vision-architecture-of-the-consciousness/

EA is not a mere IT role, especially a difficult role for those who have worked only in the areas of IT infra and in delivering such services. EA is not limited only to physical layer.

EA is not for those who find it difficult to distinguish business strategy from business architecture; business architecture from application architecture; application architecture from technology (infra) architecture. And, importantly EA is an overarching and all encompassing meta-architecture inclusive of all those levels of architecture that holistically represents an enterprise in relevant abstractions.

Architecture is a holistic sum striving to achieve systemic balance by aligning function, performance and cost

Math and statistical although important, those approaches alone are not adequate to envision future capabilities for an organization. Likewise advents in technology alone do not necessarily prove transformative. Knowledge of IT architecture by itself is not transformative. Instead, EA as a discipline  requires to integrate Architecture, Capital Planning and Program Portfolio Management. All these brought together by productive Governance; even then the challenges of future remains fleeting.

7. Not for those who think Taxonomy suffices to represent EA and NOT Ontology 

https://ingine.wordpress.com/2008/12/15/implicate-order-descriptive-mechanism-form-large-systems-of-systems/

https://ingine.wordpress.com/2013/06/21/implicate-order-probabilistic-ontology-complexity-theory/

There is distinct semantics used to represent each of the layers (“separation of concerns”). Semantics introduces dimensionality to the architecture layers and they cannot be represented with limited set of semantics in limited dimensions. Each layer that is semantically different from the other requires transformation in planning and design to discover the opportunities in each layer. Ontology plays an important role in developing and assimilating ideas leading into discovering creative transformative opportunities. EA is not for those who tend to reduce everything into simple 2D representations in the hope that simplified versions help manage complexity better.

8. Not for those who are Programmatic in Approach and Not Practitioners 

Not for those who do not understand what disposes them to be credible management consultants. Furthermore, also not for those management consultants who have not gained appreciation for structure, semantics driven architecture and mechanism within; and their role together in systemic transformation, functional modernization and economic optimization.

Consultants are those who have gained immense multi-lateral experience in the industry in variety of areas especially in conducting transformation, modernization and optimization related activities. Generally individual gains such experiences driven by motivation to solve large fleeting problems those are systemic in nature. Not by pursuing opportunities where sole motivation is revenue generation no matter what.

Practitioners develop insight by assiduously probing the problem and complexity. The skills do not develop overnight. It is not swashbuckling nor shooting through the hip. It is developing opportunity by being proactive and intense probing.

There are no Outliers (myth destroyed by  Malcolm Gladwell http://en.wikipedia.org/wiki/Outliers_(book) )

“””A common theme that appears throughout Outliers is the “10,000-Hour Rule”, based on a study by Anders Ericsson. Gladwell claims that greatness requires enormous time, using the source of The Beatles’ musical talents and Gates’ computer savvy as examples.[3] The Beatles performed live in HamburgGermany over 1,200 times from 1960 to 1964, amassing more than 10,000 hours of playing time, therefore meeting the 10,000-Hour Rule. Gladwell asserts that all of the time The Beatles spent performing shaped their talent, and quotes Beatles’ biographer Philip Norman as saying, “So by the time they returned to England from Hamburg, Germany, ‘they sounded like no one else. It was the making of them.'”[3]Gates met the 10,000-Hour Rule when he gained access to a high school computer in 1968 at the age of 13, and spent 10,000 hours programming on it.[3]“””

9. Not for those who provide professional expertise as Contractor and NOT as Practitioner

https://ingine.wordpress.com/2012/08/01/developing-enterprise-architecture-practitioner-competamcies/

http://www.ipthree.org/frontpage-features/94-messageprofessionals

http://www.cos-mag.com/human-resources/hr-columns/whats-in-a-name-professional-vs-practitioner.html

It is not a contracting role – In theory contracting assumes that the client understand the requirement and they control the way project gets executed. This is obviously flawed approach.

Generally those who have thrived only in delivering IT services of operational nature are not the candidates for conducting management consulting, since most of their career has been delivering IT solutions and services for a requirement determined by the client and their consultants.

10. Not for those who do not value Professional Integrity

https://ingine.wordpress.com/2007/08/09/enterprise-architect-fighting-obfuscation/

Importantly EA is a Practitioner Discipline introducing high standards emphasizing on quality in rendering and most importantly professional ethics promoting the desired ethos for organization’s evident growth and maturity. The results of EA achieves transparency, accountability and line of sight driven by “structuralism” striving to achieve “order”.

11. Not for those who build career around Tools and NOT around Discipline Integrating Science and Art

EA is not a discipline that can be developed by building career around tools. Tools by themselves do not create Art and neither advances Science. EA is integrative of architecture, capital planning and program management. All these driven by corporate governance.

https://ingine.wordpress.com/2008/12/01/creative-people-at-work/

https://ingine.wordpress.com/2008/11/23/in-lack-of-theory-planning-will-be-along-a-straight-line/

12.Not for those who engage merely in IT Operation and Implementation

EA is integrative of strategy, operations and implementation

https://ingine.wordpress.com/2012/08/03/transformative-enterprise-architecture-framework-connecting-strategy-tactical-operational-execution-implementation/

13. Not for those who DO NOT Develop Enterprise Transition Plan and Operating Model (must skill for EA)

https://ingine.wordpress.com/2010/04/12/etp/

https://ingine.wordpress.com/2008/12/06/ea-framework-for-transition-planning/

14. Not for those who think EA and Solution Architecture are synonymous

http://blogs.msdn.com/b/gabriel_morgan/archive/2007/09/02/enterprise-architect-vs-solution-architect.aspx

http://weblog.tetradian.com/2012/09/13/linking-ea-with-sa/

 15. Not for those obsessed with Dominance and NOT Balance

EA cannot help organization achieve balance and sustainability without Governance

https://ingine.wordpress.com/2008/02/22/governance-managing-conflict-change-the-intrinsic-duality-of-an-enterprise/

16. Not for those who engage Masquerading Solution Facades and Intellectual Contrives 

EA improves “Loss of Innocence” while it DEFEATS Solutions that do not align with context.

https://ingine.wordpress.com/2007/08/01/teaching-an-elephant-to-dance/

 17. Not for those who think Service Oriented Architecture, Correlation Architecture, etc by themselves constitute EA

https://ingine.wordpress.com/2007/07/30/ea-framework-to-accomodate-soa-style/

 18. Not for those who merely think Strategy alone and NOT Innovation help create Newer Opportunities

Innovation to create newer opportunities while achieving higher order in capabilities and business sustainability are key to ensure system harmony against the challenges of existing and ensuing complexities.

https://ingine.wordpress.com/2012/12/20/moving-from-darwinian-adaptive-to-generative-transformation/

List for NOT’s can be endless….

…N. Is Certainly for System Thinkers

Advertisements

Achieving Universal Healthcare Interoperability by Algebra instead of System Integration – Solving Uncertainties in Large Complex System

For discussion on algebra behind Universal healthcare Interoperability :- Discussion by Dr. Barry Robson who has pioneered in computational biology; developed Quantitative Semantic Algebra to realize Probabilistic Ontology to solve large systems riddled by complexity and afflicted by uncertainties.

http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=242195622&gid=3105178&commentID=138621684&goback=%2Eanp_3105178_1369067682268_1%2Eamf_3105178_69634045&trk=NUS_DISC_Q-subject&_mSplash=1

Difference between Algebra vs Arithmetic 

Algebra vs Arithmetic

On Tom Munnecke’s blog discussion

Dear Chuck I’m using this informal salutation in honor of your status as one of the fathers of VistA, I was impressed with your concise and accurate

via Open Letter to Chuck Hagel: DoD still does not know what the hell they are doing.

Extract from Tom Munnecke’s blog below observation vital to achieve universal healthcare interoperability; such that they eventually enable Evidence Based Medicine (EBM) and Pharmacogenomics which transform the healthcare to evidence based and into personalized healthcare delivery. The mechanism of interoperability across the heathcare actors:- providers, payers, pharma etc and also working across numerous data standards is achieved by weaving together probabilistic inference, linguistic semantics, inference engine, machine learning etc driven by algebric mathematical underpinning. Most importantly the probabilistic ontology achieved by algebriac mathematics developing capabilities beyond RDF / OWL creates opportunities for studies such as Complex Adaptive System, which together with EBM allows for systemic studies ensuring efficiency in healthcare management and efficacy in healthcare delivery.

From Tom’s Munnecke’s posting:-

<.  This is equivalent to building a ladder, rather than trying to get out of a hole by digging deeper.  The current approach throws away the conceptual integrity that made VistA such a success, replacing it with an “aircraft carrier” mentality that obliterates the ethos that drove VistA’s success.  The President’s Council of Advisors on Science and Technology published a health IT study that a great job of describing some of the foundations of this metadata approach, and treating Health IT as a “language” problem, not an “interface.”  This is a very nuanced difference, but think of how easy it is to link an Amazon.com book reference to a Twitter post:  you simply drag the URL of the book to Twitter, and press send.  You do not need to interface Twitter to Amazon, or use the “Book reference nomenclature standard,” etc.  It is simply an intrinsic property of the information space.  Similarly, we could build a healthinformation space that that allowed this kind of sharing ( with enhanced patient privacy and security), as an intrinsic of being part of the common information space.  This move to a higher level of abstraction is a bit like thinking of things in terms of algebra, instead of arithmetic.  Algebra gives us computational abilities far beyond what we can do with arithmetic.  Yet, those who are entrenched in grinding through arithmetic problems have a disdain for the abstract facilities of algebra.  The DoD is rejecting the Uplift model, instead succumbing to the “Humpty Dumpty Syndrome” – breaking things into pieces, and then trying to integrate them again.  This is great work for “all the Kings men” as long as the King has the resources to pay them to try to put Humpty together again.  But sooner or later (and I had hoped you would have chosen the “sooner” option) the King needs to cut off this funding.>>>