IT architect roles
Copyright 2017 Graham Berrisford. One of about
300 papers at http://avancier.website. Last updated 18/12/2018 12:05
What does an "IT architect" do?
This research paper quotes answers found in the job market.
Contents
Preface:
IT architecture in the domains and levels of enterprise architecture
Enterprise-level
IT architects
Solution/software
level IT architects
Example
3 – solution/software level
What
does an IT architect NOT do?
What
is the difference between “platform service” and “IT service”
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.
|
Domain Level |
Business |
Data/Information |
Applications |
Infrastructure technology |
|
Enterprise architecture |
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 |
|
Solution architecture |
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 |
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.
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.
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.
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.
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.”
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 role titles that might reasonably be pigeon-holed in the role grid as shown below.
|
Domain Level |
Business |
Data/Information |
Applications |
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.
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.
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.
|
Service |
App server administration |
|
Description |
Have your application server administered by Managed Services. |
|
Preconditions |
Authorised expense account Application server |
|
Clients |
University departments and units |
|
Dependencies |
Network Infrastructure Managed Services’ Data Center power and cooling |
|
Availability |
Supported Service Hours: 24 hours a day, excluding the
maintenance hours listed below |
|
Where to go for
help |
Email apphosting@managedservices |
|
Cost |
£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 |