Some of the key concerns of CIOs that I've encountered over the years have been:

• Lack of Experienced Architects

• Lack of trust in IT service vendors to provide a neutral view of the IT systems

• Lack of Architecture documentation

These concerns have negative impact on:

• Understanding the impact of new technologies in the market

• Get A neutral view of their IT landscape

• Maximise their investments in IT

The best action for them would be to hire an independent EA who can provide the following benefits:

• A trusted partner to bounce ideas off without any pressure of buying any services from them

• An experienced EA who can help them maximise IT investments by leveraging and reusing existing assets wherever feasible

• A realistic view of IT by documenting end-to-end portfolio level analysis

An Enterprise Architect usually achieves the above benefits by providing EA development and EA management services as required by the client organisation. These could be used as an ad-hoc service or as a big bang complete set of services.

EA Development Services

• IT Vision Development - Work with CIO and senior management to document the vision and build a target architecture to meet that vision

• IT Portfolio Analysis (Brownfield, Current State) - Collect all the information of the current systems and document using a standard modeling language

• Architecture Repository Design - Design the structure of various views of the architecture

• Gap Analysis And Roadmap - Build a roadmap to move the architecture from current state to the target state. Document the transition states and changes required to reach that state.

Once a target vision is developed an independent EA can help choose the right partners to realise that vision.

EA Management Services

• Migration Planning - Help managers plan the delivery of EA capabilities

• Project Document Review - Monitor the projects and guide the team as required

• Pre-Sales Vendor Selection - Help find the right vendor for each change

• Business Case / Trade-Off Analysis - Help find the right option for each change

• Market Analysis White Paper (Opportunities) - Keep on top of market changes and understand its impact of current systems

• Implementation Governance Support - Guide the teams towards an agreed vision

• Portfolio Optimisation - Identify and eliminate redundancies in the IT landscape

Companies usually deliver the IT changes by projects. And projects have a tendency to do jut enough documentation to pass any governance. Lack of time or competency drive the level of documentation. Technical resources who pretend to be architects draw boxes and arrows-based models in presentations. They add few terms that they understand or things they think business people will understand into those boxes. This may be fine to meet the project deadlines as long as everyone kind of understands what needs to be done to deliver a change.

It is difficult for teams who try to make changes to these systems once the project is over. The boxes and the arrows won't any make sense to others if they are not being explained. Some tend to mitigate this by adding text around these boxes. All these project docs are disconnected and usually no one reads them once the project is delivered.

Archimate was developed as an enterprise language to address these kind of problems. The concepts have been neatly divided into layers and the relations defined between these concepts. The advantage of this approach is to enable different architects to read back the models in the same manner. The ambiguities are considerably reduced as compared to the non-standard methods.

Apart from the ability to enable architects to communicate their ideas, Archimate also lets the organisation preserve these in a repository. This has the advantage of reducing dependency of any person and improving organisational knowledge.

Core Architecture

The primary architecture of the enterprise consists of three layers. Each lower layer is a more real representation of the elements.

Business Layer

This consists of operational aspects of the business. The main element in this layer is the role who performs the activities. This is not a replacement for the usual BPMN models. Business Analysts could use this model as a starting point to build a more detailed process models.

Application Layer

This consists of applications used by the IT to meet the business needs. These are logical view of the systems or solutions. Systems are described in functional terms and the structures that can perform those functionalities. These elements need to be implementation specific. In fact the same model could be used for different technical implementations. this is not a replacement for UML models. Application Architects could use this as a starting point to build their sequence diagrams and class diagrams.

Technology Layer

This consists of technology that implement the applications. These are physical view of the systems or solutions. It includes the technical elements of the systems. IT teams are usually focused at this layer. This is not a replacement for the more detailed infrastructure models. Technical Architects could use this to build their Visio models.

Business Strategy Layer

I've included motivation and strategy layer in this. These layers represent the intent of the organisation and why the architecture is needed.

Motivation Layer

This layer models the reasons that guide the design. This is possibly the least documented area of the enterprise.

Strategy Layer

This layer models the strategic direction of the enterprise. Some of the concepts like value streams are more documented and some others like capability/course of action may be more difficult figure out.

Strategy is a good place to start for future state models.

Implementation & Migration

Implementation Layer

This layer models the programs and projects required to realise the business strategy. This usually will not go to the individual activities of resources. PMs must make a more detailed project plan using their favourite tool (e.g. MS Projects ). This is a good model for roadmap analysis and initial planning.

PS: The model in this article is inspired by Mastering Archimate book.

Here's my high-level approach to define roadmaps :

Baseline EA

• Understand the need for this transformation

• Collect all the existing docs

• Analyse IT portfolio using industry standard techniques

• Document capability map, business architecture, IT portfolio map and core architecture models

Target State

• Conduct workshops to define a high-level vision, stakeholder concerns, IT guidelines, Principles etc..

• Conduct workshops to discuss target options

• Analyse the vision to arrive at target capability map, business architecture, IT portfolio map and core architecture models

• Document the target architecture and recommendations

• Define IT guidelines, principles and standards to guide the implementation

If the company decides to move ahead with the change, then the following approach could be taken.

Transition State 1, 2, n

• Conduct workshops with the business to arrive at intermediate transition states

• Define the agreed transition state architecture in the repository

• Support the business to define MVP for the specific change

• Support the business in building a business case for the transition project

• Update the IT guideline, Architecture requirements, standards etc to help with procurement

• Support the organisation during procurement of IT services or products

• Govern the implementation using the IT principles defined earlier

• Dispensations could be documented to enable the projects to move on

• New current state should be documented in the repository after the project goes live

API Layering can help an organisation manage changes to their systems in a more structured manner. Layering helps in decoupling the Systems Of Records and the front-office Systems Of Innovation. This layering is based on Gartner's PACE layering approach.

• System API - These APIs need to expose all the functionality of the underlying system. The data exchange should be in a canonical format. This helps the upper layer to be independent of the change in systems.

• Process API - These APIs are composed on System APIs or other Process APIs. They need to be internal to the organisation. This layer may use choreography and orchestration to build the process.

• Experience API - These APIs are aligned with the channel. They should be restricted to format changes. new formats can be easily added for any new channel or partner.

IT Principles defined based on these could drive individual projects towards the desired target state.

Few considerations when selecting a good Digital Marketing solution:

• Dynamic Segmentation - Identification of users into various segments while using your website. Profiling users could become a key input to your campaign design.

• Campaign design - Providing self-service capability to the marketeers is critical to avoid IT intervention for every minor change to campaigns.

• Analytics - A good analytics function will enable better segmentation and tuning of the campaigns.

With an increasing focus on cost reduction, Banks are preparing to digitise much of their systems.

Banks needs to consider few things when embarking on this digital journey:

• Physical Branches - Digitisation of the systems can help bring most of the process online, making it easier to transact using the mobile phones. As less people go to the branches, banks can consolidate them based on their usage.

• 3rd Party Branches - Process standardisation can help in leveraging 3rd party branches in locations where it is not feasible to keep a branch open.

• App Developers - Enabling Open Banking will help app developers in bringing innovative apps to the customers.

• Automation - Internal processes could be automated with AI/RPA kind of technology to remove any redundant activity that don't require human intervention.