Category Archives: Blog

Information and Data Architecture

Are these the same things, are they maybe similar, or are they truly different?  If they are different, then what is the difference and how should they be treated from an architecture practice point of view?

Within your company do you have data architecture or information architecture? Should you have one,  both, or maybe neither?

Like me, I am sure that for many of you these question have come up over and over again.  Let’s take a look at each and see how they are defined and what the difference is.  Then you will be better placed to decide what they mean to you and your organisation.

There are a number of quite useful definitions on the Internet.  The first port of call for me was DAMA,  and for those not familiar with DAMA it is an International non-profit, vendor-independent, global association of technical and business professionals dedicated to advancing the concepts and practices of information and data management.  DAMA’s first chapter was founded in 1980 in Los Angeles – sadly, we don’t have any New Zealand chapters as yet so if you are interested please give me a shout!   There are other great sources that I have also referenced and used in the discussion below, all well worth reading.

Information Architecture

Information, according to DAMA, is:

“data in context. Without context, data is meaningless; we create meaningful information by interpreting the context around data… The resulting information then guides our decisions.”

A white paper by the State Department of Public Works in Queensland, Australia on Information Architecture, asserts:

“Information is any collection of data that is processed, analyzed, interpreted, organized, classified or communicated in order to serve a useful purpose, present facts or represent knowledge in any medium or form.  This includes presentation in electronic (digital), print, audio, video, image, graphical, cartographic, physical sample, textual, or numerical form.”

They go on to say that:

“Information architecture is the means of providing a structured description of an enterprise’s information, the relationship of this information to business requirements and processes, applications and technology, and the processes and rules which govern it.”

This tells us that when looking at Information Architecture it is concerned with the relationships of knowledge, information, and, yes, data, from any source that is relevant and useful to the business.

As an architectural domain I think that perhaps information architecture is an often misunderstood domain, it is something that sits logically between the business and application domains and provides that oh so  important connection between business processes, applications and the data that is used by an organisation.  One of the key problems with this misunderstanding is the fact that the term “information architecture” was adopted by the web development industry to refer to the way in which web content is designed and structured.   Information Architecture is not just about sitemaps and  wireframes, and although ontologies and taxonomies are created and used extensively this is done as a way  to determine the meaning of information  and how information relates, so that technologies can be identified or created to support working with the information in a meaningful way.

Data Architecture

The DAMA definition of data is as follows::

“[Data] is the representation of facts as text, numbers, graphics, images, sound or video.”

Data architecture is:

“composed of models, policies, rules or standards that govern which data is collected, and how it is stored, arranged, integrated, and put to use in data systems and in organizations.” (Business Dictionary)

Data architecture is concerned with gathering and storing the data. Knowing the source and its use, the data architect is focussed on selecting the best technologies to move and store the data to ensure its availability and integrity for business use.

A 2011 Sybase white paper “What’s In YOUR Architecture?,” depicts a five-level pyramid of “domains of enterprise architecture.”

The figure starts at the top with Business and descends through Information, Applications, Data, and Technology. This paper defines Information Architecture as “a holistic view on the flow of information in an enterprise, including the effects of the processes that act upon the data.”

Data Architecture is defined as describing the way data will be processed and stored; how the data flows,  the data models (conceptual, logical, physical, and dimensional).and is predominantly used by solutions teams,  “Data Architecture (DA) is a component of Information Architecture, and is concerned with the design and use of data in structured formats such as databases and file systems. A data architect models the data in stages (conceptual, logical and physical) and must relate the data to each process that consumes (uses) that data.”

David Loshin and Charles Roe “The Utilization of Information Architecture at the Enterprise Level 2013”; assert that “Information is data put into action. Where a specific data element may exist on a server somewhere in one format or another, it has lesser business value until it is integrated with other data elements into an information package. Information is data with context. So where Data Architecture is necessary to contain and organize the manifold data resources into a manageable system, Information Architecture is necessary to combine those resources into a structure that allows the dissemination of that information to be captured, shared, analysed, utilised, and governed throughout an enterprise, across all lines of business, within all departments, with confidence and reliability.”

Chris Aitkin (from EA) summarises very well in stating that  “Information architecture provides the means to view and categorise the information required to support and enable business processes. By understanding its alignment with process we can begin to identify the value of the information and how critical it is to a business. In this way information architecture provides a means to scope and prioritise activities like master data management, application portfolio management, and data warehousing. “ How data are physically structured and managed is the business of data architecture and the discipline of data management.”

From these definitions it seems obvious  that  information architecture is something much broader in scope than data architecture, and  that Information Architecture is a set of tasks and procedures that are more strategic in their nature than Data Architecture:

