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.