Enterprise Architecture Debts

Stovepipe System

Written by

in

Description

Multiple systems within an EA model are designed independently at every level. It occurs when the interface of two components are different and yet the components themselves are quite similar. Subsystems are integrated in an ad hoc manner using multiple integration strategies and mechanisms.

Context

Derived from: “Stovepipe System”
Stovepipe is a popular term used to describe software systems with ad hoc architectures. It is a metaphor to the exhaust pipes of wood-burning stoves, so-called pot-bellied stoves. Since wood burning produces corrosive substances that erode metal, a stovepipe must be constantly maintained and repaired in order to avoid leakage. Often, the pipes are repaired with any materials at hand, thus wood-burning stovepipes quickly become a hodgepodge of ad hoc repairs – hence, the reference is used to describe the ad hoc structure of many systems.

Cause

Inexperience in developing multilayer architectures is one reason that can result in stovepipe systems. They can also be caused by insufficient team communication and a lack of design reviews.

Consequences

Technical and utility functions are implemented inconsistently. Development time of stovepipe services is considerably larger. Duplication and different implementations for the same functionality also has a negative impact on maintainability. Lack of commonality inhibits interoperability between systems, prevents reuse, and drives up cost; in addition, reinvented system architecture and services lack quality structure supporting adaptability.

Detection

Identical name or identical implementation. Stovepipe services typically have a large number of private implementations. Monolithic and undocumented architectures. In ArchiMate, we can detect this Smell by looking for services that provide similar functionality but have different names or interfaces. In order to detect a duplicate abstraction, one can be checked for identical implementations and terms in the model. We can not evaluate identical implementations within a graph because it requires much more low-level details. Therefore, a process manager is required to check for identical implementation between components. However, we can evaluate identical names by checking if two components have the same or similar names.

Solution

Refactor the common private features of all services into new technical services or utility components with a common interface. Coordination of technologies at several levels is essential to avoid a Stovepipe Enterprise. Initially, the selection of standards can be coordinated through the definition of a standards reference model.

Example

The components ‘Legal Expense CRM System’ and ‘General CRM System’ look similar, although having different interfaces.

Cypher query

MATCH p1=(a)--(b:ApplicationInterface|BusinessInterface|TechnologyInterface), p2=(c)--(d:ApplicationInterface|BusinessInterface|TechnologyInterface) <br /> WHERE a<>c and b<>d and  apoc.text.jaroWinklerDistance (a.name, c.name) < $score <br /> UNWIND [p1,p2] as p <br /> RETURN p

Cypher count query

MATCH p1=(a)--(b:ApplicationInterface|BusinessInterface|TechnologyInterface), p2=(c)--(d:ApplicationInterface|BusinessInterface|TechnologyInterface) WHERE a<>c and b<>d and  apoc.text.jaroWinklerDistance (a.name, c.name) < $score return COUNT (DISTINCT a)

Diagram

Diagram for Stovepipe System

Aliases

Alternative Components with Different Interfaces

Tags

soa, business, application, technology, ambiguity, The Object-Orientation Abusers, between elements

Query parameters

[
    {
        "name": "score",
        "type": "range",
        "default": 0.4,
        "min": 0,
        "max": 1,
        "step": 0.1,
        "description": "The similarity score ranges from zero to one, where zero indicates an exact match and one signifies no similarity between the strings."
    }
]

Related smells

All smells

More posts