Interfaces

I am often asked what the right way to record interfaces is. The answer is really that it depends what you want to know about the interfaces and that in practice you will probably want to record information at a number of levels

Let us examine another communications paradigm we are all familiar with – Bill communicating with Bob.

Should one record that:

1. Bill Communicates with Bob (remember communication may be multimodal)

2. Bill makes sounds with his mouth that Bob hears through his ears (and similar for other modes with different input and output interfaces).

3. Bill makes sounds that are communicated via a medium (e.g. air), or converted into electrical signals and transmitted via an electrical cable, to a switching mechanism etc.

See diagrams of three example options below

There are a myriad of other strategies e.g. Bill communicates with clients (and Bob is a client); or Bob's brain interprets the sounds and hears the words and emotional content, etc. Then there are the issues associated with the semantic content of the message e.g. do we want to record that Bill is communicating about Products, Pricing or whatever

Well it really depends on what we are trying to understand – if we want to understand communications flows in a organistion, or if we are designing a phone etc. It make be useful for different purposes and audiences to record this at many levels and to be able to relate these different views together.

Unsurprisingly the same is true when one considers who to record communications between applications. The way you record them varies based on the purpose. They may be recorded in multiple ways and it is very handy to be able have a way of see how all the different levels are related. But searching in vain for a single way of recording interfaces that will serve all audiences and all purposes is unlikely to be productive.

Traditional processes and EVP no good for EA

Even Microsoft is now saying "Traditional enterprise architecture processes do not work" (said by Gabriel Morgan, principal enterprise architect of Microsoft 10 days ago). He also said other things we have said for a long time e.g.

- "We have to prove IT’s value to deliver that market position"

- "We cannot develop a sustainable target architecture if we don’t know where we are"

So perhaps EAs will one day listen and stop doing what they have done i.e. using Excel, Visio and Powerpoint to try and do EA and look at what is actually required.

Dealing with complexity

I think this presentation indicates how useful visualisation are in dealing with complexity.

http://www.ted.com/talks/eric_berlow_how_complexity_leads_to_simplicity.html

It mentions that it is important to set back and embrace complexity, and then look at issues in context.

It also demonstrates how dynamic visualisations can be powerful in analysis where one can selectively hide, decompose etc. the views. And to my mind why static crafted hardcopy reports will often struggle to allow us to examine new issues that arise, and what-if analysis i.e. it is the ability to interactively explore the data from many perspectives that is critical to the insights.

It is only by understanding how to deal with complexity effectively and good using solutions and tools to deal with it are we going to get any better at making strategic transformation or optimisations of the increasingly complex systems that are large enterprises.