I was recently asked to review a paper lodged with Academia.edu which discussed the Quality Attributes of Enterprise Architecture Models. Its scope was bounded by the traditional concept of model, as produced by tools such as Archimate.

I commented that this approach restricted the audience to the architectural and technical and omitted business stakeholders. I proposed a view of a “model” from a different perspective, which I reproduce below. I’d be interested in feedback (good or bad!)

The Oxford Dictionary definition of “model” or “models”: 1) “a three-dimensional representation of a person or thing or of a proposed structure, typically on a smaller scale than the original.” 2) “a thing used as an example to follow or imitate “the project became a model for other schemes”” 3) “a particular design or version of a product

“the company revealed their latest model at the Motor Show”” 4) “devise a representation, especially a mathematical one, of (a phenomenon or system) “a computer program that can model the behaviour of smoke””

All of the above (except 4) envisage something that is 3-dimensional, tangible, and (to a greater or lesser extent) operational. Even definition 4 states a requirement for some level of dynamism – “behaviour.”

When I was young, the father of one of my school pals was manager of the “Model Department” in the local shipyard. He gave me a tour of the department. In it there was a huge physical, scale mock-up of a Command Cruiser (HMS Sheffield, which was sunk in the Falklands war.) This allowed the designers (draughtsmen) to take into account spatial and operational considerations – for example, as a Command Cruiser, the Sheffield had thousands of miles of thick (sometimes 0.5 metre in diameter) cable trunking – it was difficult to imagine how much leeway was required to bend these cables around bulkheads without damaging the connectivity of the copper threads inside the cable. Similarly, when the shipyard built commercial ships before it started to specialise in naval vessels, it allowed designers to understand the customer experience of life onboard during their voyage.

This is an approach I have used with regard to enterprise architecture – I identify Capabilities, Value Streams and document the required Business Outcomes; define Vision, Principles, Policies, core Semantic definitions, Technical & Design Standards. I then set about building a Model – a Model Office, Model Branch, Model Shop whatever – using Cloud Technology. I do this at first in my own office as a very crude mock-up, then build it on the client’s premises where stakeholders (senior and end-users) can use it (based on Use Cases of core activities that I gathered during the initial research.) Another essential preliminary exercise is the definition of business-significant services and how they can be isolated in a classic SOA manner

I have used this approach successfully for both enterprise-wide digital transformation and for individual enterprise solutions, in both the product selection phase and the solution design phase.

Key benefits are that:

– As the Model is cloud-based (either hybrid or pure-cloud), it can be used as the basis for the roll-out of the live system and simply scaled as required

– Business stakeholders can assure themselves that their required outcomes will be delivered without specifying requirements that simply re-build the “old” system

– When used with SaaS it encourages configuration rather than customisation, which has many benefits

– I have also recently used this approach with Low-Code / No-code methods if SaaS is not appropriate

– Architecture is dragged out of its ivory tower and starts to be viewed as a real asset (I have never been interested in “Architecture for Architecture’s sake.”)

In terms of the research which backs up the above, I’d point to my experience at several clients, and the fact that the concept of a Model Office has been adopted by the UK Government Digital Service (GDS) and used at HMRC and National Audit Office (as far as I am aware of – I am sure it has been used in various other places.) Going further back, it has been standard practice for decades for Financial Services organisations to have a Model Branch and / or a Model Office (albeit without the cloud component) – usually for end-user testing.

I have found that business stakeholders view a ppt deck with bullet points (which has been the traditional mechanism of communication with senior stakeholders) as a poor second choice, but often a choice for which they have no other option. They would rather see and experience what I have outlined.