In Butterfly Manifesto we looked at the Butterfly paradigm, in this blog we look at usage.

Enterprise Architecture provides an organisation with the capability to link strategic concepts with each part of the Architecture to drive change and understand problems. Structured Linkage is needed to map each part with the overall Goals that they serve:

• Business Vision identifies Goals that the business is trying to achieve, and the Capabilities that are needed to realise that Vision.

• Business Architecture identifies Services, Functions and Processes needed to realise the Capabilities.

• Systems Architecture identifies the applications systems and use-cases needed for the Business {Services, Functions, Processes}.

• Technology Architecture identifies the Platforms (hardware and software) needed to host the Applications, and manage their growth and resilience.

• Throughout the process functional and non-function requirements are identified in a catalogue to track needs.

… That’s the theory, in practice it is more common for vision to be derived from customer experiences, environmental or regulatory change. When the Vision is not created from strategic review, it is more common for Business Architecture to be generated to find sponsors for Systems Architecture. Irrespective of the driver {Business, Systems, Technology} Architecture evolves in parallel at the same time, but cannot always be reconciled.

Butterfly and Agile Enterprise Architecture

Butterfly takes the view that the most important knowledge is that concepts are related rather than how they are related. This might suggest that Architecture can be dispensed with (especially when Business Architecture is treated as an ephemeral stage), but instead structure can reduce overall effort.

In this example trace relationships can be drawn through the Architecture life-cycle to map a Goal to a Change, but in practice it is rarely done because the effort cost might be higher than the insight value. You wouldn’t conduct an enterprise traceability study answer

What proportion of our change programme and cost relates to strategic goals, rather than legacy renewal?

You might notice that the Business-Service/Function/Process step is missing from the diagram – possibly because

• Non-Functional requirement
• Defined by a client
• Regulatory
• Function is being restructured
• Simply that the stage was skipped.

It does not matter whether the Goal and Change are linked by business function (or not), but whether the change is Goal or Legacy driven.

Historically Graph Database have been used to reduce the mismatch problem, but query (join) complexity is replaced by tool complexity and bespoke integration.

Butterfly does not transform the business model into a graph database, but uses a simple (SQL-like) script to define how information is related when needed.

create butterfly Traceably;
create node Goal source ("ArchiMate_Goal");
create node Capability source ("ArchiMate_Capability");
create node Requirement source ("ArchiMate_Requirement", Requirement");
create node UseCase source ("UseCase");
create node Application source ("ArchiMate_Application", "Component");
create node Change source ("ArchiMate_CourseOfAction", "Change");
create path Trace
	from ( Goal, Capability, Requirement, UseCase, Application, Component )
	to ( Capability, Requirement, UseCase, Application, Component, Change )
	source ( "TraceFrom", "RealizeFrom", "Parent" );

If association relationships are used instead of trace in one business area the definition script can be changed to include Association in addition to TraceFrom and the view refreshed.

Ray Tracing

Until recently a graph database with specialist loading/transformation would be needed for the recursive queries, but the application of ray-tracing techniques and GPGPU technology renders intermediate stores superfluous.