Hello again. In the previous lesson, you turned a broad business problem into measurable information requirements: decisions, KPIs, source data, quality expectations, timeliness, access needs, and validation criteria. That requirements brief is the shared starting point for several professional roles—but each role asks a different question and produces different kinds of work.
This lesson separates four roles that are central to enterprise information management and cloud information architecture:
- Information architect
- Cloud architect
- Data engineer
- Information governance specialist
You will learn what each role is responsible for, where their responsibilities overlap, and how they would collaborate on the customer-service reporting scenario from the previous lesson. The aim is not to memorize job titles; titles vary considerably between employers. The aim is to recognize the work behind the titles.
Roles are lenses on the same enterprise problem
An enterprise information solution is rarely “owned” by one profession. A business might need to reduce support delays, protect customer data, improve reporting, and make better use of Azure. Those needs touch business processes, information meaning, technical platforms, and operational delivery at the same time.
The diagram is useful as a reminder that responsibilities overlap. It is not a universal job-description template. For example, one organization may use the title data architect for work this course calls information architecture; another may combine cloud architect and solution architect responsibilities in one role.
A practical way to distinguish the four roles is to identify the primary question each one answers:
| Role | Primary question | Typical outputs |
|---|---|---|
| Information architect | What information does the organization need, what does it mean, and how should it flow and fit together? | Information-domain map, conceptual models, information flows, architecture principles, target-state roadmap |
| Cloud architect | How should cloud services and platform foundations be designed to deliver the required capabilities securely, reliably, and economically? | Azure architecture diagram, service selections, landing-zone design, resilience and security decisions, implementation approach |
| Data engineer | How will data be collected, transformed, stored, tested, and delivered reliably in practice? | Pipelines, transformations, curated datasets, data models, automated tests, monitoring and operational documentation |
| Information governance specialist | Who has authority to define, use, protect, and improve information—and which policies and controls make that authority real? | Governance operating model, glossary, ownership assignments, policies, quality rules, issue workflows, control evidence |
A short version is:
Information architecture designs the information landscape. Cloud architecture designs the cloud environment. Data engineering builds and operates data products within that environment. Information governance establishes decision rights and rules for responsible use.
The roles collaborate continuously. They are not a simple relay race in which one role finishes before the next begins.
The information architect: designing meaning, structure, and flow
An information architect connects business strategy and processes to an enterprise-wide design for information. Their focus is not primarily “Which Azure service should we buy?” Instead, it is questions such as:
- What major information domains does the organization manage: customer, product, employee, supplier, finance, case, or asset?
- Which system is authoritative for each domain?
- What does a term such as “active customer” or “resolved case” mean consistently across teams?
- Where is information duplicated, fragmented, inaccessible, or poorly understood?
- Which future information flows would support the organization’s goals?
- What architecture principles and standards should guide new projects?
The County of Santa Clara’s Information Architect specification gives a realistic, broad view of the role: translating business and technical requirements into an information and data architectural blueprint, then setting standards and roadmaps for information assets.
Job Specifications | County of Santa Clara
Read the County of Santa Clara’s “Information Architect” specification to see how a real employer frames information architecture as a bridge between business requirements, information models, standards, and future-state planning.
In the Definition and Distinguishing Characteristics sections, read the role definition. Then move to Typical Tasks and scan the bullets on information-architecture standards, identifying information the organization produces and consumes, creating conceptual/logical/canonical models, and developing current-to-future-state roadmaps. Focus on the kinds of decisions and artifacts involved, rather than treating every bullet as a required entry-level skill.
What this role would do in the customer-service scenario
Recall the business need from the prior lesson: support leaders need to identify the causes of delayed case resolution and repeat customer contacts early enough to act.
An information architect might:
- Define the relevant information domains: Customer, Support Case, Interaction, Product, Support Team, and Service-Level Agreement.
- Create a conceptual view of the relationships: a customer creates contacts; contacts relate to cases; cases belong to queues and issue categories; cases may result in survey responses.
- Identify authoritative sources. For example, the case-management system may be authoritative for case status, while CRM is authoritative for customer segment and region.
- Highlight semantic conflicts—for example, whether “closed,” “resolved,” and “completed” mean the same thing in all source systems.
- Design a future information flow from operational systems to an approved analytical dataset for service reporting.
- Establish an architecture principle such as:
“Business-critical service metrics shall use approved definitions, traceable source data, and documented owners.”
This role works at several levels of abstraction. It may create a high-level subject-area map for senior stakeholders, a logical model for analysts and engineers, and a roadmap for moving from fragmented reports to a coherent information architecture.
What is outside its primary responsibility?
An information architect may recommend a direction, but usually does not personally:
- configure Azure networks, identity settings, or subscriptions;
- build and operate every ingestion pipeline;
- approve legal policy on behalf of the business;
- become the owner of all information assets.
The architect gives structure to decisions and makes trade-offs visible. The business owner remains accountable for the business purpose and priorities.
The cloud architect: designing a viable Azure environment
A cloud architect turns business, operational, security, and technical requirements into a cloud-platform design. In an Azure-focused organization, that design might address:
- Azure subscriptions, resource groups, and management structure;
- identity and access approach;
- connectivity and network boundaries;
- resilience, backup, availability, and disaster-recovery expectations;
- monitoring and operational support;
- cloud-service selection;
- cost controls and governance guardrails.
A cloud architect must understand the business need, but their central responsibility is the cloud environment and its technical fit. They work across applications, data platforms, security, infrastructure, and operations.
Titles can be confusing. Some employers use cloud architect, Azure architect, solutions architect, or technical architect for overlapping roles. Rather than assuming a title means exactly one thing, inspect the responsibilities in the job description.
In “Working as an Azure Architect,” Patrik’s Tech Lightning explains why Azure Architect is a broad title, then shows how the role translates organizational goals into a practical Azure foundation and implementation plan.
Watch the role framing for the distinction between architecture and engineering work. Then watch the practical responsibilities, focusing on discovery, governance, connectivity, identity, landing zones, operational handover, and the fact that architects often contribute to early implementation as well as design.
What this role would do in the customer-service scenario
Suppose the organization has approved the requirement for daily service reporting and faster identification of cases approaching service-level breach. A cloud architect could help determine:
- Whether the reporting solution should use managed Azure data services rather than a self-managed server.
- How the environment should separate development, testing, and production workloads.
- How users and services should authenticate.
- Which teams should have access to detailed customer or agent-level information.
- How the solution will be monitored when a data refresh fails.
- What recovery and availability level is appropriate for daily reporting versus operational alerts.
- How cost, security, and operational ownership will be managed.
The result might be a high-level Azure architecture diagram showing the cloud boundary, approved services, identity and access boundaries, data flows, monitoring, and supporting governance controls.
Architect versus cloud engineer
The boundary is not absolute, but it is useful to distinguish the emphasis:
- A cloud architect defines the technical design, constraints, trade-offs, and target environment.
- A cloud engineer usually configures, deploys, automates, and maintains the cloud infrastructure that realizes that design.
A cloud architect may write infrastructure-as-code templates or help deploy an initial environment, particularly in smaller teams. But the architect should not be evaluated solely by whether they can configure one service manually. Their value lies in making sound, explainable design decisions across the whole environment.
The data engineer: making information move and work
A data engineer builds and operates the mechanisms that make data usable. If the information architect defines the intended information flow, the data engineer makes that flow function reliably.
Typical responsibilities include:
- extracting data from applications, files, databases, and APIs;
- transforming and standardizing data;
- loading data into appropriate storage and analytical platforms;
- designing data structures for reporting and analysis;
- checking for failed loads, missing records, duplicate records, and unexpected values;
- automating pipelines and scheduling refreshes;
- monitoring performance, reliability, and cost;
- documenting technical lineage and operational runbooks.
Data engineering has a strong practical component. It combines SQL, data modeling, automation, storage knowledge, and increasingly cloud-platform skills.
The following reading contrasts data-engineering responsibilities with governance-oriented responsibilities. Its job-title descriptions are broad, so treat them as examples of common patterns rather than a fixed industry standard.
Data Management Careers: An Overview - Dataversity
Read the selected parts of Dataversity’s career overview to compare the day-to-day emphasis of data governance and data engineering: one establishes and communicates rules across domains; the other builds and maintains the technical data mechanisms.
In the Data Governance Lead section, read the governance overview, focusing on its cross-domain and policy responsibilities. Then, in the Data Engineer section, read the data-engineering overview. Skip the degree and certification suggestions for now; focus on the work itself.
What this role would do in the customer-service scenario
The data engineer might:
- Connect to the case-management system, contact-center platform, CRM, and survey platform.
- Extract agreed data elements such as case ID, case status, queue, category, timestamps, customer segment, and survey score.
- Standardize formats—for example, ensuring dates use one consistent time basis and issue categories follow approved values.
- Match related records, such as customer contacts to support cases.
- Create a curated dataset that can calculate first-contact resolution, backlog, and service-level risk.
- Schedule daily refreshes and, if justified by the requirements, more frequent operational updates.
- Add validation checks, such as alerting when an unusual number of cases lack a queue or closure timestamp.
- Monitor each run and investigate failures or data-quality exceptions.
A key distinction:
A data engineer can implement a quality check, but does not independently decide what “valid issue category” means or which quality threshold the business accepts.
Those decisions belong to the business owner and governance process. The engineer makes the control executable and observable.
The information governance specialist: making responsible information use repeatable
An information governance specialist helps an organization make consistent decisions about information. Their work is concerned with authority, accountability, policy, standards, and evidence.
This role may be titled:
- Data governance analyst
- Information governance specialist
- Data governance lead
- Data management specialist
- Metadata or data-quality analyst
The exact title matters less than the responsibility: creating an operating model in which people know who may decide what, which rules apply, and how issues are resolved.
Typical governance responsibilities include:
- defining ownership and stewardship responsibilities;
- supporting business glossaries and shared definitions;
- documenting metadata, classifications, and information lineage;
- establishing data-quality rules and issue-management processes;
- translating policy into practical controls;
- coordinating privacy, security, records-management, legal, and business stakeholders;
- monitoring whether governance processes are being followed;
- escalating unresolved ownership, quality, or usage issues.
What this role would do in the customer-service scenario
The information governance specialist could help establish:
| Governance question | Example answer or artifact |
|---|---|
| Who approves the definition of first-contact resolution? | Support Operations Manager, with input from customer-service leadership and the data steward |
| Who documents the definition and known limitations? | Customer Service Data Steward |
| Which source is authoritative for case status? | The approved case-management application |
| Can every report consumer see agent-level details? | No; detailed performance information is restricted to authorized supervisory roles |
| What happens when of cases have missing issue categories? | An issue is logged, assigned to a named owner, tracked to correction, and escalated if overdue |
| How is “support queue” defined across systems? | A business glossary term linked to source-system fields and reporting assets |
This role does not replace the data owner. From the previous lessons:
- The business owner is accountable for value, priorities, and key business decisions.
- The steward maintains definitions, context, and quality coordination.
- The governance specialist designs and supports the process that enables ownership and stewardship to work consistently.
- Technical custodians and engineers operate systems and controls.
Later in the course, Microsoft Purview will provide a practical environment for working with glossary terms, assets, classifications, lineage, ownership, and governance workflows.
One requirements brief, four distinct contributions
The customer-service requirements brief from the previous lesson stated that managers need daily measures of first-contact resolution, repeat-contact rate, backlog, and resolution time, with analysis by queue, channel, category, region, and team.
Here is how the four roles turn that single requirement into a working solution.
| Stage | Information architect | Cloud architect | Data engineer | Information governance specialist |
|---|---|---|---|---|
| Understand the need | Maps information domains, sources, meanings, and future information flow | Identifies cloud constraints, integration needs, operational expectations, and technical feasibility | Assesses source accessibility, data volume, extraction options, and transformation complexity | Confirms owner, steward, sensitivity, definitions, and decision rights |
| Design the target state | Defines conceptual structure, authoritative sources, shared terminology, and architecture principles | Selects Azure platform patterns and designs secure, reliable, manageable cloud foundations | Designs ingestion, transformation, storage, data models, testing, and monitoring | Defines required metadata, classifications, quality rules, retention expectations, and issue process |
| Build and validate | Checks consistency with the target information architecture | Guides deployment architecture, identity, observability, and operational readiness | Builds and tests pipelines and curated datasets | Confirms glossary, ownership, quality evidence, access expectations, and control operation |
| Operate and improve | Identifies fragmentation and roadmap improvements | Reviews cost, resilience, platform health, and cloud governance | Maintains pipelines, resolves failures, optimizes performance, and improves data reliability | Tracks quality issues, policy exceptions, ownership gaps, and governance adoption |
The roles often work on the same meeting or diagram, but contribute different expertise.
For example, imagine that first-contact resolution cannot be calculated reliably because a follow-up contact is not consistently linked to the original case:
- The data engineer demonstrates the technical limitation through data profiling.
- The information governance specialist helps assign ownership of the issue and documents the quality rule.
- The information architect assesses whether the missing relationship affects the enterprise information model and other reporting uses.
- The cloud architect may assess whether a new integration mechanism or platform capability is necessary.
- The Support Operations Manager, as business owner, decides the priority and accepts, changes, or delays the KPI requirement.
This is an important career insight: architecture and governance work is not merely “giving instructions to engineers.” It is structured collaboration that makes business and technical trade-offs explicit.
Avoiding common role-confusion mistakes
Mistake 1: “The cloud architect owns all data decisions”
A cloud architect decides how Azure can support the solution. They should not unilaterally decide business definitions, ownership, retention periods, or what data is necessary for a business KPI.
Mistake 2: “The data engineer fixes all data-quality problems”
A data engineer can detect missing data, reject invalid values, and automate validations. But if business users choose inconsistent categories or a source application lacks a needed field, the organization needs a governance and business-process decision—not only a new pipeline.
Mistake 3: “Governance only means compliance paperwork”
Governance includes privacy and compliance, but it also makes everyday work more dependable: shared definitions, known owners, usable metadata, quality rules, and clear escalation paths. Good governance reduces uncertainty for both business and technical teams.
Mistake 4: “Architecture is just drawing diagrams”
Diagrams are evidence of architectural thinking, not the work itself. The work is understanding requirements, evaluating options, making trade-offs, defining principles, exposing risks, and guiding a feasible transition from current state to target state.
Mistake 5: “Every organization uses these titles in the same way”
They do not. A smaller organization may have one person performing architecture, engineering, and governance tasks. A large enterprise may have dedicated specialists in each area. When reading a vacancy, focus on verbs:
- Define, model, roadmap, standardize often signal information architecture.
- Design, secure, scale, govern, deploy cloud environments often signal cloud architecture.
- Build, transform, automate, test, monitor pipelines often signal data engineering.
- Assign ownership, define policy, catalog, classify, control, escalate often signal information governance.
Building career evidence across the four areas
For a career transition, you do not need to claim experience in all four roles immediately. Information and cloud architect positions are commonly more experienced roles because they require broad judgment across business and technical concerns.
A stronger early-career goal is to build visible evidence that you understand how the roles connect. Over this course, your portfolio will gradually include artifacts such as:
- an information-domain or subject-area map;
- a current-state and target-state information architecture diagram;
- a small relational data model and SQL analysis;
- a basic Azure architecture with justified service choices;
- a data-pipeline diagram and a guided pipeline implementation;
- governance artifacts such as glossary entries, ownership assignments, quality rules, and a RACI matrix.
Together, these show that you can contribute to an enterprise information initiative without pretending that one course makes you a senior architect. They also give you concrete material for interview answers: what problem existed, which stakeholders were involved, what controls mattered, and why each design choice was made.
Key takeaways
The four roles have distinct centers of responsibility:
- The information architect designs the enterprise information landscape: domains, meanings, models, flows, principles, and roadmaps.
- The cloud architect designs the cloud platform and technical foundation that can meet business, security, reliability, operational, and cost needs.
- The data engineer builds, tests, operates, and improves the pipelines and data structures that deliver usable information.
- The information governance specialist establishes the decision rights, policies, standards, metadata practices, quality processes, and escalation paths that support responsible use.
They all begin with business needs, but they transform those needs in different ways. The requirements brief you created in the previous lesson is therefore not merely a reporting document—it is the point where architecture, cloud design, engineering, and governance begin to coordinate.
Next, you will map the evidence you create throughout this course to AZ-900 and DP-900 topic areas, helping you connect portfolio work to Azure Fundamentals and Azure Data Fundamentals preparation.