I received a call from a colleague, explaining that one of his clients was looking for an Agile EA to help them define a Roadmap for Database Replication. I thought “What a curious thing !”. Of course, my colleague had only heard of the opportunity second-hand, and as such was short on details. But it gives us an excellent opportunity to apply what we know so far of the TOGAF Architecture Development Model.
The first thing I recognized is that we don’t have enough information yet. If we follow the basic tenets of Practical TOGAF, and in order to develop an understanding of what the Target State might look like, we need to examine the BAIT components. In the Mind Map above, we see that BAIT stands for Business, Application, Information and Technology. Assuming the client has followed an Architectural Framework (such as TOGAF), we can infer that they have followed the BAIT path.
As we see in the model to the left, the Business Processes or Activities are handled by the Application. Riding on its own technology, say a Point of Sale device, the Application is the interface between the User and the Information. In turn, the application rides on top of specific technologies, perhaps a JAVA-based web application, which uses the SQL language to read data from the Information Store (aka database). Finally, the Information Store requires a Relational Database to structure the information held within.
My favourite line is “What business problem are we trying to solve ?”. In this case, is the need for Database Replication to support an existing capability or a new one ? Equally, is this Technical Requirement a Reaction to a problem – perhaps the client already has a Database Replication Technology, and they think it is too expensive? Or perhaps the client wants to be Proactive, offering a new Capability or Service to the Business ? What Processes or Activities are being affected ? So many questions !
The ADM tends to lump the Application Architecture and the Information Architecture together. By using a BAIT view of the Architecture, the Agile EA recognizes that the Application is the Business’s interface to their Information. The Application provides a means for viewing and performing CRUD (Create, Read, Update & Delete) operations on the Information. So is the client looking to implement some form of High Availability for the Database which serves their Application ? Or perhaps they are more interested in Disaster Recovery, in which case they are most concerned about the Recovery Time Objectives and Recovery Point Objectives. What is they are interested in having a subset of their database available in an off-premise Cloud configuration for a new Web Application ?
The Information contained in the database is of high value. It is very common for clients to replicate the data to a secondary database engine, to separate the Application operations (CRUD), from the compute-intense reporting operations. This might have implications around whether or not the client needs the Database Replication to be Synchronous or Asynchronous. Or perhaps the data needs to be transformed to a specific Data Model, such as the ARTS Data Model for Retail. The application may not support the ARTS Data Model, but the Reporting and Data Warehouse systems might, causing the data to be Transformed during the Replication process.
Supporting both the business application and the management of the information, it is not a direct interface for the business consumer. Instead, they will access the application, which will provide a view of the information. Both the application and the information ride on top of some form of technology stack. So when considering the client’s question, it is important to understand how the technology is used and deployed. Database Replication might be handled in the database itself, or perhaps in an Integrations layer, as part of an ETL (Extract, Transform, Load) job. Perhaps it would best suit the requirements to implement storage-level replication. And of course, there’s always third party solutions.
So in order to help this client, the Agile EA would need to spend some time understanding the Business Problem that is being solved, as well as understand the Application, Information and Technology architectures in their current state. After careful analysis, coupled with knowledge of any Architectural Principles, and Agile EA could help develop such a roadmap for their client.