Arguing with Mendeleev

@JohnZachman insists that his classification scheme is fixed—it is not negotiable. Comparing his Zachman Framework with the periodic table originally developed by Dmitri Mendeleev, he says, “You can’t argue with Mendeleev that he forgot a column in the periodic table”.

Well, actually, you can. If you look at the Wikipedia article on the Periodic Table, you can see the difference between Mendeleev’s original version and the modern version. Modern chemists now use a periodic table with 18 columns. As Wikipedia states, “Mendeleev’s periodic table has since been expanded and refined with the discovery or synthesis of further new elements and the development of new theoretical models to explain chemical behavior.”

What makes chemistry a science is precisely the fact that the periodic table is open to this kind of revision in the light of experimental discovery and improved theory. If the same isn’t true for the Zachman Framework, then it can hardly claim to be a proper science.

Some observers have noted that early versions of the Zachman Framework had fewer columns, and see this as a sign that the number of columns may be variable and open to discovery. But the Zachmanites reject this; they say that the six columns have always existed, it was just that the early presentations didn’t mention them all. “Humanity for the last 7,000 years has been able to work with what, how, who, where, when, and why.” (This sounds like a Just-So-Story – “How the Enterprise Architect Got His Toolset”)

Mr Zachman has a degree in chemistry, so he ought to understand what makes the Periodic table different from his own framework. However, some of his followers are less cautious in their claims. I found an article by one Sunil Dutt Jha, whose “proof” of the scientific nature of EA seemed to rely on two key facts (1) that Mendeleev transformed alchemy into chemistry by creating the periodic table, and (2) that the Zachman framework looks a bit like the periodic table, therefore (3) EA must be a science too.

An earlier version of this comment was posted on Linked-In Is it true to say that “Enterprise Architecture” is a scientific basis for creating, maintaining and running an Enterprise?


Erecting the Framework (Feb 2004) – John Zachman discussing his Zachman Framework for Enterprise Architecture in an interview with Dan Ruby

John P. Zachman, The Zachman Framework Evolution (2009-2011)

Sunil Dutt Jha, Biggest myth – “Enterprise Architecture is a discipline aimed at creating models” (January 2013)

See also 

Richard Veryard, Satiable curtiosity (September 2009)

Alan Wall, Pattern Recognition and the Periodic Table (March 2013)


Link added 24 March 2013

Open Work unedited notes on my current thinking

Below is a copy and paste of the document where i note down all my thoughts on what i’m calling ‘Open work’

I thought i’d share the raw shizzle in the interests of practising what I preach and trying to be as open as possible as I work these thoughts through (hopefully) into something coherent, useful and publishable. Enjoy! all comments welcome

Open Work

What is openness?

Openness is the freedom that is felt at a personal level and experienced in an organisational context to share thoughts feelings, opinions and information
Openness is also the receptiveness to receive what is shared
Openness is the culture that pervades social interactions that are based on freedom

Later on I need to talk about freedom and how to enable that freedom.
Leverage social proof
Don’t judge the sharer, judge the hoarder
Hoarding

The construct that i describe as Openness has both an organisational and personal element

because the Silos can be both be structural and interpersonal
show an organisation, function, team, interpersonal siloes

siloes that can be vertical within hierarchy or horizontol across functions.
graphic of horizontal and vertical partitions.

Ask yourself how many edges do I have, how many edges does my team have? My department? Directorate? How removed am I from these?

What pattern can you apply to break these down? link to fast iterations of virtual structures,
that revolve around hubs. what are the hubs?
Who are the hubs?

WHY?

Symptoms

Where does your orgs ideas come from?
E.g.g corporate goals
Who sponsors your change activity?

are two people/temas working on the same thing in isolation?
Are two intiatives unknowingly working to undermine each other?
are two changes competing for the same resource?
Is there conflict between business units, functions, teams people caused by competing goals?
Do you get different answers if you ask different employees what the organisations top 3 priorities are?

top down
bottom up

top up
bottom down

top bottom
up down

What is wrong with these words where is the width? (Flanking)
These words are part of a language of hierarchy that is anachronistic.

-Reject closed language
Recognise the language you use that is not open.

