Considering a near real-time ADM process

I’m still chasing that elusive real-time window, can’t seem to give it up. This is the latest visual thinking I have on it, bringing together ideas from more than 22 frameworks.

I don’t guarantee any failure arising from the usage of the indicated knowledge presented in any or all the pixels shown below. I certainly make no guarantee of validity or fit for purpose to any usage whatsoever.

I do however guarantee a different experience than using any standardized ADM would give.

Depicting the ADM as it is married with other powerful thinkings
A near real-time ADM process

I’ve had some comments and questions asked regarding what happens in the different circles, so I thought I’d try to answer that by listing my thoughts on the subject. I’ll use the names of the circles as reference to them so that the text will be easier to connect to the illustration above. Remember however that this is work in progress for me so I’ll just as likely change the name as the meaning of any one thing.

Considering the RT ADM

I separated the strategical and operational perspectives from each other because they usually execute on different time cycles. Another reason for the division is that the operational perspective is more drawn towards the solutions domain whereas the strategical perspective is more drawn towards the architecture domain. The only item left is the requirements part which in this case was named requirements as an allowance to my experiences with TOGAF. I guess the requirements area could better be named repository which would fit the notion of “orientation” as being the act of analyzing the data in the repository.

Tom has in his comments to the original post made many fine assumptions. Although I’m not sure we say or mean exactly the same thing it is of lesser importance. What is good is that he by just thinking about the pattern displayed through the illustration could use that insight to create his own version of this system.

The yellow circles are heavily inspired by the OODA Loop as devised by John Boyd. I know I’ve written about this before on my blog (link to post) but I’ll cut the text in here and add some edits so the reader doesn’t have to open up that old link for any other reason then to view an illustration of the original OODA loop.

To make it a bit easier on the people we could assume that the loop speed would start with monthly iterations, then we could go down to every fortnight and after that every week and after that every other day ending with every day. The aim would off course be to do the loop instantaneously.

As part of our normal work routine we should enter data, updating the organizations repository with information about every change we came into contact with. The “All” in this case is all levels in the organization, definitely not just architects.

Continuously the data in the repository would be analyzed, by the architects and all the other stakeholders.

Each cycle a decision to create new releases of the repository matching the outcome of the orientation would be taken. The goal obviously would be to drive this so far that no single decision has to be taken.

Each cycle updated information would be made available to act upon. As an example, directives with detailed instructions could be made available to ongoing projects. Another example could be giving updated information about the state of our business models to customer, partners and employees so they can act accordingly to the organizations intentions with the enterprise at hand.

What would we have won over the common best practice

  • Organizational trust in the architecture of the enterprise since all could be participants in its creation and continuous expansion according to the skills given.
  • An ever updated enterprise architecture since we all could work on it continuously.
  • We’ve added the promise of an agile capability to the whole enterprise not just single projects
  • You could start this work anywhere on almost any budget.

One thought on “Considering a near real-time ADM process

  1. Nice.

    (Would also be nice to see more of the detail, but that’s another story – and a long one at that! :-) )

    What are your reasons for having Architecture and Solutions outside of the real-time loop? My guess from your diagram is as follows:

    – Architecture is not part of real-time because it is the background ‘core ideas’ that do not change (timelessness vs real-time)

    – Solution is not part of real-time because it is a longer-term plan for change from ‘here’ to ‘there’ (wave [movement in time] vs particle [now])

    I also assume that, as in TOGAF, ‘Requirements’ actually needs to be a much richer set of repositories, including requirements, issues/risks/opportunities, dispensations, and glossary/thesaurus.

    Is there a specific cycle to Orient / Decide / Act / Observe, or can it go either way? (BTW, it’s a strong fit to the Complex domain in the Cynefin model: Probe > Sense > Respond)

    Looking good, anyway – keen to see where you take this next.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s