Information and Data in the EA Practice

How then should we manage these two separate but related architecture domains? As two distinct architecture domains or as a specialisation of one or the other? The descriptions show us that the two do have a connection, but they are recognisably different in nature and each one addresses a specific set of concerns for a particular stakeholder community. Information architecture today covers a broad spectrum of interrelated disciplines such as master data management, data warehousing, business intelligence, enterprise information integration and many more whereas data architecture is more focused towards an application (e.g. CRM, ERP) and concerned with structured data and the more technical aspects of applications and database design.  Each domain provides a perspective on making information more usable and valuable and they leverage approaches and principles of the other.

From an EA practice perspective it may work better to keep them together, and to have data architecture as an area of specialisation within information architecture (management). This will enable the information “master plan” to establish the longer term blueprints that will allow for the development of an integrated and useable information ecosystem. The creation of the information ecosystem needs architects that can attend to all aspects of data and information. If treated as completely separate domains then we run the risk of things being considered in a vacuum without regard to the wider information ecosystem, or the needs of the organisation.

Whatever route you choose however, will be dependant on having a clear understanding of your organisation and the environment in which it operates, the maturity of the EA practice, and the availability and capability of required resources and skillsets. From a skillset and perspective it would be worth exploring a “day in the life of” information and data architects alike to help determine the focus areas for your given organisation. Ultimately, It is the responsibility of the EA practice to determine the most effective way to fulfil the mandate of each.

Amanda Parkes, Senior Consultant Architect at Cyma Limited

Email:  Twitter: @cymaltd


Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.

Standardising Solution Diagrams

As architects, can we at least standardise our solution diagrams?

It still surprises me that even in some corporates, there are solution design diagrams being produced that aren’t based on any standard, or are roughly aligned with some modelling notation at best.

When I first started as a Solution Architect in a small Architecture team for a corporate many years ago, there were no Solution Design templates or standards. When documenting a solution I was left to my own devices to come up with the content and diagrams. Even as a junior architect, I understood the importance of communicating your solution. I always wanted to get the solution on one page and abstract some of the detail to ensure the key stakeholders got the key points. I’d typically end up with a Visio diagram that combined application and infrastructure views, but also at different levels of detail dependent on the specifics of the solution I wanted to highlight.

As the programme of work grew year on year, so did the Architecture team, and the need for some level of standardisation and reuse became clear. The core deliverable of the team was a Solution Design document, so the structure and content of that deliverable was debated and standardised. The reality was that that only got us so far. It didn’t bring any standardisation to diagrams we were creating, no diagrams were reused, every Architect had their favour of viewpoint (which typically reflected their domain strengths). Some organisations resorted to implemented expensive architecture modelling tools, but even a good tool won’t ensure consistency and reuse. Like many standards, good outcomes can still be achieved without them, but consistent outcomes across many individuals is much harder to achieve.

There are a number of professions (I won’t name them for risking starting a separate debate) that argue what they practice is more of an art than a science and hence standards shouldn’t apply. The justification from architects is often that every project and application is different so there is little point in standardising. Then they can’t understand the previous architects work, so they don’t reusable diagrams.

While the likes of UML gave us components diagram that went some way to giving as a standard way to diagram application components and interfaces, there still big gaps. There was still a lack of a modelling language that was sufficiently flexible to replace those “custom” diagrams you created, but sufficient to ensure all areas were considered and standardised sufficiently so that your IT peers can understand them consistently.

“ArchiMate offers a common language for describing the construction and operation of business processes, organizational structures, information flows, IT systems, and technical infrastructure. This is just like an architectural drawing in classical building where the architecture describes the various aspects of the construction and use of a building” (Wikipedia). Most importantly, it’s very flexible and supports many “viewpoints” depending on what you need to communicate, but there rules (which are sometimes broken) just like any real spoken language.

Example archimate diagram illustrating different layers

Example Archimate diagram depicting different layers. CC BY SA 3.0

IT Architecture as a profession is still immature. Imagine if building architects created diagrams with inconsistent detail, or non standard notation. There would surely be more issues in the constructions phases. I found this interesting building architect quote “We were not creating the construction documents for our own use, but providing people who have no prior knowledge of the project, with all of the information that would be needed to construct the project. No matter how great the design of the project may be, if we can’t graphically instruct the contractor on how to construct it, then we have failed in our responsibility to the client.”

I found as an Architecture team manager it was difficult to identify suitable training for the team to support their profession development. There was the obligatory TOGAF training, but unless you were an organisation practicing TOGAF, or had a project big enough to be using the TOGAF framework at some level, that training was hard to put in practice. Solution model diagramming was something the architects do often, but they could be a lot better at it.