Compare contrast open/closed phrases, investigate the etymology of these words
E.g.
Buy-in
Post
Role
Function
Directorate
Structure
Organisation
Group
Alignment
Influence
Direct report
Subordinate
Meeting
Conference
Desk
Office
Work
Strategy
Outcome
Lead
Manager
Senior
1:1 (like its something special)
Presentation
Promotion
Hot desk
Go for a coffee
Deadline
Cascade
All hands
Rush hour
Deliverable
Stakeholder is there someone who isn’t a stakeholder?
Influence
Performance review
Transparency: of many things e.g. committments
Lunch and learn is a broken concept, why not learn the rest of the time, and why not in work time

Staff survey, do you share the results and raw data?
concepts/principles
Should I split these into, attitude, enablers, constraints, principles?

Leadership = openness
Be brave

‘Open Argument’, argument is not negative!!!
Conflict too strong word, but the debates are open and lead to a better position, rather than seething resentment

Task over structure

Negatives/things to look out for
Openness needs accountavility or you create cracks. May be counter uintuitive

Also decision making

Signal/Noise and noise reduction.

What are the mechanisms for noise reduction?
Timeliness
Context, tagging or do I need to go there
Cones of interest, sharing those up front. What do I need to know

-Context

Bring the contextual baggage to a conversation.

Move conversation through different mediums for maximum value e.g. Start conversation on desktop, continue on mobile

Relate data and meta data to conversations, e.g. Here is the conversation that led me to talk to you.

Design for collision

