The efforts spent on definitions

Definitions are attention-seekers. And good ones. They get much more attention than they deserve.

I’ve just read a post by Nick Malik called Many (flawed) Definitions of Business Architecture. There he does a very good job of analysing the existing definitions of Business Architecture. He comes to the conclusion that all of them need to be improved, including his own one.

Tom Graves recently wrote about the Meaning of process. In my comment I asked why do we need to agree on a process definition. For similar reasons I doubt that we need to spend too much efforts on arriving at a better definition of Business Architecture.

Would a better definition, being some-body’s statement or many-body’s convention, make a definition-compliant Business Architecture better? Would making Business Architecture better make the business better? The business may get better without a good Business Architecture and having a good one would not necessarily make it better. Quite similar reasoning applies for definitions. You can have a good Business Architecture with a wrong definition and vice versa.

Nick Malik listed and categorised 20 definitions of Business Architecture. The fact that they are so many speaks about the amount of efforts spent on them including – on discussing them. Not that I’m not tempted as well. Especially by some of them. Let’s quickly check for example the definition of TOGAF, starting not with the explicit statement, but the implicit meaning taken from the TOGAF content. (Here I go, could not resist) If something belongs to Business Architecture domain, it doesn’t belong to Application Architecture, unless I’m misreading something. For example applications are not part of the Business Architecture. Well, if we strip down the Architecture dress, applications does not belong to the business. Although the business paid for them. Nice. Business is practicing Aparigraha. I’m all for.

If the business is split into social and technical part, then applications would rather be in the technical, than in the social. That I can understand. But when we distinguish business and application domain… Or maybe when ‘business’ is used as adjective for architecture, things are different? Anyway, it seems that in some contexts this type of abstraction works. Or at least I hope so, otherwise why so many smart people are following TOGAF? Still, some deductions from the Architecture of TOGAF makes it not very reliable tool for the Architecture of the Enterprise.

If we take the explicit definition itself, things get even worse: “The Business Architecture defines the business strategy, governance, organization, and key business processes.” Business architecture does not define strategy, people define strategy. It might be that there are models used to support the strategy and these models are classified as belonging to Business Architecture. But that doesn’t help the statement make more sense.

Now again back to content, there is very little mentioned about strategy in the TOGAF Architecture Development Method, although it deals with Business Architecture to support the claim that it is Enterprise- and not IT-architecture framework. Then in the Architecture Content Framework, things such as driver, goal, objective and measure appear (recently!) in something called ‘Motivation Extension’. Isn’t it odd to have goals and drivers in an extension? Shouldn’t we rather place them in a… more central place?

May be it’s better to determine things by their relation with other things, such as relating talk with walk (the above example refers), model with reality, common with sense…

On the other hand definitions are important. They really are. Also – a bit less though – in the areas such as Enterprise Architecture. It’s just that spending too much efforts on them often has high opportunity cost.

7 thoughts on “The efforts spent on definitions

  1. Ivo, many thanks for pointing to my post ‘The meaning of process’.

    The ‘definitions problem’ – the amount of hot-air apparently wasted on arguments about definitions – is an inherent outcome of the otherwise very useful fact that people view things in different ways and from different directions.

    Yes, it’s an overhead, yet a very necessary one. If we don’t get clarity on definitions, we end up with disasters like that of Mars Climate Orbiter, where one team used ‘English’ (US aerospace-engineering) units whilst another used more general metric-units, and things got a bit confused when they tried to put the space-probe into orbit around Mars… (see NASA-JPL, ‘Mars Climate Orbiter Team finds likely cause of loss‘).

    Bruce Tuckman’s ‘Group Dynamics‘ project-lifecycle sequence (forming, storming,norming, performing, adjourning) is useful here. We need to gain clarity on definitions, success-criteria, principles, roles and all manner of other definitional matters in the Storming phase, before we go on to the plan in the Norming phase, and especially before we go to action in the Performing phase. If we try to rush straight to the ‘doing’ without sorting these issues out first, we all but guarantee to set ourselves up for failure.

    The real catch is that the Taylorist view of business doesn’t really recognise people as people, hence can’t see why this type of (often heated – hence ‘Storming’) discussion really is necessary – and then wonders why things suddenly fall apart ‘without warning’ in the middle of the action.

    You’re right in that we do need to get out of the Storming phase at some point, though! If we’re so busy arguing about fine points of detail that we never do get to the point of action, there’s not much point in having those arguments in the first place… :-) (Though there’s also the reality that one of the drivers behind continuing the arguments is to avoid actually doing any ‘real work’! :wry-grin: )

    “Isn’t it odd [in TOGAF] to have goals and drivers in an extension? Shouldn’t we rather place them in a… more central place?”

    Well, yes, exactly. Hmm… :-)

    • “there’s also the reality that one of the drivers behind continuing the arguments is to avoid actually doing any ‘real work’!”

      Agree. But it’s rather done by good sense-making than by good definition-making.

      • The process of definition-making is sensemaking; a significant part of the process of sensemaking is definition-making.

        They’re very tightly interwoven. “What is this thing? What does it mean? How can I describe it? How can I describe it to others?” -it’s both sensemaking and decision-making.

  2. Great post and the difference between sense-making and definition-making is an important one.

    When I was in my high school debating club, I always remember my coach teaching us that defining the words in the proposition set the boundaries of the argument and often determined the winner. This tactic is so established that there are actually rules to govern it:

    Why is this important?

    In a lot of instance, all the definition-making seems driven by a need to rationalise the facts into a predefined world view. This is often about being right, than furthering understanding.

    In an actual organisation, I think the key is the culture of the people. In an environment of trust then small variances in the meaning of words will be forgiven and the debating of definition is impeding progress. Without trust, then you are essentially negotiating a contract so it is right and proper that we should all debate definitions. To save time, we should get the lawyers in the room to help us.

    Perhaps, more seriously, the actual meaning of words like ‘process’ and ‘business architecture’ can only arise out of doing the work which creates the meaning. Starting with the definitions is rarely fruitful since people don’t understand their bias or usage until they are exposed to other people’s interpretations. In this context, definitions are more important retrospectively as a way to crystallise the shared understanding the work creates.

    Thoughts on that?

  3. Hi Ivo, thank you for linking to my blog post and commenting on it. You are right in that definition activities don’t build good architectures… But they can help new people learn about an idea. That is what led me to do the work. I was preparing a session for the Microsoft Tech Ed conference that took place last week in Auckland New Zealand.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.