At the risk of contradicting myself, there is still a place for those custom hybrid solution diagrams, especially for your business or senior executives audiences where your ability to communicate is king. Just don’t use that as an excuse to not produce additional standards based diagrams for your other IT stakeholders.

David Molesworth, Principal Architect at Cyma Limited

Email:  Twitter: @cymaltd

Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.

Using the Business Motivation Model: Modelling BMM in Archimate

The previous blog discussed the essential BMM concepts that are of particular relevance and use to small and medium sized enterprises.  This is sufficient to start modelling business motivation in an unstructured manner on paper or using common drawing tools.  But if the goal is to create a persistent architecture artefact that can be share, enhanced, and used to inform other architecture activities, then we need to model in a more formal and structured manner.  BMM itself is not a formal specification, so it must be mapped onto an existing modelling language.

In this blog I will discuss how Archimate can be used to define a BMM Metamodel.  More specifically, Archimate 2.1 and the Motivation Extension.  A brief description of how Archimate 3.0 affects this work is provided towards the end.  The tool used is Archi, a great open source project.  

Specialising the Archimate Motivation Extension

The first step is to create the BMM concepts in Archimate through specialisation of existing elements, illustrated in the following diagram.

Diagram illustrating the specialisations of archimate elements to bmm concepts

BMM Means are modelled as Archimate Requirements.  An Archimate Requirement is defined as an aspect of what a system (in its widest sense) does.  The Mission, Strategy and Tactic concepts are all statements of action and can be viewed as high level requirements.  Directives are also clearly a type of requirement or constraining requirement (I have deliberately chosen not to use Archimate Constraint).

BMM Ends are modelled as Archimate Goals.  An Archimate Goal is defined as an end state so this is a pretty straightforward interpretation.

BMM Influencer is modelled as an Archimate Driver.  An Archimate Driver is defined as something that drives change in an enterprise.  Again, this is a pretty uncontroversial mapping.

Lastly BMM Assessment and BMM Impact are modelled as an Archimate Assessment.  An Archimate Assessment is defined as the outcome of an analysis of a driver.  They are both types of assessment, so again I feel that the mapping is appropriate.

Defining the BMM Metamodel

Now we have the BMM concepts modelled as Archimate elements, we can now define the BMM Metamodel using Archimate relationships. I have chosen not to specialise the relationships so that they map to the BMM relationships – the BMM relationships are a bit too specific and wordy for this .  Instead, I am using standard Archimate relationships and I feel that these are sufficient for the purpose.  The following diagram shows the BMM Metamodel in Archimate.

An image illustrating the BMM metamodel in archimate

The relationship shown between BMM Influencer and BMM Assessment is an Association.  Archimate is strict about the relationships that can be drawn between elements.  The only relationships allowed between an Archimate Driver and an Archimate Assessment are Association and Influences.  In BMM the BMM Influencer is neutral and it is the BMM Assessment that determines the effect on Means, so Influences did not feel like an appropriate relationship between these two concepts.  Association was therefore selected as the most appropriate relationship.

A similar argument can be followed for using Association between BMM Assessment and BMM Impact.  The relationships available are Association, Influences, Aggregation, Composition and Specialisation.  Compositional relationships do not feel right as we are not creating a meaningful order or structure.  Specialisation is certainly not right and neither is Influences.  We are left with Association again, and I think this is the right relationship.  We are simple associating related statements.

The relationship from BMM Assessment to BMM Directive is Influences, and this is certainly correct in terms of both BMM and Archimate.  Similarly, the relationship from BMM Directive to both BMM Tactic and BMM Strategy is Influences.

Aggregation has been used to define the organisation of BMM Mission, BMM Strategy, and BMM Tactic as well as BMM Vision, BMM Goal, and BMM Objective.  Aggregation was used over Composition because it is more of a group of common elements rather than a strict whole-part relationship.  For example, a BMM Tactic may relate to multiple BMM Strategies.

Lastly, Realisation is used to connect BMM Means concepts to BMM Ends concepts.  This is straightforward and is aligned with BMM and Archimate – and action will realise a goal.


In this blog I have demonstrated how the core BMM concepts discussed previously can be mapped onto a common modelling language, Archimate, to create a BMM Metamodel that can now be used to capture business motivation in a formal and structured manner.

By using Archimate we now have access to a wide range of tools for modelling.  We can also map the motivation modelling directly to other enterprise architecture work, such as roadmapping.  The next blogs will take a look at how to use the Archimate based BMM Metamodel and how to use it in the definition of roadmaps.

