IT architect roles

Copyright 2017 Graham Berrisford. One of about 300 papers at Last updated 18/12/2018 12:05


What does an "IT architect" do?

This research paper quotes answers found in the job market.


Preface: IT architecture in the domains and levels of enterprise architecture. 1

Enterprise-level IT architects. 2

Solution/software level IT architects. 2

Example 1 – enterprise level 3

Example 2 – solution level 3

Example 3 – solution/software level 4

Two more example roles. 4

Footnotes. 5

What does an IT architect NOT do?. 5

What is the difference between “platform service” and “IT service”. 5


Preface: IT architecture in the domains and levels of enterprise architecture

Business planning is what business directors and business planners do.

Business planning is informed and supported by business system planning, which enterprise and business architects do.

Up the 1970s, business systems were often analysed and designed by people in an Operational Research department.

At the start of the Information Age, many Operational Research departments were absorbed into IT departments.

Because IT departments were created to support and enable business processes that create and use business data.


In the 1980s, Enterprise Architecture (EA) emerged.

It grew out of IBM’s "business system planning", James Martin’s “information engineering” and other approaches.

All these approaches urged enterprises to take a strategic and cross-organizational view of business processes and data.

And since the PRISM report of 1986, architecture has been divided into four domains - reflected in the columns of the table below.

The table below positions EA as a high-level cross organisational and strategic view of business systems.

And it positions IT architecture in the yellow sections to the right.







Infrastructure technology



Business roles & processes,

standardisation, integration

and road maps

Business data

standardisation, integration

and road maps

Business application portfolio

standardisation, integration

and road maps

Platform technology portfolio

standardisation, integration

and road maps



Outline design of a solution’s

required processes

Outline design of a solution’s

data architecture

Outline design of a solution’s

application(s) architecture

Outline design of a solution’s

IT production environment



Detailed design of

processes & use cases

Detailed design of

data stores and flows

Detailed design of

software architecture

Detailed design of

IT production environment


Every enterprise has to work out for itself how its roles cover the cells of the table.

It is usually expected that IT architects are concerned with platform/infrastructure technologies, and the deployment of applications to them.

Enterprise-level IT architects

These are concerned with the enterprise-wide information technology portfolio.

They set general principles and standards and govern the use of technologies by architects at lower levels.

They define strategic road maps that the span the life cycle of each platform technology’s use in an organisation.

Typically, they are reasonably well-versed in one or more of the following.

·         Client-side technologies: desktops, laptops, other mobile devices.

·         Server-side technologies: virtual and physical environments, clusters, load balancers, hardware platforms, mainframes.

·         Network and communication technologies – office LANs, extranet, VPNs, internet gateways, media and unified comms.

·         Data center technologies: racks, heating, ventilation and air conditioning.

·         System management technologies -  monitoring of hardware and software infrastructure, networks and IT services

·         Security technologies – identify management, encryption, firewalls.

·         IT services management technologies: help desk, configuration management.

Solution/software level IT architects

These are concerned with the infrastructure needed to support specific solutions and applications.

They may follow a process of this kind:

·         Establish requirements

·         Identify risks, issues and constraints that may affect the architectural design.

·         Engage with business people to understand the above and ensure sponsorship.

·         Define an architecture to meet requirements, under constraints, while managing risks.

·         Create an implementation and migration plan.

·         Govern detailed design and implementation against requirements and plans.

·         Work alongside all involved until the architected system is operational.


IT architects may get involved in the design of applications in these ways:

·         The deployment of apps in production and other environments, and porting of apps between environments

·         The provision of client devices, servers, storage, network, connections etc.

·         Determining the sizes and numbers of technologies, perhaps using performance data from similar systems.

·         Addressing latency, throughout, availability and disaster recovery, backup, failover and restore.

·         Compliance to security requirements for confidentiality and availability.


The IT architect may have to persuade people these are important matters, which must be paid for.

Example 1 – enterprise level

The example is pitched at the enterprise level.


I am one of 2 IT Infrastructure Architects, referred to as the IS Infrastructure Network Architect. I will

1.      review EA Technology Solution Reviews that are basically a composite of questions that the Architecture Group wants to see answered before any development, installation, or major modification to the Existing Architecture are made, as will all other Architects in our program.

2.      focus primarily on anything that will result in changes to the Network Infrastructure. (i.e. IPv6, Firewalls, IDS/IPS, Switches, Routers, VPN, Network Design, Management/Monitoring tools, etc.).

