In science or in research, you experiment and find out new ways to fail, until it works. For some architects, this is very much like the efforts in their organizations.

There is not a common way of working and the approach is more or less ad-hoc inspired. Hopefully there is one or more architects with prior experience from some kind of process, but it's not accepted by all architects. We as architects are very much individuals, do you agree?

So what to do then? What if we should describe business processes for others, how do we do this?

A top-bottom approach is to look at a high level process and then break it down to sub processes with input and output from the sub-processes. Each of the subprocesses could further be decomposed into activities.

For each activity, you could specify the role that is doing this activity. Do you agree that this is a good approach?

Next, the recommendation we always give to our customers is "don't re-invent the wheel". If we apply this to ourself, what does this mean?

TOGAF ADM is a widely accepted best-practice for architecture development and thus a good candidate for a business process framework for us architects.

But we are unique will somebody tell you. How does this differ from the situation where our clients say that their organization is unique.

What is our architecture principles? Is it re-use before buy, buy before develop or is it don't use if not invented here? Probably the former than the latter.

When the model isn't good enough or doesn't cover everything, make your on add-ons. do not develop a totally new framework.

Third, choose wisely what you need from the model to solve your problem. Don't implement all pages in the TOGAF book at once, unless you really need it. Then, adapt the framework to the governance model you have chosen in the previous step.

Quite simple, if you have done it before. If not, you are experimenting and working with research.

Disruptive architecture