Appendix – Archimate 3.0

Archimate 3.0 was released in mid 2016 and it has introduced two new elements that have a direct bearing on this work.  The new elements are:

Outcome:  This is defined as and end result that has been achieved and is supposed to be measurable.  This can be used instead of Goal to represent BMM Objective.

Course of Action:  This is defined as an approach or plan to achieve a goal and maps directly to the BMM concept of the same name.  It can be specialised for BMM Strategy and BMM Tactic rather than using the Archimate Requirement.

John Owen, Principal Architect at Cyma Limited

Email:  Twitter: @jiowen and @cymaltd

Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.

Using the Business Motivation Model: Influencers and Assessments

The first blog provided a brief introduction into what BMM is and isn’t, and then discussed the two most popular concepts of the model, Means and End. To recap, the basic idea is that business motivation and strategy can be split into two categories, an end state (or states) and a set of means and plans to get there, such that the means help realise the end. The following diagram provides a simplified view of these concepts and their relationships.
An image showing the BMM Means and End concepts
This post will go on to describe three other essential concepts (Influencer, Assessment and Impact) as well as return to the Means concept to explore the idea of Directives. The previous diagram can be expanded to conclude these new concepts.
An image showing the BMM Means, End, Influencer, Assessment and Impact concepts
Influencers, Assessments, and Impacts are all about understanding the reasons why an enterprise wants (or needs) to change – they are the Drivers for change in an enterprise.

The basic idea is to examine the environment in which the enterprise exists in order to identify Influencers and then make some Assessments about them.  These Assessments can then be used to guide and direct how an enterprise may respond to an Influencer in order to take advantage of (or mitigate) its Impact.  Assessments may also help in identifying and defining the End statements.

Remember that BMM is not a methodology, the arrows indicate relationships not process flow.  That said, you can probably see that this form of modelling lends itself to an iterative approach.

Influencer, Assessment and Impact

Influencers are the things that affect an enterprise. They may be internal or external, and are often grouped or categorised in ways that are meaningful to the enterprise. For example competitor, customer and partner are examples of external Influencer groups while infrastructure, capability, and culture are examples of internal Influencer groups. Most importantly, an Influencer is a neutral statement of fact which must then be assessed to identify the impact.

An Assessment is a judgment of an Influencer that discusses how the Influencer may affect Means and Ends.  Assessment can be grouped if needed. The BMM does not mandate any specific categorisation but discusses the use of SWOT based grouping.  Personally, I am not the biggest fan of SWOT for many reasons.  There are plenty of other approaches that could be used, such as SCORE, PEST, NOISE, SCOPE. You can find plenty of information on the Interweb, but a good starting place can be found at Sideways Thoughts.

An Impact provides an evaluation of an Assessment describing the potential effect of an assessment in more quantitative terms (where possible). Again, no specific grouping is provided, but the BMM does discuss a simple split between risk and reward.
Table providing examples of BMM driver concepts

Means revisited

Means was discussed in the previous post, but for simplicity I left out the concept of Directive. Whereas Mission, Strategy and Tactics are all descriptions of how an enterprise will go about achieving the desired Ends a Directive is more about governance of action than action itself. They can be viewed as requirements that are used to guide and constrain Strategies and Tactics.
Table providing examples of BMM Means concepts

Some key concepts deliberately omitted

In the first post I mentioned that in the interest of creating readable blog posts and avoiding the trap of over analysis by applying a ‘just enough modelling’ principle, I deliberately simplified or omitted some concepts. Here are some of those with a brief explanation of what they and why they are omitted – just jump to the conclusion if you aren’t too concerned.

The BMM has a complex set of relationships between the various concepts. I have limited this to a few simple relationships such as influences, realisation, aggregation and association.  The main reason for this is to provide a clean mapping to the relationships available in Archimate.  I also find that the relationships could be verbose but still added little extra meaning beyond what can be achieved with the four I selected.

Course of Action and Desired Result are two concepts used to encapsulate the more tangible Means and Ends concepts. Course of Action can be either a Strategy or Tactic; Desired Result can be either a Goal or Objective. Because I chose not to model all of the relationships in BMM these two concepts became largely irrelevant. Even in BMM they are treated more as containers than as concepts with specific meaning.

A Directive is modelled in BMM either as Business Rule or Business Process. This can be easily achieved by grouping Directives, just as Assessment and Impacts can be grouped.  For this reason I decided to keep things as simple as possible and not model them explicitly.


