Practical Guidance for Creating IT Architecture Roadmaps

enterprise architecture strategy

By Rohan Malkhare, Senior Software Architect, JYSK

Amidst a rapidly changing technology landscape, enterprises need to embrace and plan modernization of their IT architecture with the goal of retaining and enhancing business competitiveness. An important aspect of this planning exercise is the enterprise IT architecture roadmap.

Contemporary IT architecture literature is often found to be lacking in practicality and applicability for small-to-medium scale enterprises, non-profits, minority-focused businesses and others that may not necessarily have the wherewithal to hire an expensive team of architects but nonetheless need pragmatic guidance on developing roadmaps for transforming IT architectures in support of their organizational objectives.

This article uses simplicity and brevity to offer experiential guidance for enterprises to derive their own IT architecture roadmaps and is especially relevant to IT departments of underserved organizations such as the aforementioned ones.

Architectural perspectives

Although it is not necessary to have an explicit architectural division in the roadmap, it is always useful to bear in mind the four typical perspectives of enterprise architecture:

  • Business architecture represents the individual business activities or processes of the enterprise, the high-level information shared between the processes and the relevant stakeholders that include enterprise partners and customers.
  • Application architecture represents the applications that execute the business processes as well as the supportive IT tools. These may be commercial off-the-shelf systems from third-party vendors (COTS) or custom-built by development teams. The applications may be deployed on a cloud provider such as Azure/AWS, on-premises servers or shared between the two in a hybrid mode.
  • Data architecture represents the enterprise data elements, storage mechanisms, policies such as usage restrictions and the data flows across the enterprise, partners and customers. Data may be transactional, purposed for Business Intelligence or archived for historical purposes. It may be stored on on-premises servers and/or the cloud.
  • Technology architecture represents the infrastructure including on-premises equipment for storage/networking/computation, hardware such as security gateways and provisioned assets on the cloud.

Transformation Evaluation Criteria

As a first step in planning modernization of any individual IT system, it is important to have useful evaluation criteria to determine the value of executing a transformation option. Three simple evaluation criteria may be used wherein answers should be sought for some key questions. Below are the evaluation criteria and a few important questions associated with each.

  • Costs:
    1. What are the projected upfront and ongoing costs of executing the transformation option? This should include workforce, hardware and software costs.
    2. How do the projected costs compare with the current costs?

 

  • Benefits:
    1. Is the enterprise getting any competitive advantages from the transformation such as increased customer access/satisfaction, cost savings and/or better process efficiencies?
    2. Is there new functionality that maps to the future desired state of business processes?
    3. Is there better performance on system parameters such as throughput, security, availability, scalability etc.?
    4. Are obsolescence issues such as expiring vendor support for the current system being addressed by the transformation option?

 

  • Potential Risks:
    1. If there are development and/or customization requirements, are there sufficient workers with the right skills?
    2. Is there enough redundancy for workers in key roles?
    3. Will the transformation have adequate shelf-life?
    4. Is there any risk of incompatibilities being introduced with partner systems and/or regulatory compliance requirements?

The costs, benefits and potential risks of executing a particular transformation option should be clearly understood and incorporated while crafting the roadmap.

Structure of a simple roadmap

The enterprise IT architecture roadmap consists of high-level diagrams as well as descriptions. The diagrams, some of which are referenced in this article, are quite ubiquitous and publicly available online resources can be used for assistance in their development.

The roadmap should contain, at a minimum, seven major sections rendered in a sequential manner.

1.    Stakeholder analysis

This is primarily a mapping of all the key personnel that participate in the enterprise business activities with their respective roles. A stakeholder power-interest matrix is useful in representing the stakeholder relationship to IT efforts and should be necessarily developed as a part of this analysis.

2.    Current business processes

This represents all the fully and partially automated business processes of the enterprise.

Value-stream map diagrams for individual business processes and value-chain diagrams for collective business activities are excellent representations for this purpose.

3.    Current state of enterprise IT architecture

This represents the architectural details of current enterprise applications, tools, data as well as infrastructure. Technology infrastructure diagrams, Deployment diagrams and Data flow diagrams are useful architectural representations in this section. At a minimum, following details should be included:

  • Structure of on-premises hardware such as servers/virtual machines, storage, network connectivity as well as any virtual infrastructure on the cloud.
  • Listing of each system, it’s mapping to the relevant business process(es), whether the system is custom-built or a COTS.
  • Deployment details of each system.
  • Data flows between systems, data storage mechanisms and policies.
  • Upfront and as well ongoing costs for each system as well as the total costs.

4.    Stakeholder Surveys

It is important to conduct anecdotal or formal surveys of stakeholders on the efficacy of the current systems, pain points, their perceived business value and wish-lists for the future. The results of such surveys should be delineated in this section.

5.    Future state of business processes

Envisioning new business processes as well as updates to existing business processes is an important exercise during development of the roadmap. Results of stakeholder surveys as well as the evaluation criteria should be used during this exercise and new value-stream/value-chain diagrams should be created.

As examples, a non-profit may be missing the CRM process or a retail company may be missing logistics tracking or there may be duplicate data entry taking place across processes. The future desired state of business processes should address such issues.

6.    Future state of enterprise IT architecture

The diagrammatic representations and the overall format of the future state of the IT architecture should mimic the current state. Results from stakeholder surveys, the future state of the business processes and the evaluation criteria should be leveraged for developing the future IT architectural state. Some important points detailed below should also be included in the considerations.

  • Is there a need for new systems, either custom-built or COTS, that map to the future state of business processes? For applications and tools, consideration must be given to Buy-and/or-Build for decision-making.
  • Do existing systems need to be upgraded or replaced either with competitor systems or custom-built ones? Examples include migrating an e-commerce platform such as Magento 1 to Magento 2, replacing an ERP such as Dynamics NAV with SAP or vice versa etc.
  • Is there any layer of the application stack for any system(s) that should be upgraded or substituted? Examples include migrations from on-premises to the cloud, version upgrades of a database or a middle-tier platform such as .NET/Java etc.
  • Are there duplications across the enterprise that need to be consolidated? Examples include different departments in the company using separate project management tools, storage systems etc. that can be effectively converged.
  • Are new IT tools or upgrades of existing ones necessary? Examples include automating release pipelines through use of tools for configuration-as-code, infrastructure-as-code, tools for centralized application monitoring etc.

7.    List of recommended projects

This is a high-level listing of the series of executable projects as well as the intermediate goal-posts to transition from current IT architecture state to the future proposed state. Project management personnel should use this listing to develop detailed project plans.

Conclusion

Although brief and simple, it is my fervent hope that this article will give a strong impetus to many IT departments for commencing their own journeys towards IT transformation.