EVA

Canvasses on Steroids

A popular technique for quickly understanding or planning a business is the Business Model Canvas, introduced by Alexander Osterwalder and Yves Pigneur. This provides a high level ontology in the form of a one page diagram with boxes for key elements of a business.

The canvas idea has also been used for assessing other things including Business Value Proposition; Blue Ocean Strategy Ideas and Product and Service Innovations. There are a number of advantages to the canvas:

  • It is quick and easy to use

  • It is accessible to non-technical executives, managers and domain experts without modelling knowledge

  • It is concise and low effort

  • If well designed, it focusses attention on key concepts (provides ontology)

  • It can be done for baseline and proposed scenarios and comparison

However, there are also drawbacks and limitations:

  • It is often just a diagram with little formality of definition behind the concepts or consensus on what each category actually means
    (Resources may include People, Skill, I.P., Cash, Plant… )

  • Users often mix concepts and instances in completing the blocks
    (Retail Customers, Govt. Dept of Energy…)

  • There is insufficient detail behind the entries to perform more detailed analysis
    (For Revenue Streams we may list Hardware Sales, Software Sales and Services, but we don’t know that these contribute in the proportion 60%, 35%, 5%)

  • Relationships and dependencies are not apparent
    (Which Partners or Resources or Activities are necessary to offer a particular Value Proposition?)

To solve these issues, facilitate richer analysis and integrate the elements in the canvas with other enterprise models and architecture elements, we implemented advanced features for canvasses in our Enterprise Value Architect (EVA) tool platform:

  • Users can define canvasses using any concepts defined in the meta model (also user definable). Concepts are represented by user friendly names and icons

  • Users can choose the canvas layout, size of boxes etc.

  • Items captured into a cell can include hierarchies, thereby facilitating use of subcategories and templates, if desired

  • Items captured are repository objects with relationships and any desired properties, which can include rich items such as documents, images, calculations etc. Items in the canvas have hyperlinks to view or edit these details

  • Items can be related in the canvas by drag and drop. Related objects are highlighted when the cursor is hovered over an item

  • Items can be included in any other tool view, including reports, generated documents, matrices and graphical models

  • Canvas views can be linked into menus for easy access by users collaborating on a shared repository. Since the tool is web based, these users can be anywhere

These innovations make canvasses very powerful! Take a look at the demonstration below.

Role of the Repository

1633369525412.jpeg

As architects we use many models and produce/share a lot of artefacts (models, documents, presentations, plans, posters). We collect a lot of references and create many “working files” (such as notes, spreadsheets, outlines, templates). We share with other parties in business, I.T., vendors and advisors.

It is a daunting task to keep all of this stuff straight, to find it when we want it, to ensure that we have the right version. Difficult to make a consistent change across the various mentions of a particular thing, for example: a Business Unit has been renamed - how can we reflect that across all references in all the various models and documents?

We can of course build a library of documents, often a network drive or Sharepoint portal. This may start out well, but often quickly devolves into a large bucket. A better solution is to have electronic document management, where artefacts are stored, indexed, versioned, searchable and sharable with appropriate permissions. This can work well with appropriate discipline. It still suffers from the maintenance problem we mentioned. E.g. Updating things mentioned _inside_ models, presentations and other artefacts consistently.

This is where we need a proper repository. This may do document management too: the key difference is that a repository will manage _objects_. These can be course grained, such as the documents and models mentioned. They can also be fine grained, such as the things of interest inside the documents, models etc. A repository allows having the same object reflected in multiple models, documents, reports, matrices etc. This greatly facilitates impact analysis and maintenance to ensure consistency. It also allows integration of different domains or perspectives. For example, I can mention Business Objects (which derive from a Conceptual Data Model) in a Business Process Model, or a Requirement Specification for a Business Intelligence Dashboard.

To provide this sort of flexibility, the repository should allow customisation of meta models. I.e. we should be able to define: the concepts we are interested in, the relationships that they can have to other concepts, the properties that are important to a concept. Also, how we want to represent the information in various ways including: forms, reports, models, documents, matrices, etc. The repository solution should provides easy import from standard formats as well as APIs for easy integration to other tooling. Global search facilities and a strong security system are valuable too.

Our EVA toolset provides such a repository. The philosophy is that it's easy to capture information from a variety of sources: CSV, XML, Web Forms, Graphical Modelling; store it all semantically regardless of source; use it for analysis; and output in many forms: Query, Lists, Matrices, Visualisations, Graphical Models, etc.

Read more about EVA here.

#enterprisearchitecture #enterprisemodelling #repository #tools