So far I have introduced the BMM model and described some of the core concepts, focusing on those that I feel are useful when modelling motivation for small to medium sized enterprises. This is sufficient to start modelling in an unstructured manner on paper or using common drawing tools. But if the goal is to create a persistent architecture artefact that can be share, enhanced, and used to inform business improvement activities, then we need to model in a more formal and structured manner. The next blog post will look at how we can do this by using Archimate to define a BMM metamodel.

John Owen, Principal Architect at Cyma Limited

Email:  Twitter: @jiowen and @cymaltd

Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.

Using the Business Motivation Model: Introduction, Means and End

The OMG BMM provides an excellent framework and metamodel to understand and communicate the motivation behind change and for developing and defining business plans. The BMM is very thorough, providing the user with a comprehensive set of concepts and relationships to analyse and model motivation and it is very well suited, in fact designed, for large enterprises.

Successful enterprises are aware of change and will develop business plans to manage change, regardless of size. The BMM provides an excellent conceptual framework to do this, and with minimal effort it can be tailored to suit enterprises of all sizes.

This blog is the first in a short series that discuss the BMM within the context of a small to medium enterprise. In this article I will introduce the BMM and discuss the key concepts that can be usefully applied to any enterprise. Subsequent blogs will introduce a few more BMM concepts and then take a look at how to map these concepts onto a formal modelling language called Archimate, how to model motivation, and how to use it to inform road mapping activities.

Why Enterprise?

Throughout this article I will use the term ‘enterprise’ rather than business, organisation, company etc. It can be legitimately used as a synonym for these terms and allows the discussion to be applied to a wider context than purely commercial operations. The word is also used to describe the desire or ability to to do something difficult or risky, which is certainly appropriate for the topic – change is difficult and risky, so it would be prudent to have considered any action carefully.

What is the BMM?

An enterprise does not exist in isolation. Instead, it lives in a world surrounded by many other enterprises, all of which have an influence on its own health and wellbeing. The BMM provides the language to describe these influencers and what an enterprise may choose to do about them. That said, it is important to note that BMM is not a formal definition of a metamodel. If we are to model it, then we must map it to a suitable formal language. It is also important to note that BMM is not a methodology that defines how to do this, but it does provide an excellent scaffold with which a strong business plan can be built.

As mentioned in the introduction, the BMM is a very detailed model that has been developed to support the definition of business plans – specifically, the definition of well informed business plans. To do this the BMM looks at the reasons why an enterprise may choose to change, what it may want to change to, and how it may go about changing. These are modelled respectively by the concepts of Influencers, Assessment, Means, and End.

Reducing an OMG specification into a short set of blog posts necessitated some omissions and simplifications, and I will certainly have introduced my own interpretation along the way as well. Furthermore, following a simple principle of ‘just enough modelling’ I have also removed elements of BMM that are not relevant in the context of small to medium sized enterprises. If you are interested in the full text and official definitions, you can find it on the OMG BMM site.

In the next few sections I provide a quick introduction to Means and End, the others will be dealt with in the next blog. The following diagram provides a simplified view of the concepts and their relationships – there are many versions of this view so it may well look familiar.

An image showing the BMM Means and End concepts

The basic idea is that business motivation and strategy can be split into two categories, an end state (or states) and a set of means and plans to get there, where the means help realise the end. Read on for more details.


Ends (actually often just End in the BMM – maybe to allow them to talk about ‘Means to an End’) are descriptions of the things an enterprise wants to achieve or to become. They describe the result of doing something. The core End concepts are Vision, Goal, and Objective.

A Vision is an aspirational statement of a future state, although it could also capture current state as well where this is of value. Goals are qualitative statements that describe an achievable part of an enterprise’s Vision, which are in turn quantified by one or more Objectives.
Table providing examples of BMM End concepts


Means are descriptions of how an enterprise will go about achieving the desired Ends. They describe the actions and activities that must be performed in order to achieve an outcome. The core Means concepts are Mission, Strategy, Tactic, and Directive.

A Mission provides statements about operational, day-to-day, activities that will realise Vision. Strategies describe agreed approaches to achieve a particular Mission, and thereby realise a Goal or Vision. Strategies are definitions of longer term plans and activities which are comprised of shorter term Tactics. The role of a Tactic is to implement part of a Strategy, and thereby realise an Objective or Goal.
Table providing examples of BMM MEans concepts


In this blog I have introduced the BMM model and how I think it can be used to help enterprises of all sizes, if used appropriately. I have described two of the core concepts, Means and End, and will go on to discuss Influencer and Assessment in the next blog. After that we can get into the details of how to use BMM.

John Owen, Principal Architect at Cyma Limited

Email:  Twitter: @jiowen and @cymaltd

Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.