By John Gotze and Peter Nørregaard
The Tilted House is an architectural anti-pattern that expresses a TCO-costly, change-inhibiting, and risk-inducing misfit between the business and an IT solution. This article describes the phenomenon and offers advice on how to act on it and shows the ways to improve the situation.
In their 2019 book Designed for Digital, MIT Sloan’s Principal Research Scientist Jeanne Ross and colleagues argue that to play in the digital economy, companies need to replace their dysfunctional systems and processes with an operational backbone1. Digital transformations, whether digitizing existing business processes or producing new digital products places existing IS solutions under pressure to adapt. These are not new circumstances (as our case below shows) but the pace is quickening, and the business impact graver.
We have identified an antipattern we call The Tilted House; a situation in which further investments in an existing solution leads to steadily increasing costs, decreasing return on investment, and a significantly increased risk profile.
A Tilted House denotes a misfit between the business and the solution that evolved over time. The misfit is not related to the business nor isolated to the solution, but lies in the relationship between them.
The misfit is in the offset difficult to detect when building or procuring a solution. This misfit can be identified using a Tilted House analysis, using the Tilted House anti-pattern as a guide to uncover initially un-observed but – over time – very palpable issues with the IT solution in question. This article identifies the need for a Tilted House analysis, what a Tilted House anti-pattern looks like and how to respond if the business is living in a Tilted House.
Patterns and anti-patterns are increasingly popular in literature aiming to guide behaviour in a range of areas2. Despite the expansive literature of patterns and anti-patterns, the Tilted House antipattern has not previously been identified, even though being recognisable when knowing what to look for. This article rectifies that.
What is the Tilted House anti-pattern?
We define a Tilted House as an IT system that may have been, and probably still is, fit for a purpose but not fit for the current purpose.
To understand the anti-pattern, imagine a structure, a house, that has supported the needs of its occupants for years. Over time, new purposes and new tasks are being performed in the house and old needs die off. Daily living is becoming increasingly difficult and satisfaction deteriorates. System engineers are perhaps puzzled as the solution has worked for years and may even be in good, technical shape (although not always the case). What has happened is that the business needs have pivoted, gradually incrementally or in quantum leaps, and the house no longer accommodates the new ways of working in the business domain. The occupants are living in a house turned sideways, requiring extensive and expensive refurbishing, where walls are now floors, and doorways may be wide but also too low.
In this article, we focus on describing the antipattern in bespoke / legacy systems. However, interesting examples can also be found sold as commercial-off-the-shelf (COTS) where the Tilted House-effect leads to implementation failures or costly maintenance due to the misfit between the solution domain and its inability to map the business domain. A situation that over time will result in increasing cost for the customer and likely breaking changes in the system as not to be on the upgrade path.
Sidebar: Architectural patterns and antipatterns
A short introduction / side-bar to architectural patterns and antipatterns:
- An architectural pattern is a general, reusable solution to a commonly occurring problem in software architecture within a given context.
- An architectural anti-pattern, conversely, is a result of a common, recurring problem that is usually ineffective and risks being highly counterproductive. Scott Ambler3 defines an anti-pattern as “the description of an approach to solving a common problem, an approach that in time proves to be wrong or highly ineffective”.
Adjacent but separate antipatterns
It may be useful to consider adjacent but separate antipatterns / other types of misfitting in order to understand what TH is not, and hence sharpening what to look for. For bespoke solutions (the focus of this article) this is a Big-ball-of-mud:
A big ball of mud is a software solution that lacks a perceivable architecture. Although undesirable from a software engineering point of view, such solutions are common in practice due to business pressures, developer turnover and code entropy. They are a type of design anti-pattern. [ref: Wikipedia, https://en.wikipedia.org/wiki/Big_ball_of_mud].
Where a Big Ball of Mud relates to the inner workings of a solution, the Tilted House refers to a structural misfit in how the business is supported by / translated onto the solution. The authors hypothesize that continued investment into a Tilted House may drive the solution towards a Big Ball of Mud.
Technical Debt: A poor technical implementation of the solution domain is usually characterized as Technical Debt. The solution domain may however still be a good fit to the business domain. Conversely a Tilted House solution may have a low technical debt, yet being a misfit to the business domain. Thus they are different concepts.
Feature bloat: Adding new features to a bespoke solution will occur naturally over time and do not constitute a Tilted House. If, however, those features morph into new core functionality without re-architecting the solution (re-writing parts of the code and/or adding new specialized COTS), the solution may become a Tilted House.
Drivers for tilting
The virtue of avoiding a tilted house is not new. In fact, in his classic Mythical Man-Month, Fred Brooks wrote4: “I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas”.
So why does tilting happen? Tilting happens over time as gradual, incremental, or pivotal shifts in the business domain are supported by the solution, developed for the old business domain: The system supports an as-is or to-be business domain with a solution for the has-been business domain.
20 years ago, Claudio Ciborra5 explained how drifting occurs, and we stress that drifting in turn can lead to a tilted house if unchecked. Drifting describes “a slight, or sometimes significant, shift of the role and function in concrete situations of usage, compared to the planned, pre-defined, and assigned objectives and requirements that the technology is called upon to perform (irrespective of who plans or defines them, whether they are users, sponsors, specialists, vendors, or consultants)” (p. 85).
Ciborra points out that drifting should not be considered as a negative phenomenon per se: it can occur for both applications that are seen as successes and those that are not. He gives an example with a large Group Decision Support System within the World Bank that led to a surprising result in use. The initial goal of the application was to improve collective decision making during important policy meetings within the complex environment of the Bank, where different cultures and political interests are involved in highly sensitive investment decisions. The system offered a range of possible uses, besides the voting functionality, Ciborra notes, and observed that the variety fitted well with the daily dynamics at the Bank, with highly sensitive decision making usually being prepared outside the meetings where the decision had to be formally deliberated. Ciborra found that the users of the system tacitly agreed to keep the present practice, while using the facility only to brainstorm and focus on issues. So, the system was successful in being heavily used, but not as a decision support system. What happened was what Ciborra called drifting, and what we call a titled house.
Drifting, Ciborra argued, can be looked at as the outcome of two intertwined processes (ibid. p. 87). One is given by “the openness of the technology, its plasticity in response to the re-inventions carried out by users and specialists, who gradually learn to discover and exploit features, affordances, and potentialities of systems”. On the other hand, there is “the sheer unfolding of the actors’ being-in-the workflow and the continuous stream of interventions, tinkering, and improvisations that colour perceptions of the entire system life cycle”. The outcome of these two processes, Ciborra notes, can only be ascertained in situ, when the matching between plasticity of the artefact and the multiform practices of the actors involved takes place. Such a matching is “open, situated, and continuously unfolding” (ibid.)
As Ciborra observed, technology drifting seems to be a widespread process. The various instances of drifting unveil a variety of learning processes taking place around the innovation and punctuating its internalization into the organization, and such processes may range from improvisation to radical reform. They also tend to occur in a fragmented, loose manner. Drifting happens outside the scope of control of the various actors, and “it consists of small and big surprises, discoveries and blockages, opportunistic turns and vicious circles” (ibid. p. 88). As a consequence, many applications are not implemented at a speed consistent with the pace of business transformation while others make big jumps, but in unexpected directions, and still others zigzag.
(Editor’s Note: Part II of this article appears here.)
John Gotze (MSc (Eng), PhD (Eng)), an enterprise architecture theorist, practitioner and educator, with over 30 years of experience in the field. John has worked in parallel in academia and industry/government since the early 1990s. John is the CEO of EA Fellows ApS. He has published 5 books and numerous peer-reviewed articles.
Peter Nørregaard (MSc (comp. Sci), GDBA.), an IS architect thinker, blogger and management consultant with 25 years of experience with designing and implementing information systems. Peter has been an external examiner at the IT University of Copenhagen. Peter is Director of the architecture consultancy services in Devoteam Denmark.
