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 we need to agree on a process definition. For similar reasons, I doubt that we need to spend too much effort 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 to 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 there are so many speaks about the amount of effort 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, I could not resist) If something belongs to the 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 do not belong to the business. Although the business paid for them. Nice. Business is practising Aparigraha. I’m all for.

If the business is split into social and technical parts, 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 an adjective for architecture, things are different? Anyway, it seems that this type of abstraction works in some contexts. Or at least I hope so, otherwise why so many smart people are following TOGAF? Still, some deductions from the Architecture of TOGAF make it not a 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 an Enterprise- and not an 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?

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

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