Modernization of business applications can take many forms. One approach is doing a deep dive into the current implementations to document the current state. Another approach is to create a technical architecture of the current implementations. In the first approach, the analysis attempts to identify the business requirements as currently implemented. Followed by a strategy to migrate to some future state (i.e. migrate from a monolith to a more modular solution). The second approach identifies current infrastructure and software used. This may result in a strategy to migrate to a new platform (i.e. from “on prem” to the “cloud”). Both approaches often end up re-engineering current implementations without gaining improvements for the business.
A third approach is to create a logical architecture of the business. This provides the opportunity for the business to re-think their current processes. Creating a logical architecture frees the business from any limitations embedded in current implementations. The logical architecture provides a vision for a future state without limitations. This avoids the trap of re-implementing existing, inefficient business processes. The diagram below depicts the relationships between logical and physical environments for current and future state architectures.
The diagram shows the current logical architecture state as it sits over the existing physical implementation. The line from 2 -> 3 shows taking the current logical business architecture state and moving to a future logical business architecture. The future state logical architecture is used to create the future state physical implementation. The overall success of any future state implementation is dependent on how closely the logical architecture aligns with the physical implementation (i.e. alignment of business requirement to implementation).
Unfortunately, it is not unusual for there to be gap between what the business wants logically and the physical implementation. This gap in the implementation results in additional steps or workarounds for the business. This is not uncommon when purchasing a vendor product to perform business functions. Vendor products are based on a logical architecture on how to best automate a process. The vendor product’s “Industry best process automation” is their value proposition.
The depiction below shows a misalignment of the logical architecture with the physical implementation. This happens when the business strategy is mis-aligned with the IT development strategy. The area in between 4A and 4B is filled by manual business processes to bridge the gap between two implementations. An example of a workaround is to require duplicate manual data entry to fill the gap.
Assuming there is not a current logical architecture of the business such as business process models, enterprise data models and the relationship of data to processes. It’s necessary to analyze the current implementation to establish the logical business perspective. This is followed by working with the business to modify the derived logical architecture into some future state implementation. This approach requires a lot of expensive, upfront analysis.
Logically, you can avoid the assessment of your current implementation and start directly with the business (box 3) to define the business logical architecture for the future state. This avoids the trap of re-implementing business processes that existed solely because “that is how the system works”. Your options are limitless giving you the freedom to re-think the most efficient way to run the business. This creates a context to organize and analyze current system implementations.
A Logical IT Architecture defines the foundation your business requires to function using process to data. From a strategy perspective, the architecture allows proper prioritization of efforts and highlights dependencies. For example, a business can not sell a product until you first have a product and find a customer. This logical approach provides a broad view of your business by removing all the detail complexities inherit when analyzing current implementations.
Below lists the characteristics comparing a Logical Architecture with a Re-Engineeirng effort:
Recommendation:
Start with the business, logically layout the business processes and data. Defining the business by creating a logical architecture uses a common language (logic) understood by both business and IT professionals. This becomes great medium for the exchange of ideas while defining a future state strategy. Dependencies and foundational elements of the business become clear. This logical architecture establishes context or domains for organizing current implementations.
Use can the logical architecture to organize the deep dive into existing implementations. Use the context provided by the logical architecture to organize your teams by their domain knowledge for any necessary analysis of current state. It’s likely a lot of time and effort (i.e. money) is saved taking this approach.
At this point, you’re ready to begin to layout the strategy you need to build your future state.