Different languages and models for different purposes

Organisations, and individuals, operate in certain ways and the assets owned and used (we could choose to call these things their business architecture and their technology architecture). They need to manage and maintain their various assets to minimise e.g. cost, risk, etc. To manage these portfolios of things effectively they need to know what they are and if there are many of them be able to analyse them effectively.

They also have demands to change and make things better (i.e. transform and optimise). These demands necessarily relate to how they operate (i.e. changes to how they operate) and own (i.e. changes to what they own and use).

When an initiative(s) (e.g. a project) is put in place these demands are expressed as requirements and for a period a abstract view of future assets is described in designs and the elements of solutions (and how they relate). These requirements and designs are transitory, and specifically the level of detail they go to are transitory. They need to be able to relate to existing assets and ways of operating so the exact affect of desire change is clear.

When the initiative(s) are complete these requirements and solutions effectively cease to exist in the transition form used in the transition. At the end of the initiative and what remains are way things are done and the assets owned and used.

This sounds facile, why does this matter?

 It matters because we need to understand that we need to be able to manage:
a) the business and technology architecture
b) be able to define requirements and designs in the context of the business and technology architectures.
c) that we may used different models and languages for describing things e.g. we may use a different language, terms and concepts when we design a building vs when we own, used and operate a building.

I use the analogy of a building above because the average person is more familiar with a building and because therefore less easily mislead (as Dawkins's law of obscurantism is rife in IT). The reality is that designers need design languages and details to perform transitions e.g. Archimate is really a design language i.e. it is not oriented at the management of large sets of assets or holding comprehensive views of how business operate i.e. the business or technology architecture - but it needs to be to relate to these. Just as an architect needs to be able to relate his designs to the level held in the town plan and the property managers portfolio view - but his design views are not town plans - and different languages and models may be used.

Further - to summarise what I said here (http://enterprisesto.blogspot.com/2013/10/what-is-ea-and-what-is-epm.html)

Royal of Academy of Engineering and British Computer Society identified:

• "there is a broad reluctance to accept that complex IT projects have many similarities with major engineering projects and would benefit from greater application of well established engineering and project management ..."
• "a striking proportion of ... difficulties stem from people ... failing to implement known best practice. This can be ascribed to the general absence of collective professionalism in the IT industry..."
• "...  problems relate to the people and processes but further in developments in methods and tools is required to support the design and delivery ..."

No one it their right mind would suggest that the same tooling, modelling and language for:

• Portfolio Management - is not about design (it is about economics).
• Planning - is not about design either. it is about having view of the future at different points in time and mapping out, usually broadly, how to get make these views reality.
• Standards Management - is not about design of any specific solution it is about saying what we should build with and how we should assemble
• Enterprise Architecture - is about the design of enterprise and has fluid relationships to the extant, but it is not about design solutions or engineering.
• Solution Architecture - is about design, though not really about detailed engineering or construction and need to apply languages like Archimate.
• Software Engineering and  Systems engineering - are about design and need to apply languages like UML.

See also http://ea-in-anz.blogspot.co.nz/2007/09/ea-and-analogies-with-built-environment.html

Inferring purpose from artefact

I am often presented with an artefact that is has been created at some stage to address some problem. Inferring the purpose of the artefact can be difficult. What is amazing is that often the people creating artefacts have only vaguest idea of its purpose e.g. for whom, to do what, when, why etc.

It is a bit like someone showing you Stone Henge and expecting you to know its function is to tell the time.

And you are meant to work out they want to tell time.

Or being shown an ancient Pesian bowl and expecting to know they want to tell time

Or being presented with a grand a complication and being expected to know its function is similar to the above.

And you are meant to work out that they want a chime on the quarter hour.

In all cases they may really want something else entirely e.g. they may want a ceremonial assembly point, a lovely ceramic or a beautiful items of jewellery. The real point is that it is very difficult to infer purpose from an entity.

So you need to try and look as clearly as you can at what you want to achieve, rather than assuming what is wanted is a replacement for a current artefact.

http://enterprisesto.blogspot.com/2013/08/technology-architects-need-to-realize.html
http://enterprisesto.blogspot.com/2010/03/artifacts-vs-business-results.html