#eavoices

Enterprise Architecture as Science?

by

It is common to describe Enterprise Architecture as a science. Here are a few examples.

  • We see enterprise architecture (EA) as a scientific sub-discipline both of computer science and business management. The twice mentioned word “science” here emphasizes our certainty that EA is an exact discipline able to produce precise approaches and solutions. Wolf Rivkin, Enterprise Architecture and the Elegant Enterprise (Architecture and Governance 5-3)

A few years ago, I discussed this question with @RSessions

Roger is one of the few people I know who is seriously committed to empirical investigation of EA. I believe he shares my view that much EA falls woefully short of anything like scientific method. To my eye, many knowledge-claims within the EA world look more like religion or mediaeval scholastic philosophy than empirically verifiable science.

But why does it matter anyway? Why would people be so keen to claim EA as a science? Here is what Foucault had to say to those who wished to claim Marxism (or psychoanalysis) as a science.

“When I see you trying to prove that Marxism is a science, to tell the truth, I do not really see you trying to demonstrate once and for all that Marxism has a rational structure and that its propositions are therefore the products of verification procedures. I see you, first and foremost, doing something different. I see you connecting the Marxist discourse, and I see you assigning to those who speak that discourse the power-effects that the West has, ever since the Middle Ages, ascribed to a science and reserved for those who speak a scientific discourse.” Michel Foucault, Society Must be Defended: Lectures at the Collège de France, 1975-76 (English translation by David Macey, 2003)

In other words, claiming EA as a science is not about the rational basis for its knowledge-claims but about its authority, or what Foucault (in David Macey’s translation) calls Power-Effects. Thus instead of claiming EA as a science, one might follow Gartner in claiming EA as a discipline.

Enterprise architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. EA delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve target business outcomes that capitalize on relevant business disruptions. EA is used to steer decision making toward the evolution of the future state architecture. (Gartner website, retrieved 17 August 2013)

Foucault characterizes a discipline in terms of the selection, normalization, hierarchicalization and centralization of knowledge. We can surely recognize these processes in the formation and maintenance of EA frameworks such as TOGAF and PEAF, as well as various attempts to construct Bodies of Knowledge. Foucault notes that “the progress of reason” necessitates “the disciplinarization of polymorphous and heterogeneous knowledge”. This might lead us to expect some institutional resistance to heterodox ideas, as well as the marginalization of “amateur scholars”.

Foucault is interested in ways that people and organizations can respond to disruptive forces large and small, from “great radical ruptures, massive binary divisions” to “mobile and transitory points of resistance, producing cleavages in a society that shift about, fracturing unities and effecting regroupings”.

Just as the network of power relations ends by forming a dense web that passes through apparatuses and institutions, without being exactly localized in them, so too the swarm of points of resistance traverses social stratifications and individual unities. And it is doubtless the strategic codification of these points of resistance that makes a revolution possible. [Michel Foucault, History of Sexuality Vol 1.]

Gartner’s notion of EA-as-discipline seems quite consistent with this. It is focused on mobilizing the response to disruptive forces (for which Gartner uses the rather strange word “nexus”). EA gains its power from a kind of strategic codification (or discursive practice), allowing the enterprise to “harness the nexus”, thereby “revolutionizing business and society, disrupting old business models and creating new leaders”. (Gartner website, retrieved 17 August 2013)

Update

@tetradian commented on the dangers of spurious ‘authority’ – ‘spurious’ in sense of claiming an aura of ‘authority’ when there’s none to be had (b/c it isn’t ‘science’ anyway)

