Nobody claims to like anti-patterns, and I certainly don’t like them. In fact, when it comes to architecture and solutioning, we identify them, make sure we understand why they are bad, and then we avoid them. We help others to identify and remove them. The reasons we call certain patterns “anti-patterns” is precisely due to the consequences of using the pattern including the technical debt that is ultimately incurred. Some anti-patterns may not even have common names, but the technical debt and consequences of these anti-patterns are well known; for example, creating single points of failure due to lack of infrastructure, planning, or financial resources; or using end-user analytics data sets as sources for data ingestion into transactional systems, and so forth. Let me be clear, these and all the other anti-patterns out there are bad, generally, but of course nothing is set and stone and there are exceptions. There are also “perceived anti-patterns” that are considered to be bad or even disallowed by the enterprise for various reasons.
How could you ever even justify the use of an anti-pattern? Quite often the use of anti-patterns comes about due to neglect, lack of knowledge, lack of governance, or poor decision making. However, sometimes the anti-pattern is actually the best way forward, and in some cases challenges previously held beliefs in a good way. The case to use an anti-pattern can be made when there is an atypical inversion of benefit versus the consequences of using the pattern. However, there is a big difference between selectively and consciously making evidence based architectural decisions to use an “anti-pattern” versus just obliviously blasting out architectural anti-patterns as part of solutioning and hoping for the best – the latter is wrong
Sometime we will grudingly condone the use of an anti-pattern when we are in a bind or under heavy constraints. We may have a time crunch or a financial crunch, and thus, as architects, our wheels start to spin to creatively think about what could be acceptable. When we do this, we should think about this atypical inversion of benefit vs consequences, and how this can be used to justify the decision making around anti-patterns and technical debt. Purists have a hard time understanding this, but rationally and objectively understanding such dilemmas is key to solution architecture; “architectural purity” shouldn’t ever be the goal – the goal is to satisfy business in the short and long term. In fact, I’d even consider “architectural purity” to be an anti-pattern in itself, but that’s a topic for another article on another day.
Let’s consider some enterprise and solution architecture anti-patterns as well as scenarios that may allow us to justify them and in some cases advocate for their continued use. These examples will give starting points and help frame your thinking about how to approach the potential justification (or rejection) of anti-patterns even when these ideas are at odds with external forces or conventional wisdom.
1.Vendor-Lock in: In some circles, ‘vendor lock-in’ is seen as a defined anti-pattern, but of course there is not a clear consensus on this considering that a large number of enterprises get stuck year after year paying hefty licensing and maintenance fees to huge global software vendors. What’s important here is to consider that this can be seen as an anti-pattern that has the potential to incur huge costs, reduced long term interoperability, and significant costs to change.
Enterprise Architecture road maps should clearly articulate the use, or non-use, of vendor lock-in in relation to the use of technology that helps enable business capabilities. Solution Architecture target states should also clearly articulate software and integration frameworks, patterns, and target states in which solutions across the enterprise need to align to. In an extreme example, it’s often very hard to make and justify the case to lock into huge vendor contracts for obscure software even if a VP wants to introduce it at huge financial and human capital costs just because the VP met and became friends with the VP of the vendor at a conference and, on whim, the VP is now advocating for this “miracle” software. The EA team needs to act as a counter balance here, understand the politics and successfully navigate them, and act in the best interests of the entire organization; this is a situation where enterprise architects would likely come to the conclusion that this is a bad idea and work to get alignment on that from the broader organization, including, executives.
Of course, it is often much more nuanced than that. Consider an organization that is transitioning to the cloud; there are a myriad of cloud providers and a myriad of cloud solutions to solve the same problem. Once an organization settles on a single cloud provider (or multiple cloud providers), you’ll move into choices such as to use PaaS or IaaS and there are advantages and disadvantages to both. Some solutions may be considered to be “vendor lock-in” and maybe that’s ok and that’s justifiable. Architects should consider the advantages of interoperability between native cloud components that could be “locked-in” and require re-work if there was ever a decision to change cloud providers and the benefits (on-going cost, development cost, etc) of using these components. With this example, you can start to see how you can build a case for a certain amount of “vendor lock-in” in consideration of the short term and long term benefits of doing so; you’ll also need to include the cost, risk, and likelihood of change as part of this decision.
2.Using Reporting and Analytics Data as a Source of Data Ingestion to Transactional Systems: This hasn’t been given any kind of naming yet, but this is an “anti-pattern” too. The scenario here is when a system needs data from another system and architects decide to source that data from a reporting and analytics platform instead of designing the proper integration sources from a proper master data location. “Oh, well I know the data is in the analytics data source, so let’s just build a job to get it and pump our product list into this new system. It’s so easy”. No. Don’t do that – this is not the intention of a reporting and analytics data source.
This is where some of my earlier terminology might apply: Neglect – architect doesn’t spend enough time doing due diligence, does very surface level diligence, or there was no architecture defined at all and the integration team was left to their own devices. Lack of Knowledge – the architect didn’t understand the role of reporting and analytics or wasn’t aware of the established enterprise patterns which prohibit this type of integration. Lack of Governance – the architect made poor decisions but there wasn’t sufficient governance to keep these decisions in check. Poor Decision Making – the architect knew this wasn’t ideal but went ahead anyway with limited reasoning to justify it without considering the risks and technical debt incurred.
None of this is meant to say that designing such an integration is always wrong even if you can make a convincing case as to why it’s generally wrong. In scenarios where it might overwhelmingly seem that this is something you shouldn’t do, what if there are just too many constraints that make any alternatives very painful or unpalatable. Let’s say the product feature is required, but there is a product master data project that is currently in-flight which can’t be integrated to until it’s ready, and the true source of product data comes from a legacy application that is very complex to integrate to. Existing integrations to it are very fragile, not so secure, and the CISO has indicated that ‘security risk acceptance’ is a very difficult proposition. As you look at how to source this data, you realize that there is too much risk in using the current product source, there is a lack of intermediate product sources, but the enterprise does have a modern reporting and analytics platform in which a very difficult, but relatively reliable, integration was built to hold this product data. Thus, we end up with an atypical inversion of benefit versus the consequences of using this anti-pattern. Of course, we cannot overlook all of the reasons that this is an anti-pattern in the first place, but it will leave us with a case where justifiable evidence can be used to support this approach and allow the organization to comfortably move forward even with its flaws; long term mitigation plans can reduce the risk by integrating to a proper master data solution once it’s available and getting sponsor risk acceptance on the short term risks which may include reduced availability and less frequent data updates due to the nature of integration.
Summary
Architects need to understand risks and ensure they are mitigated accordingly. There may be inherent risk in deploying an anti-pattern or in increasing technical debt, but there are cases when dealing with considerable constraint that an architect can put together a pathway forward along with the alignment necessary in order to proceed. In other cases, the pathway forward might actually be optimal in the long term as well even if it goes against previous notions that may have been tightly held by the organization – such as in the vendor lock-in scenario or even in cases where organizations start to adopt SaaS and PaaS models to solutions when previously the organization may have had hard rules that favoured on-premise or IaaS implementations. Of course, it’s not the role of one single architect to arbitrarily change the rules about if a SaaS solution to replace on premise ERP solutions is the right approach; these scenarios require alignment with sponsors, business, executives, and enterprise architecture. However, architects are in the position to make the case to drive change across the organization even when this challenges previously held beliefs such as “on-premise gives us more control than SaaS, so SaaS is not an option” as an example. All facets of the design need to be considered, and if architects can make a solid evidence based case, they should make it and proceed to get alignment and help to drive the change required to see the enterprise into the future.