3.      be looking at network technology as it matures in the industry, and be ready to prepare strategies for technology that will fit in our technology model and assist with meeting the needs of the business. We want to maintain this knowledge so that when the Business identifies new requirements that we don't have in place, they won't have to wait forever for the Infrastructure capabilities to be available. We will have already done the initial research and be able to be more proactive with our response to the Business relative to providing these new capabilities.

4.      provide opinions as to whether or not new technology is a good fit for us, or whether we want to introduce it to our environment.

5.      look for redundant technologies or solutions that are already available in our environment and help keep cost down by insuring that the Business or Project recommending the change is aware of any solution we already have in place that may be able to meet their needs, and that existing solutions are looked at along with new ones to determine best path, with least resistance.

Example 2 – solution level

This example is at a lower level, and veers towards being a more general solution architect.


“My concerns are to ensure the infrastructure supports the running of applications or IT services.

And it conveys data flows (patient results, ECG graphs, X-Rays, reports) from source to destination (e.g. London to Liverpool) in the correct format.


Various technical architects, engineers and administrators (network, storage, database, servers) report to me.

I do not care about network devices, but I do care if the VPN fails or the firewalls stop the data flow traffic.

I do not care how Windows and Linux are built or managed, but I do care if they do not offer the availability or performance.

The PM handles resource allocation and client billing.

The PM rarely has the technical understanding to front a meeting or explain change requests to a change board.

I often report to program directors, give brief summaries to project boards and daily updates to the PM on progress.

I chase the PM to ensure there is a complete project plan.”

Example 3 – solution/software level

This example is clearly an IT infrastructure/platform architect working alongside project delivery.


“What I do is:

·         Establish OS and platform requirements (e.g. performance data, application information and configuration).

·         Identify required hardware and configuration.

·         Engage with application owners to ensure application environment requirements can be met.

·         Sometimes, work with application guys to help specify what apps can do meet NFRs (e.g. multi node and/or replication)

·         Ensure all NFRs have been considered by business and application architects, and all been met

·         Ensure supportability by business-as-usual and applications teams (engagement, involvement and documentation).

·         Define build and deployment processes and environments if they do not exist.

·         Ensure environment passes through all areas (e.g. test and production), ensure issues are re-mediated.”

Two more example roles

Two more role titles that might reasonably be pigeon-holed in the role grid as shown below.







Infrastructure technology

Enterprise architecture

Operations Architect

Solution architecture

Services Architect

Detailed design



Operations Architect

Plays role in Continuous Service Improvement area of ITIL, including ongoing assessment of architectural fit of existing applications, infrastructure and services.

Recommends incremental investments to cope with:

·         changing demand profiles (e.g. user or transaction growth);

·         experience of post go-live snags (integration with Problem Management);

·         end of service issues, platform migration issues, capacity management and total cost of ownership perspectives.


Services Architect

Defines architectures that are focused on orchestration and consumption of external services, particularly in Cloud context, in order to create solution architectures on projects.

Focuses on:

·         specification of integration between internal and external services,

·         specification of requirements for contracts with the external service providers and

·         integration with enabling toolsets for (e.g.) Security, monitoring, data integration.


What does an IT architect NOT do?

IT architects:

·         rarely engage with the business regarding functional requirements.

·         have no influence over business process or business data definition.

·         have little need for business, data or application architecture techniques.

·         never see use case definitions; and do not define software architectures.

·         are not usually employed in a software development or deployment project team.

·         understand surprisingly little of databases and middleware.

·         may deploy a database, yet understand little of how data is structured, stored and accessed.

·         may deploy middleware, yet understand little of how messages flow within and between applications.


What is the difference between “platform service” and “IT service”

A platform service is what an infrastructure technology provides to a business application.

E.g. database query, transaction commit, transaction roll back.


This table defines, for example, one IT service that an IT service management organisation provides to other business departments.



App server administration


Have your application server administered by Managed Services.


Authorised expense account

Application server


University departments and units


Network Infrastructure

Managed Services’ Data Center power and cooling


Supported Service Hours: 24 hours a day, excluding the maintenance hours listed below
5:30 A.M. to 7:30 A.M. Monday through Friday
5:30 A.M. to 10:00 A.M. Saturday
5:30 A.M. to 12:00 P.M. Sunday.

Where to go for help

Email apphosting@managedservices


£1000 setup fee, plus monthly charges negotiated on a per-customer basis and start at £300 per month.

Date created

August 2, 2006

Date of last review

August 12, 2008