I agree that claims of scientific status or method in the EA world are generally spurious. But there are other ways of asserting authority. For me, the key question is why (and on what grounds) should anyone trust the pronouncements of EA. It is not just about danger versus safety, but about authority versus authenticity.

    Looking back on Year 2

    by

    As a follow on to my blog post that reflected on year 1 of EA at Bristol (http://enterprisearchitect.blogs.bristol.ac.uk/2012/04/17/looking-back-on-the-first-year-of-my-ea-role-at-bristol/), here’s a summary of the top three key things I covered in year 2: Raising the profile of EA: a two-hour workshop with the Portfolio Executive (http://www.bris.ac.uk/planning/programmesandprojects/portfolioexecutive/). This senior decision-making group within the University were interested to […]

    Top Strategy and Planning Lessons Learned

    by

    I’ve spent a few years designing and facilitating strategy and planning processes (aka business performance management or BPM) and have gained some insight that I thought might be interesting to folks. This article is a work-in-progress set of best practices I feel are worth sharing. Top Business Performance Management Lessons Learned 1. Be clear on…

    Schism and doubt

    by

    On Friday 14th June, there was a public meeting of the EAST group, entitled Perspectives on Enterprise Architecture and Systems Thinking, kindly hosted by BT in its offices near St Paul’s. Tom Graves has posted a detailed write-up on his blog At ‘EA and Systems-Thinking’ conference.

    What is the purpose of dialogue between EA and ST? Putting aside the debate about what the labels “Enterprise Architecture” and “Systems Thinking” might mean, there is certainly a thought that the two (or more) communities can learn from each other. There are strengths and weaknesses on both sides – so we may be able to produce a critique of EA from an ST perspective, or a critique of ST from an EA perspective. For example, in his presentation, John Holland asserted that “EA is broken – How ST can help”. (See Tom’s blog for summary.)

    This kind of material often arouses a certain kind of resistance. “He’s not talking about me, he must be talking about someone else.” Where are the EAs to whom such a criticism as John’s might apply? Surely the fact that we are going to these meetings, or reading these blogs, or participating in these Linked-In discussions, puts us into the most sophisticated and reflective quartile? 

    One of the fundamental questions underlying discussion of EA and ST is imagining some kind of landscape with more or less distinct zones: EA over here, ST over there, this or that school of EA, this or that school of ST, good EA versus bad EA, authentic ST versus fake ST, mainstream versus next practice.

    I have written several pieces on the relationship between Enterprise Architecture (EA) and Systems Thinking (ST), on this blog and elsewhere, but such pieces are always open to challenge by those who disagree about the correct use of the labels.

    • “That’s not what real Enterprise Architects do.”
    • “That’s not really Systems Thinking.”

    So it sometimes seems that we cannot even start talking about EA and ST, and about the relationship (if any) between them, until we can agree what these terms mean. The desire to name things properly is an ancient one, and can be found in the Analects of Confucius. (See my post on the Wisdom of Confucius). But the prevailing desire to impose one’s own definitions leads to endless and mostly unproductive debate on Linked-In and elsewhere. For this meeting, we hoped for a more productive energy, and I like to think we largely succeeded.

    Some of the speakers fell into a dialectic mode of presentation – on the one hand EA, on the other hand ST. This can be useful as a starting point, but if the distinction between EA and ST is taken too seriously it may drive a wedge between practitioners. As Tom commented, “there don’t seem to be any clear distinctions, any absolute boundaries that determine who’s ‘in’ and who’s ‘out’ – all a bit blurry all round, really.” For my part, instead of trying to avoid making any distinctions whatsoever, I put up a few slides with some provocative and playful distinctions, flagged with “possibly” and “tongue-in-cheek”. But I haven’t always been consistent about this, and (as someone pointed out to me) I probably need to be more careful when making a rhetorical contrast between “mainstream” and “next practice”.

    The EA/ST landscape may include Confucian and dialectic modes, but it should also include Daoist and dialogic modes. (For a brief explanation of the difference between dialectic and dialogic, see Wikipedia: Dialogic.) Robust debate between dogmatic EA and dogmatic ST may lead to schism, but even that is preferable to bland and empty speech. If we want to have a serious discussion about the strengths and weaknesses of current practice, then we must be prepared for robust critique, and we should not have to worry about over-sensitive practitioners taking everything personally.

    One possible aspiration is to build a bridge between two communities, or perhaps even one single community. In their presentation, Patrick Hoverstadt and Lucy Loh presented some recent work of the EAST working group, showing how the concepts and techniques of EA and ST could be combined to address business challenges. This work is ongoing.
    If we take the view that community building depend on affiliation (finding common beliefs and values), then any schism and doubt may seem to undermine this agenda. However, there is a more robust path to community building, based on alliance (accepting and overcoming difference for the sake of collaboration). For an eloquent defence of what she calls Deep Disagreement, see Margaret Heffernan’s TED Talk Dare to Disagree.

    Perhaps some people will think me perverse, but I look forward to plenty more friendly disagreement between EA and ST in future.

    The Chief Marketing Technology Officer – CMTO – and the EA

    by

    Admittedly, it’s a bit of a leap – addressing the converging roles of the CIO and CMO (Chief Marketing Officer) with an Enterprise Architecture perspective, particularly when a CMO’s “Enterprise” ranges far and wide of the actual organization they serve. The Internet does extend now into outer space a bit, after all.

    The classic scope of the Enterprise is that which is contained within both an operating and investment budget (OPEX and CAPEX) – the assets and resources that are produced, consumed and used under a common business (or mission) strategy.  Perhaps a company or agency, a department or line-of-business, or some other facility or organization segment. Enterprise Architects (EAs) most often influence these sorts of enterprise contexts.

    A CMO certainly runs a business segment, investing in people, assets and consumable resources – most of which can be touched, inventoried or governed in some way to align with the segment’s business strategy (make revenue, deliver goods or services, be a public steward, contain costs, mitigate risk). A CMO’s “Enterprise”, particularly in this digital age, is also that of the online, networked audience. Social media profiles, data feed providers, branded communications channels, publisher networks and web app platforms – these also are part of the CMO’s “Enterprise”, and require some degree of monitoring, governance, investment control, integrated standardization.  Digital marketing campaign assets and advertisements aren’t usually just thrown to the wilds of the Interwebs (unless they are) – they’re carefully planned, tested, optimized, controlled, monitored and analyzed – both their original forms and any derivations.

    Note that, for purposes of this blog, the “CMO” is readily compared to the “Government Services PR Lead” or “Constituent Relationship Communications Lead” – or basically any other leadership position in charge of outreach, communications and basically marketing of Public Sector capabilities or services.

    “Traditional” EA doesn’t seem to address the Internet of things, stuff and services as something to be modeled, or deemed compliant, or aligned with standard reference frameworks. This isn’t unlike trying to apply one EA’s influence across an SOA interface boundary – while there are certainly very useful, open standards for both to leverage in delivering SOA success, one organization’s EA model compliance and content isn’t necessarily usable or useful to another organization.  

    Can or should one’s Enterprise Architecture scope and framework be applied to all those 3rd-party Internet-hosted products and services a CMO relies upon?  Why not – particularly if this “External Interactive Marketing” business domain is scoped according to some kind of “services taxonomy” (that may likely have parallel definition back within the organization).  For example “Data Publishing” services (like Equifax), “Search” services (like Google), “Information Sharing” and “Community Management” services (like Facebook and LinkedIn).  While these Internet capabilities aren’t owned by the organization, how they’re used can certainly be modeled and approached from the same architectural principles, standards and experience as a already found within the organization.

    Enter the “Chief Marketing Technology Officer” (CMTO), a role that combines digital marketing practice and Internet services technology knowledge, with the classic IT investment, management and operations knowledge of a CIO (or CTO). The CMTO not only understands what’s necessary to secure and control information within his organization, but also understands what does or can happen to this information on the public Internet – planned or not.  
    Below is a proposed standard “Domain Reference Architecture” for the CMTO role, depicting also the intersection (and expansion) of the traditional EA role.

    Chief Marketing Technology Officer Domain Reference Architecture

    Helping the CMTO apply architectural principles, governance and repeatable methods for the information lifecycle external to the organization – that’s a worthwhile and appropriate role for the Enterprise Architect…and may be all the more relevant as programs and lines-of-business holistically outsource their information management capabilities to 3rd-party providers and cloud services.  Full-scope alignment of the EA practice to the CMO/CMTO’s domain is probably inevitable, as more industry analysts point to the rapid and dominant global enterprise demand of marketing departments on their organization’s IT investment portfolio.

    As written on the Oracle Social Spotlight Blog, “CMOs must see the science behind the art. CIOs must see the art behind the science”.  EAs must align the art and science to meet the business case.