-radical/extreme/progressive sharing/shariarchy
-channels of discovery
-foster emergence
-Social architecture: (thinking stack/zachman etc)
-connectedness (connectivity and psychological sense by what? shared vision?
-finding
-serendipity design for
-ego-less
-embrace criticism but by embracing criticism how to avoid paralysis (too many arguments)
-Clear threshold for decision making – stops paralysis
-radical un-secrecy
-Virtual Structures
– finite structures, rapid iteration of create, grow, destroy
– task/problem networks (mayfly)
-Now-ness – relate to the when/tenses of sharing future, past, present
-Presence
– hire for compatibility, culture is context context is people, understand organisational context.
– Energy
– feel time
-ownership
-positively reinforce sharing
– Your goals -> our goals
reward/incentivise colab and sharing, how? measure engagement.
– Shared goals are your compass goals are your culture, the thing direction of travel

Embrace emerging structures

– space is not a barrier, space is not as big as it used to be
there are tools to enable skype, vc units, desktop vc mobile vc

Current State:

-No opportunity for serendepity
-Closed networks
-Entropy

Trends:

-Privacy as commodity/desensitisation
-Hyper sharing
-High bandwidth communication/consumption
-Open source, social networks,
– task/problem networks

Thoughts:

There is no reason not to share
There is no impediment to sharing

appendix
valve handbook
open business cushman 90/10?

References:

http://fasterfuture.blogspot.co.uk/2012/07/the-10-principles-of-open-business.html

http://blog.ted.com/2013/01/24/why-radical-openness-is-unnerving-reshaping-and-necessary-a-qa-with-ted-ebook-authors-don-tapscott-and-anthony-d-williams/

http://www.ted.com/pages/tedbooks_library#TapscottWilliams

http://www.ted.com/talks/don_tapscott_four_principles_for_the_open_world_1.html

http://www.fastcodesign.com/1671797/from-zappos-4-simple-hacks-to-foster-office-collaboration

gore tex
http://www.gore.com/en_xx/aboutus/culture/index.html

http://www.managementexchange.com/story/innovation-democracy-wl-gores-original-management-model

http://metro.co.uk/2013/02/25/facebook-twitter-or-email-what-do-we-share-online-and-why-3508887/

http://www.noop.nl/2012/11/taking-care-of-horses.html

Categories Uncategorized

Humility and the Art of Enterprise Architecture

As a lot, Enterprise Architects are not terribly humble people.  We name frameworks after ourselves, and sometimes go to great lengths to correct the “misinterpretations” of others who describe our work in a way that we don’t agree with. 

Yet, recognizing that the field is young requires that we should be willing to change as the field of EA changes; that we should be willing to look back on our models, developed in the past, and admit that we missed a few steps that we wouldn’t miss today.

I recently had the opportunity to discuss, on LinkedIn, a blog post that I made five years ago.  I look back on that blog post and must admit that my opinions are a bit different now than they were five years ago.  I still agree with my post, but I would certainly use different words today than I used in the past.  I am more than willing to admit it. 

I also look at the efforts of Alexander Osterwalder whose Business Model Canvas has proved both practical and flawed.  He missed the fact that he needed to create a differentiation between the customer’s needs and the value proposition of the business offering to fill some of those needs.  Did he go back and create an updated canvas?  Nope.  He created a new canvas to describe demand as though it fits with his older one (hint: it’s a mess). 

The venerable John Zachman, probably one of the most humble men I’ve met, also made this same mistake.  While his original model was only a couple of columns, and was updated only a few years later into the table we see today, the field of EA has changed.  The table is no longer representative of companies with multiple business models (most of them) and the lack of a “customer” row simply relegates his “ontological table” to the dust bin. 

Neither man will change.  They have “legacy” models, with their names attached.  To paraphrase Forrest Gump, humble is as humble does.

I would like to think that my willingness to upend my EBMM and replace it periodically with new versions shows my willingness to admit that (a) I’m often wrong, and (b) I’d rather learn than become stale.  That said, I’m no paradigm of humility, myself. 

After all, a truly humble EA would not have written this blog post. 

(As my teenage daughter would say: Oh snap, you pwned yourself!)

Addressing the Multi-Dimensionality Challenge on Thinking of The Enterprise as a System

Last week I had the pleasure of attending and presenting at the Open Group conference in Newport Beach, California.  I find these conferences enlightening as I enjoyed the dialog with fellow professions who share similar point of views on the&nbsp…

Addressing the Multi-Dimensionality Challenge on Thinking of The Enterprise as a System

Last week I had the pleasure of attending and presenting at the Open Group conference in Newport Beach, California.  I find these conferences enlightening as I enjoyed the dialog with fellow professions who share similar point of views on the discipline of Enterprise Architecture.   I have made the following observations: We have a huge challenge in…

Open Work: first notes

Open Work


image

An initial sketch of ideas around the concept of ‘Open work’, a developing idea for a manifesto for a new way of working that leverages concepts around openness and technology that enables openness to enable us all to work better, together.

Other than this preamble this is a straight dump of notes i’ve been jotting down, just thought i’d get it out there on the blog as a vehicle for making myself think more deeply about what i want to achieve. My plan is to start fleshing these notes out, into principles (hey i’m an architect!) and trace these concepts to some reality. When I first started thinking about these ideas I happened upon david cushman’s great writing (http://fasterfuture.blogspot.co.uk/2012/07/the-10-principles-of-open-business.html) on the area of ‘open business’, so i’m mindful not to re-hash or at worst plagiarise David’s thoughts (you’ll notice some of my headings map to some of david’s principles.

So my plans consist of trying to frame some interesting and hopefully original thinking, whether this ends up as a post on my blog an ebook, or whatever, i’m not really sure, I’ve just got fed up of thinking things through, so thought its about time I should start, er, writing them through.

concepts/principles

-Context
-radical sharing/shariarchy
-discovery
-foster emergence
-Social architecture: (thinking stack/zachman etc)
-connectedness (connectivity and psychological sense by what? shared vision?
-finding
-serendipity
-ego-less
-embrace criticism but by embracing criticism how to avoid paralysis (too many arguments)
-Clear threshold for decision making – stops paralysis
-radical un-secrecy
-Virtual Structures
-Now-ness – relate to the when/tenses of sharing future, past, present
-Presence
– Energy

Current State:

-No opportunity for serendepity
-Closed networks
-Entropy

Trends:

-Privacy as commodity
-Hyper sharing
-High bandwidth communication/consumption

Thoughts:

There is no reason not to share
There is no impediment to sharing

Categories Uncategorized

Enterprise Architecture Roadmap for success: Adopting an open approach to Enterprise Architecture

<p style=”line-height: 18.99147605895996px;”><span style=”font-size: 11px; line-height: 19px;”>This is the fifth posting in our “EA Roadmap for success” series. In this posting we zoom in on the use of an </span><em style=”font-size: 11px; line-height: 19px;”>Open</em><span style=”font-size: 11px; line-height: 19px;”> approach to enterprise architecture.</span></p><p style=”line-height: 18.99147605895996px;”> </p><div class=”captionImage left” style=”width: 600px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600375-Enterprise-architecture-roadmap.png” alt=”Enterprise Architecture Roadmap” title=”Enterprise Architecture Roadmap” width=”600″ height=”375″/><p class=”caption”>Enterprise Architecture Roadmap</p></div><h2>Frameworks and approaches?</h2><p style=”line-height: 18.99147605895996px;”>One of the key challenges of getting started with enterprise architecture (EA) is to agree on goals for the EA practice, and subsequently to find and agree on a framework / approach / method that helps the organization to realize those goals.</p><p style=”line-height: 18.99147605895996px;”>In the early days of EA (1990’s and the early 2000’s), we saw many organizations growing their own approaches and frameworks. By working with business sponsors, architects experimented with different processes for EA, frameworks to structure EA products, modeling languages and notation and so on.</p><p style=”line-height: 18.99147605895996px;”>While this worked well in the ‘old days’, many best practices have emerged and ultimately led to the major frameworks / approaches / methods we see today: ArchiMate, TOGAF, IAF, Zachman, DYA, and so on.  Some of these are ‘general purpose’, while others (e.g. MODAF/DODAF) appear to be particularly useful in a single branch.</p><h2>Build or Adopt? Open or closed?</h2><p style=”line-height: 18.99147605895996px;”>While organizations in theory face a choice of ‘build or adopt’ where it comes to frameworks, we see that many chose the latter. With all the experiences and best practices that have been developed, most organizations realize that there is little point in re-inventing the wheel all over again.</p><p style=”line-height: 18.99147605895996px;”>The question that remains, then, is this: do we adopt an open approach, or a proprietary / closed approach?</p><p style=”line-height: 18.99147605895996px;”>This question can be answered on many different levels. One could argue that “open vs closed” doesn’t really matter, as long as the selected framework does what it is supposed to do. While this may seem true at first glance, we do believe that there is a lot to be said about principally going for an open approach. The main advantages here are as follows:</p><ul><li>Know what you will get: all details about open frameworks tend to be available in the public domain.</li><li>Choose your partners: because the frameworks are in the public domain, you’ll often be able to select which vendor can help you get started – if needed at all. Along the same lines: if the vendor doesn’t deliver what was requested, switching is easier.</li><li>Get involved: perhaps most importantly, if the framework is lacking in certain areas, organizations can often join and publish their own best practices, furthering the framework for all other users.</li></ul><h2>Adopt as-is, or tailor to specific needs?</h2><p style=”line-height: 18.99147605895996px;”>To conclude this posting: there is one more choice that organizations have to make when adopting a framework, be it an open or a closed/ proprietary one: should we adopt the framework as is, or tailor it to our needs?</p><p style=”line-height: 18.99147605895996px;”> </p><div class=”captionImage left” style=”width: 348px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/Enterprise-architecture-framework.png” alt=”Enterprise Architecture Framework” title=”Enterprise Architecture Framework” width=”348″ height=”400″/><p class=”caption”>Enterprise Architecture Framework</p></div><p style=”line-height: 18.99147605895996px;”>The best practice here is simple: pick and choose! Most approaches explicitly recommend users to tailor the framework to organizational needs. In TOGAF this is being done as part of the <em>preliminary phase</em>.  While TOGAF recommends that certain parts <em>not</em> to be skipped, it is of course entirely up to the individual organization to decide what is useful and what is not!</p><h2>Next posting</h2><p style=”line-height: 18.99147605895996px;”>If you’d like to know more, please contact the authors directly at <a title=”b.vangils@bizzdesign.com” href=”mailto:b.vangils@bizzdesign.com”>b.vangils@bizzdesign.com</a> / <a title=”s.vandijk@bizzdesign.com” href=”mailto:s.vandijk@bizzdesign.com”>s.vandijk@bizzdesign.com</a>, or leave a comment. The next post in this series covers project based implementation of EA. It is scheduled to be posted on January 29. </p>

Categories Uncategorized

Enterprise Architecture – A Perfect Tool for Operating Model Management

On this blog I have covered the discipline of Enterprise Architecture from a number of perspectives. Enterprise Architecture (EA) can be effectively leveraged as a foundation for Industry Reference Architectures e.g. The Retail Reference Architecture. Equally effectively EA can also be leveraged as the mechanism for Business and Technology Governance as well as Technology Performance Monitoring. In this article I would like to propose that Enterprise Architecture is also an effective tool for the Operating Model management, both for the definition as well as the ongoing lifecycle management. 
It may be worthwhile visiting some industry definitions for Operating Model before we explore how Enterprise Architecture can be effective here. The definition of Operating Model varies based on the Organisational and Operational context in which it is applied and hence probably one definition may not fit all Operating Model scenarios. However if I had to choose one definition, I would like to refer to the IBM’s definition of the Operating Model (see the picture below)
IBM Target Operating Model (TOM)

IBM proposes that a Target Operating Model (TOM) helps determine the best design and deployment of resources to achieve an organization’s business goals. It provides current operational maturity assessment and roadmap to defining and/or improving organisation’s Operations Strategy. Key deliverable include business review, current operating model assessment, desired future state and change management plan roadmap.
The TOM essentially is seen here as the mechanism to link the business goals and strategy of the organisation with the roadmap for change to achieve those goals. TOM then holds together various organisation concerns such as processes, technology, capabilities, customer view, governance and partners in a single cohesive fashion.
 
Now that we have briefly summarised an illustrative Operating Model definition, let us explore how Enterprise Architecture as a discipline or practice can be leveraged as a tool for its management. There are a number of good Enterprise Architecture Frameworks available for this purpose and recent revisions of certain frameworks have further established them as leading candidates for this purpose. I do not advocate or support a specific Enterprise Architecture Framework on this blog however for illustration purposes I am going to be using the TOGAF 9 as the tool for Operating Model Management. I would like to also mention the Zachman EA framework as the other leading framework which may be equally effective or in some application scenarios it may be a better fit. 
The purpose of this article is not to explain or define the TOGAF 9 and I would highly recommend visiting the OpenGroup website for relevant documentation. However for the ease of reference, I am going to share the TOGAF ADM which is the process for Enterprise Architecture Management in TOGAF. 
The process links the Vision and Strategy of the Organisation and its business / functions with a portfolio of change programs which realises this Strategy. TOGAF uses various architecture disciplines such as Business Architecture, Information Architecture (Data and Application) and Technology Architecture as mechanism for linking the Strategy with Implementation and Governance of Change programs to deliver on the Strategy. 
The central argument which I am now going to make is that such a process of Enterprise Architecture can be seamlessly deployed and leveraged to manage the Organisation Operating Model. A number of Enterprise Architecture Frameworks and especially Zachman categorically state that the application of Enterprise Architecture should not be restricted or limited to the Information Technology systems. It is a true framework for organisation and business management. For instance applying the TOGAF to manage the IBM TOM will result in following steps / mapping. The key here is to use tools, processes, approach, templates and constructs from each of the TOGAF ADM stage to define and develop the TOM stages as seen in figure – 1. 
  1. The business goals and strategy can be defined by the Preliminary phase while the vision underpinning this is defined in Phase A. Architecture Vision
  2. The Assets and the Locations of the TOM along with key processes can be captured and defined during the Phase B. Business Architecture
  3. Certain aspects of skills, capabilities, culture and processes too can be captured in Phase B
  4. The Technology, Processes, Performance Metrics can be captured through phases C and D while defining the Information and the Technology Architecture.
  5. The sourcing options and alliances can be identified and shortlisted in phase E. Opportunities and Solutions
  6. The phase F of migration planning can be used to identify the roadmap for change through what TOGAF calls as transition architectures
  7. Finally culture which is central to TOM needs to be constantly be a driving force as well as the recipient for the requirements for change
I would like to again highlight that this is simply an illustration of managing a view of Operating Model with a particular EA approach. However a number of other variations can be equally effectively managed by similar approach. It will probably make sense to present an illustration and mapping using other EA framework such as Zachman…may be a topic for next post on this blog!

References:

Strategy and transformation for a complex world, IBM Global Services, Mar 2011

The TOGAF Architecture Development Method (ADM)

The Zachman Framework