Architecture Makes Decisions Easier

When I previously referred to architecture, I implied an engineered approach to solving a complex, multi-faceted issue. One of these issues has to do with making complex decisions about information we do not always have accessible or know what will happen.

Take for example how granular should a service be in a Services Oriented Architecture [SOA]?  I have been involved in the development of over a dozen SOA’s and in each the granularity was different (with similarities of course). The definition of UOW defines the lowest level construct and then we have to decide should we have CRUD (Create, Read, Update, Delete) services individually or have one service for this UOW element, or a combination (create & update, read, delete).  Composite services combine together UOW’s into a business process (choreography, governance, orchestration and correlation) and presto – the services architecture works.  My take is to decide based upon the business architecture – number of required transactions, types of transactions, etc.

The speed of a systems response to a query can be calculated usually in advance of development with architecture, experience and some level of guestimation.  So when building an SOA, a ‘single truth’ in the way of a centralized (or distributed) Integration Operational Data Store [IODS] is the right way to go in my opinion.  You have to build the integrated data architecture to move along the Enterprise Service Bus [ESB] anyway so why not extantiate it and reap the benefits of a persistent store that can optimized for speed of read.  Simply build an IODS with a designed data model (3NF) and have a data warehouse with the identical model.  Have the IODS be a current state data store (updated) and the warehouse include history (inserts) and presto – you build an SOA and gain Business Intelligence constructs for FREE!  You never know what you can learn from information until you have it!

Another example is should we adhere to ACID (Atomicity, Consistency, Isolation and Durability) or BASE (Basically Available Soft state and Eventual consistency) when defining data constructs?  This is a more completed debate over distributed transactions and the need for speed vs. the need for a ‘single truth’.  A commodities value is directly proportional to its availability, a BASE advocate would note – relax consistency to buy availability, relax isolation to buy scale.  This is based off of the premise that having a quick answer that isn’t 100% up to date is better than a slow one that is not entirely accurate (or no answer at all in the case of a down system or data service). My opinion on this is that there is a continuum and ACID should be the model to strive for (in most cases – there are cases where BASE makes sense as well) and I have seen ACID work even highly scalable so that all transactions are available and fast – you just have to design for it – like having a replication engine across the globe so that localized stores propagate information uni-directionally from working time zones.