Mirafor Blog

Problems of Togaf9 Part 2

Wed, 22 Feb 2012 13:46:33 GMT

Problems of Togaf9 Part 2

I have received lots of criticism being critical about TOGAF. Great! Major comment has been that one needs not to use it as such but take the best or suitable parts for whatever is the need. Let us think about that for a moment!

TOGAF9 Introduction states:

TOGAF Says: TOGAF is a framework - a detailed method and a set of supporting tools - for developing an enterprise architecture. It may be used freely by any organization wishing to develop an enterprise architecture for use within that organization.

Mirafor wonders: Detailed method for developing enterprise architecture! I assume that detailed method means that it is supposed to be also logical. Or is it so that method is always logical by nature. Hmm…based on what proven theory?

TOGAF Says: The purpose of enterprise architecture is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy

Mirafor wonders: This means that it is process development only! Or have I missed something? Which comes first process or information? Or is it so that strategy is information developed by strategy process. Is then strategy process improvement responsibility of enterprise architecture? Did I say enterprise architecture process…? We are confused what is process and what is information.

OK…let us move to Part IV of the TOGAF to get clarification….

…And Togaf9 Part IV states in overview:

“The TOGAF Architecture Development Method (ADM) provides a process lifecycle to create and manage architectures within an enterprise. At each phase within the ADM, a discussion of inputs, outputs, and steps describes a number of architectural work products or artifacts, such as process and application. The content metamodel provided here defines a formal structure for these terms to ensure consistency within the ADM and also to provide guidance for organizations that wish to implement their architecture within an architecture tool.”

“TOGAF Says: At each phase within the ADM, a discussion of inputs, outputs, and steps describes a number of architectural work products or artifacts, such as process and application”

Mirafor wonders: Are “inputs and outputs” information? Do “steps” mean process “tasks”? Do “architectural work products or artifacts” mean information about them since we are not developing the actual “physical products” at this point? Ooh…sorry…I stopped reading too early…it continues “such as process and application”.

Mirafor conclusion: So it seems that TOGAF is a process for developing processes. Moreover, its process for describing processes. I think there is quite many of those already.

I am just still wondering if an enterprise is nothing but a process?

Even if enterprise is nothing but a process then should it not be information model about enterprise process?

Information model about the “universal artifacts” or just a “class model?”

I admit that I am confused trying to understand! My feeling is that so are many others.

Problems of Togaf9 PART 1

Tue, 29 Nov 2011 09:20:35 GMT

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!

Information Architecture Missing!

Thu, 21 Apr 2011 07:04:10 GMT

Tekes – the Finnish Funding Agency for Technology and Innovation conducted a research (PDF 1.0mb) about state of the enterprise architecture within 25 large Finnish companies. The result was both interesting and sad at the same time! Information architecture was mostly missing from these organizations. How is it possible? Don’t we need information architecture?

I believe that information architecture is the most important task of any enterprise or IT architecture work. I could not design requirements for any application without solid information architecture. Too much emphasis is put on process architecture with the cost of neglecting information architecture. Why? Is it because of lack of understanding?

People find process design “easy” compared to information design. Typically, during requirements collection phase we ask 1) “what” are you doing 2) “how” are you doing it and 3) “with what” are you doing it. However, we should also get to the questions of 4) “what do you need for doing it (inputs)” 5) “what is the expected output” and 6) “what are the output quality metrics”!

Even if all the above questions are answered we have just completed the “requirements list” part of the problem. This is where the hard stuff starts! Here most projects fail! Why?

Information has its own structure which processes do not “expose”. If we only look at information through processes we do not see the structure of the information. So, what defines the structure of the information? For example “contract” information structure is defined by law. This means that there is nothing “technical” about contract information model. Who should then be responsible for modeling it? We argue that business people should be modeling it, but the problem is they do not have methods or experience to do it. Stuck? Not yet!

The answer is to have experienced information modelers who understand information relationships in depth! Typically, most information best practice initiatives only get to the point of understanding main domains of enterprise information model and the key relationships between them. However, there is far more information exchange use cases between processes than what typically appears at first. The problem with most master data management programs is that they concentrate “mapping” information between applications to align terminology. However, they do not get to the point of creating structure of the information. Why the structure is so important?

Structure of the information is important because it 1) it covers the relationships between information 2) it helps to create common terminology 3) it exposes the nature of the information. This last point is crucial. By understanding nature of the information, we can categorize information better and find commonalities of information. Let’s take an example. Service Level Agreement, software license, invoicing policies and account are all types of contracts. They have very similar information and information structure between them. WE CAN SAVE LOTS OF MONEY in understanding this nature of information and by investing a lot less for managing this information.

Remember that applications are either storing information or processing it. The more we understand about our information models the more we will save money by buying more fitting software, integrating less systems and designing better use cases.