Random Thoughts

Some random thoughts on enterprise and software systems architecture, and what comes into mind when dealing with these ...

Using ArchiMate for modeling ...

posted Nov 9, 2020, 10:08 AM by Alar Raabe

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

In the ArchiMate specification (see https://pubs.opengroup.org/architecture/archimate3-doc/chap03.html#_Toc10045296 ) chapter 3.6 is written „The ArchiMate language intentionally does not support a difference between types and instances. “.

This design decisions brings ambiguity into the meaning of the diagrams. For example, what is described in the 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 be possible to deduce, whether diagram is describing the types or instances (because for example certain reflexive relationships, like „composition“, would not make sense for the instances), like:

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

Therefore indicate the usage of types or instances explicitly, using for example through ArchiMate specializations (similar to UML sterotypes) and the naming convention similar to UML, either for the types:

or for the instances:

Although in ArchiMate specification it is stated that „At the Enterprise Architecture abstraction level, it is more common to model types and/or exemplars rather than instances.“, there are still many cases where the model of the actual enterprise architecture consists of instances (like capability maps, process maps, or application landscapes, which all represent certain enterprise portfolios), and therefore it makes sense to clearly indicate on the diagrams, where are the types (for example when describing conceptual models or solution patterns) and where are the instances, especially if both are mixed on the diagram.

Hierarchies with the single elements and fixed levels

posted Nov 8, 2020, 10:58 PM by Alar Raabe   [ updated Nov 8, 2020, 11:15 PM ]

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 on certain levels.

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

For example in case of taxonomy, each element is representing a set of features – it is a class hierarchy.

In the class hierarchy it makes sense to have even single sub-class for a particular class, because this sub-class represents a different set of features than its super-class. It also could make sense in class hierarchy, if needed, to have a fixed number of levels – because on each 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 a whole – it is a composition hierarchy.

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

It makes sense to have:

, but not .

It also would not make sense in the decomposition hierarchy to have fixed set of levels – because this 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 of hierarchy, introducing multiple ways to name what actually is the same thing.

This is the reason I wouldn't advise to create for example business capabilities with only one sub-capability or application components with only one sub-component.

Using models in software development ...

posted Jun 7, 2020, 4:30 AM by Alar Raabe

I see more and more, that the usage of models (referring to traditionally used qualitative, often graphical, models and modeling languages) and model building is diminishing in the software engineering (if we can talk about the software "engineering" anymore at all).

The reason seems to be that developers do not want to use the models and therefore making or maintaining these is perceived as "no-value" overhead. Behind the reluctance of developers to use models is often the agile movement's argument that everything could be seen/found from the code, and because in DevOps same team that does the development, does also maintenance, there’s also no need to communicate between different teams.

But actually:

  • it is very difficult, if not impossible, to write code so that it all the requirements or high-level design decisions would be presented directly in the code (not to mention being easily readable/understandable for the ones that did not write the code),
  • it costs time and money if developers make mistakes because they are not able to understand from the code the requirements it implements and the design intents/constraints, and
  • it costs even more time and money if developers go away and need to be replaced by new ones who don’t know anything what has been said "at the water-cooler" (possibly two years ago).

Because additional information (same that has been traditionally represented by the models) is needed and because code isn’t usually very much commented and often also not very readable, so often developers and others, involved in the software development activities, try to find other ways to collect and maintain this additional information, representing it usually in non-formalized textual form in their work-organization tools (e.g. Confluence wiki and in Jira tasks).

Additional reason to drop models in the software development in favor of informal textual descriptions, seems to be the inability to automate anything in software development process apart from the simple "automation" of build tools to manipulate software artifacts in correct succession (thing that has been around already past 60 years) – so there’s no perceived value to have requirements or high-level abstract knowledge about the software to be represented in machine-readable form.

Today still a very big part of the development of business software is solving rather standard/common problems and is filled with the repeating tasks, which are very easily automated (like development of GUIs (where they are not the distinguishing factor), integrations, transformations, reports, etc.), and doing so would economize a lot of development time, but this will be only possible, if the requirements and high-level design would be formally specified and represented in a machine readable form.

So, the main question is "Do we want/need to automate also our software development activities?", or we just want to automate only the various business activities and continue with manual software development?

If we want to automate software development (i.e. digitalize the software development), we need a formal, machine readable, representation of requirements and high-level designs (with the focus on formalization and machine readability, not just some pictures with "boxes and arrows"), in the same way as for example to automate the credit origination, we need formal representation of customer, loan, collateral, sales process, involved business rules, etc.

Business Capability – a short clarification

posted Jun 19, 2017, 2:54 AM by Alar Raabe

The term “business capability” 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 business management.

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

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

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

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

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

The business capabilities for a given business domain can be found/formulated, taking as the starting point 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 must be able to do, to support the business strategy and execute the business models.

API vs. ESB (and other related tools)

posted Jun 16, 2017, 1:04 AM by Alar Raabe

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

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

Therefore managing an API is nothing more than managing any other formal document which can be done using any basic text editor or something more fancy, called API management tool, with lots of bells and whistles and with heavy price tag. 

From another side, ESB is nothing more than a system that transports and routes service requests, and returns matching responses, usually providing several different physical mechanisms to do so, independent of how these service requests are defined or do they together at all form an API.

Therefore, if we implement API management tool 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 any other large development. What makes API design even more important, is that API's guide the architecture of future developments and affect strongly their properties.

A good analogy here is with DBMS and actual database 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 needs just emerges from separate developments. It needs a special (some-time very large) effort, to develop a suitable concrete data-base schema.

API design and development requires same way as data-base schema design and development:

conceptual models for both functionality (service operations) and data (information),

logical models that specify the interfaces, and

physical models that specify the interfaces for specific implementation technologies.

Thoughts on "Architect Your Business - Not Just IT"

posted Apr 13, 2015, 8:23 AM by Alar Raabe

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

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

Here I must agree again with the statement that “… the dominant design approach for large companies is ‘divide and conquer’ in which individual leaders accept responsibility for 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 mentioned approach could work, but only if the domains of power and integration/interaction points between those separate “kingdoms” are very clearly defined and controlled, and designing these interfaces and controls should be  the main task for the actual business architect.

Complexity in/of the enterprise architecture

posted Dec 30, 2013, 2:10 PM by Alar Raabe

The negative effects of the overall complexity of business and IT in the enterprise, manifest themselves as unreliability and excessive cost of operations, and excessive cost and time to make 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 to control 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 elements and their interconnectedness (number of interconnections between these elements).

Based on such definition, we propose to measure 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 and IT we can differentiate between:

  • external complexity, caused by the external factors that are not under 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 decisions of 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 internal business complexity (e.g. how we organize or operate the business) defines also large part of the external IT complexity, the other part being defined by the external technological factors.

Extending EA meta-models to contain the environment ...

posted Jul 29, 2013, 1:55 AM by Alar Raabe   [ updated Jul 29, 2013, 2:09 AM ]

Current EA meta-models describe in great detail the internals of the enterprise, but leave the environment in which the enterprise operates either totally out, or describe it in considerably less detailed way.

There are definitely some meta-models, for example Nick Malik's EBMM (contains Influencer) and new ArchiMate motivation extension (contains Driver), which try to deal with the (inconveniences) of outside world, but this is not that elaborate and structured, as these parts of meta-models which deal with inside world.

If we see the role of EA function as supporting the orientation of the enterprise according to John Boyd's OODA loop, there is need to have sufficiently good models for both representing and interpreting the environment, and representing and interpreting the enterprise itself.

We should add something similar to the dynamic financial analysis (DFA) models to the EA meta-models, to be able represent the impact of environment to the enterprise, as elements representing competition, markets, regulations, etc. (see for example A. Bergbauer, V. Chavez, T. Fischer, R. Perera, A. Roehrl, S. Schmiedl, Back to the future: Dynamic Financial Analysis (DFA) for decision making, 2004 (Fig. 3), or M. Eling, T. Partnitzke Dynamic Financial Analysis: Classification, Conception, and Implementation, 2005 (Fig. 2), or M. A. Taylor, Business Environment Model, 2013).

Do/should we have "internal customers"?

posted Jul 24, 2013, 2:53 AM by Alar Raabe   [ updated Jul 24, 2013, 7:01 AM ]

If we use in the enterprise architecture framework IBM Component Business Model (CBM) and A. Osterwalder's business model canvas (BMC) for describing the business and its parts in a business domain architecture.

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

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

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

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

So in the behavior of a business component, there should not be any difference, whether the external (to the given business component) party is also external to the whole enterprise or just another part of the enterprise, but the business component should definitely have different behavior (down to the clear service agreements) towards the parties to whom it delivers services and towards 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 same word “partners”, for both consumers of their services and suppliers of services they need.

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

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

In case the same business component provides the same business service to both enterprise’s customers and other business components in the enterprise (as in many cases IT related business components do), should we treat those as two different service consumer classes, and use different words to denote these?

Reducing the complexity and increasign the modularity ...

posted Apr 22, 2013, 8:26 AM by Alar Raabe

... of enterprise systems, based on the results from (The Evolutionary Origins of Modularity), could be achieved, by imposing an additional cost (a kind of "tax") upon the direct connections between the enterprise systems.
Reserves created from such "tax", could be invested into the improvement activities of enterprise architecture.

1-10 of 20