Navigation

Blogs

A recent posting by Ron Segal on the LinkedIn discussion group for business architecture raised a specific question that strikes to the heart of what I think I have been trying to say for years. Here is my posting in respoonse, which I thought I'd record here for future reference:

The question Ron raised was: "if business architecture is really about planning the architecture of the business as a whole, its going to have to work with all of the different specialisms, HR, Marketing, Logistics, Finance, Operations, Production, IT etc. So one of the tricky issues ... is how does business architecture in that sense add value without being perceived to be interfering" This is exactly the question that I have been trying to answer from many different angles and viewpoint during the months and years I've been posting to LinkedIn, and well before. So thanks for asking!

The simplest way I can put it is that business (and/or enterprise) architecture provides the generalist view in the age of specialization. From my point of view, no issue, no aspect of business is off the table for being considered from an architectural perspective. This is why you will see me stressing certain themes over and over again in my postings:

1. Language -- I don't think it's up to architecture to create all new terminology, but rather to provide reconciliation among the multiple languages spoken by all the specialists among themselves. The architectural view should literally "take them at their word" and find ways of clarifying and disambiguating among disparate tribes. This is very challenging, and requires sophistication beyond a handful of concepts -- ("capability" comes to mind).

2. Architecture vs. decision-making -- In my opinion, if this challenging role of capturing and joining up the complete understanding of business (enterprise) is performed successfully, the value is intense, more than justifying the effort. There is no need for people in that role to also be challenging the specialists in their individual judgments, and that includes those who specialize in tough management trade-offs. I stress humility as the general approach to this work.

3. The term "architecture" -- The term itself conjures the creative aspects of the building disciplines, but the builders of businesses are entrepreneurs, and that is not an essential aspect (in my view) of the architecture discipline in the organizational space. The reason the architecture term *is* appropriate, to me, is that it conveys the idea of understanding the elements of the domain, and how they are related, structurally and behaviorally. It focuses attention on the interfaces, from outside-in, inside-out, and top to bottom. Not easy. Very valuable.

4. Requisite variety -- Borrowed from the arena of the systems sciences, Ashby's concept of requisite variety says that a controlling mechanism needs as much complexity (variety) as the factors to be controlled. My view is that architectures are aspects in the controlling mechanisms of business and enterprise (sometimes knowing when loosely-coupled control is appropriate).

5. Skill-set -- Before I left IBM I led the effort to incorporate business architecture into the HR database, and we did so as a set of skills that applied to many roles and job titles. I think I've painted the scope and complexity of the potential for an architectural view so as to indicate the unlikelihood of the "requisite variety" residing in one individual.

6. Not a project -- Again, I hope it's clear that my perspective suggests an ongoing mindset and effort of joined-up understanding, not a once-and-for-all project, though there may need to be kick-off, jump-start, or some such consciousness-raising event.

7. Immaturity -- Do we have the tools and techniques to do all of what I have asserted smoothly, seamlessly, and effectively? I think that we do not, and that the discipline of being rigorous generalists in a world of specialists has merely scratched the surface of the tip of the iceberg of what can be done. Which, for me, is where the fun lies!

If anyone really wants to use the term "business architecture", let's consider that anpther kind of architecture that is closer in practice than building architecture is landscape architecture. A business. like a landscape is made up of living entities that are parts of multiple, intersecting ecosystems. When people intervene to "architect" the landscape there is planned building of various structures. But if those structures are not primarily focused on fostering good conditions for the flora. the architecture will not be deemed fit for purpose.

I say this is a simille because I'm just saying business architecture may be like landscape architecture, in the sense of having similarities. I'm not proposing that this notion should be the primary way of understanding and discussing architectures of business, but I am saying that Golden Gate Park is more similar to a business enterprise than the Golden Gate Bridge.

The current paradigm will stipulate that growth is good and necessary. At least that has been the buzz in my neck of the woods for as long as I can remember. Even thoughts like "Limits to Growth" start from the assumption that growth is good, and it will be too bad to have to limit it.

Maybe that's the wrong meme. What if we adopt a meme such as "intensification"? Not so much "more, more, more" but rather "deeper, deeper, deeper".

This thought is underpinned or undermined by which of several concepts of wealth is held in mind. My money supplies and streams are not experiencing a lot of growth, but I have a deeper relationship with dogs (just as an example).

David Brooks, the columnist for the New York Times, has a column on "protocols", and the nature of an economy built on protocols rather than products. This is a spin on the information economy, as discussed by Hal Varian and others. It makes the point that protocols are more and more pervasive, in the form of computer programs that manage aspects of business, to the procedures followed to have a franchise operation conform to the parent standards.

This post is inspired by some interactions I’ve been having with the enterprise architect community, primarily at this LinkedIn group . There are ongoing debates about how to define what it is that enterprise architects do, what the purpose of enterprise architecture is, and how to explain it to decision-makers.

I've been engaging recently in a renewed conversation with the members of Metaphorum, a loose-knit confederation of thinkers who generally follow and preserve the work of Stafford Beer, one of the pioneers of cybernetics, systems thinking, and the application to business.

That title denotes something that I always do. Wherever I go, for instance the VSM thought framework is like an tool on a heads-up display for me -- always available as a device to peer through at each new interesting social organization that I stumble upon.

There are people who think building an enterprise is JUST LIKE building a house or aircraft. This is false. This is misleading in a profound and pernicious way. I won't name names, because this seems to be the dominant view in some quarters.

Anyone who has tried to start or maintain and grow an enterprise can attest that there is no shop manual. This is much more a matter of nurture than construction.