Recently I stumbled upon a strange„feature“ of ArchiMate language that brings some ambiguity intothe models.

In the ArchiMate specification (seehttps://pubs.opengroup.org/architecture/archimate3-doc/chap03.html#_Toc10045296) chapter 3.6 is written „The ArchiMate languageintentionally does not support a difference between types andinstances. “.

This design decisions brings ambiguityinto the meaning of the diagrams. For example, what is described inthe following diagram:

Does this mean that:

• „There exist a set of data objects of type A, each consisting of 'one-or-more' data objects of type B, and 'one-or-more' data objects of type C“, or

• „There exists a data object A, which consists of data object B and data object C“, or even some mix like

• „There exists a data object A, which consists of 'one-or-more' data objects of type B, and a data object C“?

There are situations, where it would bepossible to deduce, whether diagram is describing the types orinstances (because for example certain reflexive relationships, like„composition“, would not make sense for the instances), like:

But in some cases it wouldbe impossible to know without some indication of what kinds ofelements are in the model or on the diagram, like:

Therefore indicate the usageof types or instances explicitly, using for example through ArchiMatespecializations (similar to UML sterotypes) and the naming convention similar to UML, either for the types:

or for the instances:

Although in ArchiMatespecification it is stated that „At theEnterprise Architecture abstraction level, it is more common to modeltypes and/or exemplars rather than instances.“, there arestill many cases where the model of the actual enterprisearchitecture consists of instances (like capability maps, processmaps, or application landscapes, which all represent certainenterprise portfolios), and therefore it makes sense to clearlyindicate on the diagrams, where are the types (for example whendescribing conceptual models or solution patterns) and where are theinstances, especially if both are mixed on the diagram.

I have seen many times the which to fix the number of levels in the decomposition hierarchies (like for example in the maps of business capabilities), with the reasoning that it would make things easier by always having known number of levels. One result of this approach is the appearance of branches with single elements oncertain levels.

There are such hierarchies, where theelements with just one sub-element will make sense, and there areother hierarchies, where this doesn’t make sense.

For example in case of taxonomy, eachelement is representing a set of features – it is a classhierarchy.

In the class hierarchy it makes sense to have even singlesub-class for a particular class, because this sub-class represents adifferent set of features than its super-class. It also could make sense in classhierarchy, if needed, to have a fixed number of levels – because oneach level of each branch you have different set of features (which you can distribute evenly).

It makes sense to have:

either , or .

On the other hand, in case of functional decomposition,like hierarchy of business capabilities or application components, each element is awhole – it is a composition hierarchy.

In the composition hierarchy(which consists of instances, not of classes) it doesn’t make senseto have an element that has only one part, because these are then thesame thing.

It makes sense to have:

, but not .

It also would not make sense inthe decomposition hierarchy to have fixed set of levels – becausethis would either enforce the designers to come up with "dummy" levels just to follow the scheme, and results decomposition that is not natural, causing branches with single elements just to „fill“ the levels ofhierarchy, introducing multiple ways to name what actually is the same thing.

This is the reason I wouldn't advise tocreate for example business capabilities with only one sub-capabilityor application components with only one sub-component.

The term “businesscapability” is synonymous with BIAN “Service Domain” (see BIAN How-to Guide), with “business component”in IBM’s CBM methodology (see Component Business Models), and with “business function” in general businessmanagement.

A “businesscapability” describes ability to perform certain set of related activities forproviding a set of business services, by combining people, processes, resources(incl. needed systems) and governance, using the business services from otherbusiness capabilities, if needed.

Where “businessservice” describes externally visible unit of business functionality of abusiness capability, which provides value to service consumers, is provided viaexplicit external interfaces, and realized by business processes.

You can think of a businesscapability a self-contained part of business that could be outsourced as is.

Business capabilitiesthemselves can be hierarchically sub-divided into smaller business capabilitiesif needed, or combined into larger business capabilities up to a businesscapability to provide all banking services.

Business capabilitiesare connected through the business services and form a value network.

The businesscapabilities for a given business domain can be found/formulated, taking as the startingpoint the lists of key activities needed for all the business models of given business domain. The set of business capabilities describes what things given business domain mustbe able to do, to support the business strategy and execute the businessmodels.

I would like to clarify some questions related to API management,ESB and specific service interfaces.

From one side, API (Application ProgrammingInterface) is nothing more than a specification – a text, containing a set ofmore or less formal statements, which specify the available (service)operations and data that flows through the interface when these operations areperformed.

Therefore managing an API is nothing morethan managing any other formal document – which can be done using any basictext editor or something more fancy, called API management tool, with lots ofbells and whistles and with heavy price tag. 

From another side, ESB is nothing more thana system that transports and routes service requests, and returns matchingresponses, usually providing several different physical mechanisms to do so, independentof how these service requests are defined or do they together at all form anAPI.

Therefore, if we implement API managementtool and ESB, then this will not in any way result in a specific API (or service interface). 

Developing a specific API is quite time-and resource-consuming task, which needs to be planned and designed as anyother large development. What makes API design even more important, is thatAPI's guide the architecture of future developments and affect strongly theirproperties.

A good analogy here is with DBMS and actualdatabase schema – although we have tools for designing database schemas(e.g. ERwin) and DBMS to run these schemas (e.g. Oracle or TeraData), we cannot assume,that database schema (e.g. for Enterprise DW), suitable for current and future needsjust emerges from separate developments. It needs a special (some-time verylarge) effort, to develop a suitable concrete data-base schema.

API design and development requires sameway as data-base schema design and development:

･ conceptualmodels for both functionality (service operations) and data (information),

･ logicalmodels that specify the interfaces, and

･ physicalmodels that specify the interfaces for specific implementation technologies.

When reading MIT CISR  Research Brief No 12 from 2014 "Architect Your Business - Not Just IT", I agree very muchwith the statement that “… despite the title, business architects rarely designtheir company’s business.”!

The main puzzle forme is, that even when everybody in the organization sees and agrees, that “…their processes, structures, and systems are not providing the agility theyneed …” (i.e. the business architecture of the company is not adequate), I don’tusually see any dedicated effort for designing a new business architecture, notto mention employment of a specialist with business architect skills for doing that.

Here I must agreeagain with the statement that “… the dominant design approach for largecompanies is ‘divide and conquer’ in which individual leaders accept responsibilityfor success over a specific set of closely related business activities.”. Because of the Conway's Law, this approach leads to a business and IT architectures that copy the power-structure of the organization.

The above mentionedapproach could work, but only if the domains of power and integration/interactionpoints between those separate “kingdoms” are very clearly defined and controlled,and designing these interfaces and controls should be  the main task forthe actual business architect.

The negative effectsof the overall complexity of business and IT in the enterprise, manifest themselves asunreliability and excessive cost of operations, and excessive cost and time tomake changes.

Business complexity has additional negative effects due to the difficulties in selling more complex products and customer dissatisfaction due to unclear and time consuming business processes.

Therefore complexity of the business and IT in enterprise needs to be controlled and managed.

To be able tocontrol and manage the complexity, we need to be able to measure it.

If looking into different treatments of the complexity of systems, we can define the complexity as

the number of different elementsand their interconnectedness (number of interconnections between theseelements).

Based on such definition, we propose tomeasure business and IT complexity by counting the elements of business(like business models, customer segments, offered products, business functions, business services, business processes, etc.) and IT (like data stores, applications, technologies, etc.), and their interconnections.

In both business andIT we can differentiate between:

• external complexity, caused by the external factors that are notunder our control or depend on large scale strategic decisions (that define in which business the enterprise is in), which cannot be reduced without the large changes in the enterprise business strategy, and

• internal complexity, caused by our tactical choices and decisionsof how we organize ourselves or how we operate (that also defines the complexity for the customers), which can and should be reduced to improve the overall efficiency and agility of the enterprise.

The CBM can be used to describe the overall businessfunctionality and the functional decomposition of whole enterprise into businesscomponents, which can be viewed as small independent businesses. The businesscomponents in a CBM are connected through the business services that they produceand/or consume from the other business components, forming a value network.Some of those business services are produced and/or consumed by the externalparties (including the enterprise’s customers). So from that viewpoint, for everybusiness component, an external (to the given business component) party couldbe in two different role – customers/consumers of the produced services and suppliers/producersof the required services.

The A. Osterwalder’s business model canvas can be used to describethe overall business logic of how the business works for overall enterprise, and/orfor each functional sub-division down to the business components, identified inthe CBM. Business model canvas also identifies external parties in two differentroles – partners and customers. This separation is beneficial because business usuallyneeds to employ different relationship management techniques for the externalparties playing those different roles, and usually also the channels throughwhich the value is delivered to the business, and through which businessdelivers value, are different.

Above described conceptual models (together with their language)provide the modularity and encapsulation, needed to manage the inherentcomplexity of the business functionality that whole enterprise comprises. Employing thisview in business organization/operations allows us to achieve self-optimizationof the operations of whole enterprise by optimizing the operations of separate businesscomponents, and robustness by encapsulating the business components behind thewell formed service agreements.

In principle we should be able to separate and replace anybusiness component (including IT or its parts) as an independent businessentity, without changing the internal workings of that particular business componentand affecting the operations of overall value network.

So in the behavior of a business component, there should notbe any difference, whether the external (to the given business component) partyis also external to the whole enterprise or just another part of the enterprise, but thebusiness component should definitely have different behavior (down to the clearservice agreements) towards the parties to whom it delivers services andtowards the parties that deliver services to it.

To avoid confusions with the usage of word “partner” in the A. Osterwalder's business model ontology it would not be good to denote such business components,which do not directly deliver services to the enterprise’s customers, with the sameword “partners”, for both consumers of their services and suppliers of servicesthey need.

There might be political reasons for which we want that in our language enterprise’scustomers should stand out from business components that are internal to the enterprise, and because the value network inside the enterprise uses different ways tocount for the value, the word “internal customer” might not be appropriate forconsumers of internal services.

So should we then use the word “consumer” throughout the enterprise architecture models/descriptions to denote the businessservice consumers in the business models instead of word “customer”?