Architecture Reviews, Technical Debt, and the Cloud

The architecture review process is (or at least should be) a critical part of any IT project – especially considering the seemingly ever increasing level of complexity most IT architects face. It is a key opportunity for stakeholders to ask the ‘why this’ or ‘how about that’ questions with the dual goal of increasing their understanding as well as checking whether the architect is on the ball. It is a game of hunting down all of the critical assumptions – get them wrong and your project will be well on its way to failure.

Any architecture is built on a set of assumptions. We don’t know everything, and we need ways to limit our scope, so we use assumptions to reduce the unknowns and control our commitments. But in the process of making assumptions, we may incur ‘technical debt’. For a good discussion on the topic, you can refer to Philippe Kruchten’s excellent presentation titled: ‘What colours are your backlog‘ or Martin Fowler’s bliki. For technical debt as with monetary debt, some debt is of strategic importance (e.g., a mortgage) while others are a burden (e.g., credit card debt).

For companies considering Cloud Computing, architecture reviews should take on an added dimension: What happens if we move this application to the Cloud? Even if the application isn’t moved to the cloud, there is value in considering how much technical ‘cloud’ debt you have. The below list isn’t by any means a complete, or fully validated list, but I see five architectural areas that Cloud Computing can potentially turn into the credit card form of technical debt:

  • State management and database technologies: The default choice for almost all enterprise applications is the SQL based database, although alternative exists such as NoSQL in all its variants. Even if SQL databases appear at some point in the Cloud, they are likely to be ever so slightly different in their basic semantics. A counter approach would be to start identifying which parts of the application can leverage storage mechanism and which parts absolutely must be SQL plus ACID compliant. My guess that it is probably a lot less than one initially imagine. If you have access then I’d recommend to read the IEEE Software article titled ‘Multi-paradigm Data Storage for Enterprise Applications’.
  • Highly configurable applications have been seen as way of ensuring flexibility, but within a highly standardised Cloud environment this may turn into a liability. Complex application configurations may prove a management nightmare or just simply not supportable, so less configuration using far fewer moving parts than what’s typically found in today’s Enterprise Applications may prove necessary. This can be achieved through either auto-discovery configurations or hard-coded configurations managed through a much faster modify, test, re-deploy development model.
  • The leverage of sophisticated technologies to enrich the application functionality can be another liability. For example, Java Message Service, WebSphereMQ, or various Enterprise Service Bus implementations are typically superior in terms of communication quality to the WSDL and SOAP over HTTP combination. Yet the standardisation forces of the Internet have seen the later been the preferred in many cases.
  • Scalability is no longer just about load balancers and more web servers. End-to-end horizontal scalable is a minimum for Cloud applications – no bottlenecks allowed – and that includes the database. The truly impressive art form of database performance tuning may just not possible in the Cloud, so alternatives to big iron plus lots tuning is likely to be required (see first point).
  • And finally, almost as a way of illustrating the point, security cannot be an afterthought. Any security implementation is based on a trust model – and the Cloud changes this, as the trust we can place in a Cloud provider will be fundamentally different to the kind of trust you can place in internal departments.

As the recent CIO articles on ‘Cloud Integration’ (1, 2) highlights, there are lots of unknowns in Cloud Computing to be explored. The above list may prove to be wrong, but there is a fundamental shift in architectural assumptions from traditional Enterprise Application architecture to the new Cloud architecture due Cloud’ inherent focus on scalability, availability and partition tolerance. It’s a shift that can turn your strategic advantages into an undesirable technical debt. The good news is that companies can start to take stock of that potential debt today as part of their architectural review processes – regardless of their level of Cloud usage or preparedness – and a step towards taking our heads out of the Cloud.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s