Problems of Togaf9 PART 1
Growing success of Togaf9 and so many people being so happy with it proves the immaturity of enterprise architecting (EA). However, it’s good that enterprise architecting is slowly being recognized as something important all organizations should do. Moreover, it should be noted that I personally believe that information modeling and I mean MODELING not just defining terminology should be core activity of any EA program. Unfortunately, the lack of this knowledge becomes apparent in most information modeling exercises and industry initiatives like Togaf9.
Let’s look at the major problems with it: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap34.html (figure 34-8)
MAJOR PROBLEM 1: What actually drives what?
Information and process are like “chicken and egg”. But I personally believe that at least structured processes should not be designed before information (inputs and outputs) are first defined in DETAIL! Why? Because how can I decide what is the most EFFICIENT and EFFECTIVE way to set-up the organization to produce (process) value out of the resources (raw material, tools and people) if I do not know what is the product functionality (or Service) and its desired quality attributes.
SOLUTION: Product information represents the core of any organization and therefore it is the center and the starting point to everything.
MAJOR PROBLEM 2:
If product is the core or any organization then what is closely linked with it? Contracts! CONTRACTS with customers, CONTRACTS with partners and suppliers, CONTRACTS with authorities and LAWS (are contracts by the way). So if product is luckily found in Togaf9 (although not in the role it should be) contracts are missing! Contract in Togaf9 has nothing to do with “my contract” but comes from the history of “IT SLAs”. These SLAs are more to do with “process SLAs” linked with IT term “Business Service”.
SOLUTION: Contracts represent the business model view of the organization whereas products are the “production” side of the coin. And there is more missing following the same logic. Where is Customership? Probably not so important (but more on that later)!
So, what I am trying to say. That Information is not just “Data entity” but it defines the whole logic of what should be achieved and therefore requirements for what and how things are done. In other words how processes and their capabilities should be designed.
And by the way, what is this nonsense of “business architecture” and “business service”! My friend Wikipedia states:
The etymology of "business" relates to the state of being busy either as an individual or society as a whole, doing commercially viable and profitable work.Wikipedia
As an wannabe enterprise architect or at least wanting to comment on the topic, everything is about business so let us drop that word out of the this context because it provides zero value. Moreover, it seems like IT people think that they have understood “business logic” by having this word in their vocabulary. Unfortunately not!