When building out architecture (solution/software/integration/digital/etc architecture), it’s important to consider if the context of the architecture fits into tactical or not. What’s a tactical architecture? I define tactical architecture as “temporary” architecture that gets the business to a reasonable target state given a set of significant constraints that demand the architecture address a relatively immediate need without a significant amount of resources (money, time, workers).
When considering a “tactical state” understand that although it is often considered “throw away” it may very well not be a throw away solution. Tactical solutions will easily morph into permanent target states if you let them, and as organizations are always working through budget constraints and competing priorities this happens quite often, unfortunately.
This leads many architects and others to have a pessimistic attitude regarding tactical states but there is light at the end of the tunnel. So, as an architect armed with this knowledge there are strategies you can employ to ensure a tactical architecture that is as effective as possible given the significant constraints applied to the solution.
Tactical states are needed because they often allow us to meet business targets in a tactical hands on way quickly with less effort, however, it’s important that “architecture” is involved when considering tactical states as there still are important caveats to the architecture that need to be considered, especially, security, data governance, privacy, transition to the target state, and other governance and regulatory requirements. This means that it’s important to be wary of business teams that go off and implement tactical state solutions without the support of technical and architecture teams.
In a tactical architecture, there are still key considerations that must be taken into account, including performance, tooling, integration, master data management, and enterprise architecture alignment. Some thought needs to be put into these facets of the solution, and knowing that it is a tactical state with a possibility of becoming quasi-permanent, it’s important that these items are not just relegated to the future. Given it’s tactical nature, there are tradeoffs that can come at a cost, and it’s important that all of these trade-offs are documented and agreed upon along with a mitigation and hardening plan for the future. This hardening could include updates to the tactical solution or interim and future states that reduce the negative impact of the trade off.
When considering a tactical architecture, it’s important to consider the impact that trade offs will have over the long term, and it’s the responsibility of the architect to document and raise concerns about issues that will arise in the future due to the nature of the tactical solution. It’s important to quantify this as best as possible, so that as the tactical architecture and solution are built out, all of the stakeholders understand clearly what is at stake now and what the future repercussions are if the compromises made to the solution are not mitigated.
If these trade-offs are not handled or planned for, the business may be in for surprises down the road, including:
- When volume increases beyond the capacity the tactical solution has to service it, the solution will break down and this will translate into a negative impact to the bottom line of the business
- Data integrity issues which will require a generous amount of lead time to normalize which further may impact the business if it’s not rectified
- Lack of data tracking and reporting for analytics preventing holistic understanding of the captured or associated business data points
- Fragile and buggy technology (application code, weak integrations, and in proper tooling)
- Improper handling of private data such as personal information of your customers leads to a privacy breach
- Security breaches due short cuts with the security protocols
In consideration of the consequences of some of these trade offs (and there can be many more), there must be an adequate level of due diligence performed. Let’s look at a few examples:
Volume Surge: As your business grows or the program becomes successful, volume increases may outgrow the tactical solution and you better have a mitigation strategy by this time. Due to the tactical nature of the solution, the bottleneck may be in manpower or due to system capacity. As part of the technical architecture, it is very important to consider future volumes and how the tactical approach will handle that. Working cloud consumption technological components into the solution, ensuring that a better equipped interim or future state is in place, or the capability to add additional man power as needed are options that can be considered and weighted as part of the tactical solution delivery.
Data Governance and Privacy: In order to mitigate surprises in tactical solutions as much as possible, there needs to be additional education around data handling, privacy, and governance. Just because there may be more personal handling or storage of private data in a tactical approach (such as in an Excel file or some quasi-production database), it doesn’t mean that we throw all privacy and governance controls out the window. They still apply and there is significant risk to the business if the controls are not properly applied. As part of the solution, it’s imperative that any tactical solution meets governance requirements even, in the case of tactical, a more laboured approach to meet those requirements is necessary.
Data Tracking and Reporting: Understand future analytical reporting requirements with the business data that is being consumed. It might not make sense to build anything now, but knowing that the data is structured in a way to be consumed later for analytical purposes may be a value add for your business stakeholders.
Data Integrity: Tactical solutions can take many forms, but if one of those forms requires a lot of manual processing, you may have disparate files all over the place without any serious amount of data integrity or normalized data. This can be very bad. Although, tracking data in excel spreadsheets and emails manually allow the business to move tactically very quickly there are huge prices to pay in the future when looking add normalizing all of this data. As part of the tactical architecture, it’s important that the architect pro-actively look for opportunities that support data normalization. Some options could include looking at which technology is available at your disposal which could house the data (Sharepoint? Confluence?). Cloud and on-premise referential data management solutions can also be deployed very quickly with a user friendly interface, data constraints, integrity checking, to form part of a tactical solution that is built on top of normalized data. This structured data will lend itself to better reporting and an easier migration path to the final target state.
Tactical solutions should not be winged, and even though they are tactical, there needs to be adequate due diligence and properly considered compromises. It’s imperative that the tactical solution doesn’t get too complex, but you still need to balance it with proper architecture practices and business to create an approach that will lend itself to a smoother and more likely transition to your solutions ultimate target state architecture. It’s critical to minimize and mitigate negative surprises down the road which could have a significant negative impact to the businesses bottom line. Furthermore, it’s important that the limitations and trade offs made are clearly defined and communicated to the business stakeholders and sponsors.