A continuation from Part 1
Tilted House – a case
This case is about transforming an insurance company into a membership company while still using insurance software.
Alpha is in the business of fixed coverage of reimbursements on well defined health services, e.g. dentist work, and physiotherapy that the company supplies for a fixed fee to its millions of customers.
Alpha considers itself a health insurance company and is indeed regulated by insurance regulations. In the market of insurance companies, it could however be considered an outlier with a business domain similar to – but not completely aligned with – the rest of the insurance industry.
Around 1990 Alpha acquired a COTS Property & Casualty insurance solution already in operation at a couple of other insurance companies.
The solution fulfilled generic insurance functionality, accessed by underwriters / customer service representatives.
Misfits when translating between business domain and solution model
One key design-choice in implementing the solution back in the ‘80ies was the mapping of the business domain to the solution model. As an example, a member was implemented as a Risk in the solution model, which gave rise to odd semantics when developers translated between the business domain and the solution model:
- Risks was able to subscribe to mailings and statements, addressed to them instead of the Party
- A Party was, as a business rule, required to be a Risk of the Party’s insurance Policy’s Agreement
Those mappings were made and the solution was put into production. While minor, in hindsight they can be considered the first steps toward tilting the solution model in order to fit the business domain.
Later in the 00’s the business domain drifted due to market developments and privacy regulations, adding to the oddities of the translation, almost to a degree nonsense:
- Risks could self-service, requiring bespoke development of brand new solution capabilities
- A Party should be prevented from insight into a Risk’s insurance events when the Risk came of age
- A Risk should be prevented from insight into insurance events of other Risks when doing self service, except if the Risk was legal guardian of the other Risks
Misfit of capabilities and flexibilities
Due to the outlier or niche state of Alpha as an insurance business there were unused key-capabilities and flexibilities in the COTS solution. The unused insurance capabilities in the solution model became stale and its flexibilities petrified over time, resulting in the increasing misfit of the solution model to the business domain.
For example, actuarial – an important capability in insurance solutions – is no longer used due to fixed coverage and fixed fee. While not in use, actuarial concepts still permeated the solution model and added to the complexity of working with it.
Another example is handling of claims where 98% of Alpha’s claims, all of low complexity, today have evolved to be handled via system integrations from health service providers, reducing the use of the claims-capability to a simplistic, automatic data import.
One core flexibility of the insurance COTS’ solution model was the ability to handle a party with multiple agreements, each agreement covering several insurance policies. When the relatively simple business domain of Alpha was mapped to the solution model, it resulted in locking one-to-one relationships between Party, Agreement and Policy.
Data-wise, extra attributes e.g. member seniority could thus be – and was – placed arbitrarily on either one. However, as Risks could migrate from one Policy to another (as families disbanded and reformed in new constellations), additional programming logic was needed to ensure correct calculation of the seniority of a member to calculate the correct fee.
The user interface did, initially, not reflect the locked one-to-one relationships and required custom development, as did related reports and user documentation.
Conversely, the solution did not accommodate increasingly important business capabilities such as self-service and customer engagement, nor the concepts of membership and families.
A range of similar misfittings between the business domain and the solution model emerged over the years. As the COTS solution did not have a capable programming model for handling such an extensive degree of custom code, the original COTS solution slowly turned into a bespoke solution.
By 2020 the misfit between solution model and the business domain had developed into a Tilted House:
- Investments in supporting the business drift toward supporting a member-centric business domain were increasingly difficult to realize in the solution model, implemented in a codebase that had more than tripled in size to ½ million lines of code. A static analysis of the code-base confirmed the issues, showing the solution had become a Big-Ball-of-Mud and further indicated vendor oversight of the code was lost during the 2010’s, making modernizing the code itself a Sisyphean task.
- Alpha’s lock-in to the solution model combined with the amount of code in the solution made refurbishing or rearchitecting the COTS solution to reflect the business drift toward membership-centric business a distant mirage.
The effect of the Tilted House on Alpha’s strategic options auth
Alpha suffered from slow and expensive digitization and few means for creating digital products for the customers. Product development was slow and a number of potential business ideas were backlogged due to cost and the prioritization of operational stability over strategic development. Alpha had increasing concerns of future entrants into the niche market and limited ability to respond.
We suggest that Alpha suffered from effects of an inverse Conway’s Law. Conway’s Law states that “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”. The inverse Conway’s law, we posit, is that existence of a Tilted House will steer and impose limits on the development of the business domain.
It could also be called the effects of an Inverse Mirroring Hypothesis. The Mirroring Hypothesis states a clear “impact of organizational design decisions on the technical structure of the artifacts that these organizations subsequently develop” (ref). Hence, we posit an Inverse Mirroring Hypothesis where the impact of hard-to-change technical structures in an IT solution impedes and limits the attainable design decisions of a business domain. A Tilted House represents such a situation. Other solution anti-patterns may similarly also contribute to the Inverse Mirroring Hypothesis.
Alpha’s response to the Tilted House solution
During a consultancy assignment by one of the authors, Alpha concluded that the solution needed to be ripped-and-replaced by a member-centric solution and has now begun a three-year double-digit M$ journey towards the goal.
Take-away: How to detect and respond to a Tilted House in a bespoke solution
Detection of a Tilted House:
- Circumstantial indications: The business domain has undergone important changes (gradually, incremental, or pivotal) over a number of years, all being absorbed by the solution without associated re-architecting activities. E.g. digital products have been sought to be implemented in the operational backbone, putting strain on the conceptual architecture in the existing solution. Changes and deployments are rare and often error-prone. Suggested involvement of business analysts.
- Financial indications: Simple changes within the confines of the business domain have over time had a high and increasing development cost compared to industry peers. Suggested involvement of business architect / analyst and use of financial data on IS investments in the solution
- Analytic indications:
- Review of how processes in the business domain are supported in the solution domain. Suggested involvement of business architect, information architect and system architect
- Architecture review of fit / misfit between business domain and solution domain. Suggested involvement of business architect and system architect
- Code-analysis by 3rd party to identify architecture risks and code complexity.
Management responses to a Tilted House
- Re-architect: Un-bolt / separate misfitted business processes out of the solution. Identify the business functionality responsible for tilting the house and, using a bounded context paradigm, move that to new specialized solutions, COTS or bespoke
- Modularize: Perform new development of business features next-to the solution instead of on-top-of or inside the solution.
- Engage customers with digital products: Carve out new customer centric functionality and place it on a digital platform. Suitable for digital transformation scenarios where a new digital platform can shield the existing operational backbone from changes in the business domain related to a new set of customer centric digital products and services.
- Rip-and-replace: Transition out of the current solution. Identifying which parts of the business domain to be supported by which COTS and / or bespoke solutions. This is recommended if the solution in addition to being a Tilted House also is a Big Ball of Mud.
As organizations take on digital transformation as a core strategic effort, they must confront their titled houses. If they continue living in a tilted house, they will experience continued challenges, lack of business agility, and suffer from growing financial burdens. The organizations must monitor, analyze and act upon their titled house indications.
References
- Ross, C.M. Beath and M. Mocker, “Designed for Digital: How to Architect Your Business for Sustained Success”. (Cambridge: The MIT Press, 2019).
- The classic book about patterns is C. Alexander, S. Ishikawa, M. Silverstein, I. King, S. Angel and M. Jacobsen, “A Pattern Language: Towns, Buildings, Construction”. (New York: Oxford University Press, 1977). Although it dealt with urban/spatial architecture, one of the most important applications of pattern thinking became computer science, where the most famous book was the “Gang of Four” book: E. Gamma, R. Helm, R. Johnson and J. Vlissides, “Design patterns: elements of reusable object-oriented software”. (Boston: Addison-Wesley Longman Publishing Co., 1995). Pattern thinking also found its way into management literature, for example with P. Hoverstand and L. Loh, “Patterns of Strategy”. (London: Routledge, 2017). See also W. Goebl, M. Guenther, A. Klyver and B. Papegaaij, “Enterprise Design Patterns: 35 Ways to Radically Increase Your Impact on the Enterprise”. (Vienna: Intersection Group, 2020).
- W. Ambler, “Process Patterns: Building Large-Scale Systems Using Object Technology”. (Cambridge: Cambridge University Press, 1998).
- P. Brooks Jr., “The Mythical Man-Month: Essays on Software Engineering. Anniversary Edition”. (Boston: Addison-Wesley Professional, 1995 (orig. 1975)).
- Ciborra, “The Labyrinths of Information: Challenging the Wisdom of Systems”. (Oxford: Oxford University Press, 2002).
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.