the impact of Architecture on IT Portfolio management

Thinking in an 'IT architectural approach' is often seen as a hobby of perfectionists. This is caused by the 'need for speed' in coming up with 'Solutions'. However, thinking in 'Solutions' implies that we only start acting when there are problems to be solved. This is a rather passive view on the role of IT.

If you take the added value that IT can bring to the organization as our starting point, we will have to make blueprints that are sustainable for a longer period of time. The blueprints are defined and maintained in the description of the Architectures.

When we take the Architecture Grid as our reference, we can project the IT Services Portfolio on the intersection between the Business and IT in the 'Reality'.

The bigger part of the communication between the Business and IT deals with the performance of the IT Services Portfolio. E.g. availability of the service, Helpdesk support, seccurity issues, cost per unit of service, etc.

On top of the performance, the communication also deals with the content of the IT Services Portfolio. Meaning e.g the functionality and the 'functional fit' as perceived by the end-user. Often this content is the result of direct contact between the end-user and the IT developer, who is working like hell to keep his customer satisfied. He / she will have a 'Sollution' to all the 'issues' that the user comes up with. Despite all the well ment effort this results into a 'patchwork' of applications (= solutions = apps) and the workload for maintaining this 'architecture of a slum' increases to unimaginable hights.

However, when we take a little distance form the day-to-day issues and start working on the abstract models of what we want to achieve over the longer time, the dependencies between Business Processes, Data and the Technology to support them become clear.

In particular the focus on the role of Data in the Organization is crucial to the long term sustainability. From my own practical experience I know that Organizations that based their long term planning on a thorough analyses of the data in their Organization, end up with a significantly lower IT Maintenance Budget.

The Information Ownership Matrix plays a key role on the intersection between the Architectures of the Business and IT. This ownership matrix helps us decide on the decoupling points in the IT architecture, which provides for the required flexibility in IT.


It is the Project Portfolio that will make the changes happen in the reality, so the content of every project should be managed against the 'target architectures of Business and IT. It is not jus a matter of checking the requirements on the way processes will be functioning, but also on complying to Information Ownership.

The exchange of data with other components in the IT Architecture can not be based on simple 'copy and paste' solutions. This data exchange must be based on principles like: 'single version of the truth', 'role based access' and the use of 'open database connect (ODBC)' technology. This type of functionality needs to be embedded in the Database Management Systems (DBMS) layer of the architecture and not in the application layer.


When we take the role and impact of the Architectures seriously we can distinguish two area's of management attention in IT Portfolio Management :

1. Managing the Content of the Portfolio
This is usually a task that is performed by a small team of specialists that participates on an ad hoc basis in Projects. They provice input to the projectteam on long term directional matters. This team is also involved in the day-to-day communication with the (external) IT Service Provider on the content of the IT Services Portfolio.

2. Managing the Performance of the Portfolio
For both the IT Services Portfolio and the Project Portfolio this a standard management task. There are many excellent publications available on how to do this and what 'Key Performance Indicators (KPI's)' need to be evaluated.