Architecture is a broadly used term and can mean different things to different people. Therefore, it is important to first define it so that we can establish a common understanding of this term before proceeding further. The term architecture is defined as the practice of designing systems, buildings, or things. In the context of technology, it refers to the practice of designing structures or systems with individual components with the intention of optimizing the function, cost, and performance of the overall structure.

Thinking in physical terms, a construction architect designing a home will architect how large each room is going to be, as well as decide on the number of windows and their placement in the room. This may also include planning where each room should be located to maximize the use of space and what direction the windows should be facing to maximize sunlight. In a nutshell, a building architect aims to maximize the use of space while keeping optimal functionality and costs in mind.

Similarly, a technology architect designs solutions by making use of the available components, considering the pros and cons of each component, overall costs, and the overall performance of the system. Of course, the desired functionality needed from the overall system and its ability to meet the business objectives will also be a critical factor in determining what individual components to use for the system. The key difference between physical and technology architecture is that most technology architecture used to be based on the waterfall methodology and, as such, required extensive upfront planning, requirements gathering, and documentation. The waterfall methodology is a linear project methodology where a project is broken down into phases, and in most cases, the next phase cannot start until the previous phase has been completed with deliverables signed off. With the advent of Agile and other methodologies, the focus has now turned toward designing solutions that are scalable and can be quickly adapted to changing market conditions. This is important because in order for a business to stay competitive in the global economy, they cannot afford to spend weeks and months updating their systems.

For enterprises, architectural needs vary depending on the needs and stage of the issue the enterprise is trying to solve. Over several years, technology professionals have realized this and have delineated architecture into multiple domains. Since our discussion topic is the role of a data architect, it would be prudent to discuss the various domains of architecture because they are interlinked and exert constraints over each other.

In the subsequent sections, we will look at why data architecture is important as well as explore the different types of architects, their roles, and some of the deliverables they are responsible for producing and maintaining. This will give us a greater understanding of the differences in responsibilities and an appreciation of how the type of architect fits into the architectural puzzle of an enterprise.

Architects have been around for as long as business systems. They may have had different titles over the years, such as systems analyst, technology analyst, and the like, but fundamentally, they have always designed systems that are scalable and efficient. Today, the titles have become more refined and there are multiple types of architects specializing in their own domains. Understanding each of these is important because it will help us have better communication with them and enable us to bring other stakeholders on the same page as well.

Business architect

Business architects are concerned with identifying how value can be created for internal and external stakeholders of the enterprise. This usually involves producing strategy documents, process maps, capability maps, and commonly used business terms within the enterprise or the industry in which the enterprise operates.

Data architect

Data architects are the key topic of this book. Of course, they are mainly concerned with data: how data is organized, how it is moved internally or externally, and how it can be made accessible to users when it is needed. Data architects create data models and make decisions on how data will be stored, consumed, and archived. Some data architects will also analyze and communicate how insights and intelligence can be derived from data that can be useful to stakeholders. Typical deliverables include data models, data definitions, the flow of data, and integrations.

Solution architect

A solution architect is concerned with designing systems that deliver business value to stakeholders. Working closely with Business Architects (BAs), they ensure that the solution will provide the business value that the business requires. One of the key responsibilities of solution architects is to identify the most optimal technology that will meet business requirements. This can include packaged software such as Salesforce or designing custom solutions from the ground up. Deliverables for this type of architecture include functional and technical design documents, system landscape diagrams, and the actual software that's delivered in line with the design that the architect puts forward.

Domain architects

These are architects that have expertise in a particular domain of technology. For example, Information Security (IS) architects, technology architects, and cloud architects have very specific expertise in their respective areas and are considered domain architects. A Salesforce Certified Technical Architect (CTA), although required to have a broad knowledge of certain areas, are experts in implementing Salesforce solutions.

Information security architect

The IS architect has been becoming more important as data integrations between systems become common and cybersecurity becomes critical for enterprises to protect their data and, by extension, their reputation. IS architects are responsible for designing, implementing, and maintaining security solutions that can protect the organization's network and hardware. They regularly conduct different types of testing to identify vulnerabilities and proactively fix them before a security incident materializes. In cases where the organization's security is breached, they work on a root cause analysis and identify fixes to remediate those vulnerabilities.

Technology architect

A technology (or infrastructure) architect is concerned with the physical infrastructure needed to enable organizations to deliver their software applications to their stakeholders. Servers, networks, and cloud-based Infrastructure as a Service (IaaS) fall into this category. Their responsibilities include the following:

• Designing and implementing the infrastructure solutions needed by organizations
• Supporting the hardware needs of projects in an enterprise
• Monitoring production environments to ensure that they are running optimally by monitoring certain attributes such as throughput, latency, and redundancy, among others

Deliverables include network diagrams, server-to-server diagrams, and others. With the advent of the cloud, another type of architect that's gaining traction is the cloud architect.

Cloud architect

These architects are mainly concerned with an enterprise's cloud strategy and its implementation. Like technology architects, they are concerned with implementing cloud solutions that can support software that runs on the cloud. The key difference between technology and cloud architects is that traditionally, the former has been more focused on on-premises systems whereas the latter has been focused primarily on cloud solutions. Salesforce, for example, runs entirely on the cloud and although customers don't have to be concerned with how that cloud is implemented, maintenance schedules, and security patches, Salesforce has internal resources that focus on maintaining the cloud infrastructure, ensuring that it can meet the needs of its customers. Cloud architects are also change agents as they must be able to effectively communicate the benefits of using the cloud and be knowledgeable enough to address the questions and concerns that people not so familiar with cloud technologies have.

Let's look at why data architecture is important and what its benefits are.

A common mistake that rookie software developers make is to jump in and start writing code, thinking that the design can be modified later to fit requirements. Sometimes, they may refer to this as Agile thinking and approach. However, this is a fallacy as the data model, once defined, will be used as the foundation upon which other required business functionality is built; it is usually not straightforward to make changes to it quickly.

Let's take an example of an integration that pushes data from an external webinar system into a Salesforce Campaign Member object. Here, the webinar system takes the amount of time a person watched the live webinar and records it as a percentage. The developer has created a custom field of the number type called Webinar % Attended on the Campaign Member object. This field will only accept a number and therefore rejects any letters or special characters.

When the integration is run for the first time, it errors out because the webinar system is sending the percentage attended with the special character, %, and Salesforce therefore rejects it. This is a simple example to demonstrate how the data model needs to be well thought out and designed, not only considering the business requirements, but also understanding system functionality and limitations. In this case, the business doesn't need the values in the Webinar Completed field to make any calculations, so changing the field type to Text will work. In most cases, though, a change like this would require a thorough analysis of impacts on existing functionality and integrations and this can be a time-consuming effort.

Moreover, owing to the large number of systems that are now used in an organization, the sharing of data between these systems (that is, integration) has become crucial. Proper data architecture can avoid costly mistakes such as integrating two systems only to find out at a later stage in the project that there are technical limitations on how often the data can be moved between the two systems.

Important note

In architecture, decisions made earlier affect decisions made later. For example, should a Team Member-related list, intended to record team members working on the lead, be a lookup or a master-detail relationship? These are important design decisions to consider upfront as a change during build, or worse, when the application is in production, can be costly. For example, a decision to change from a multi-select picklist to a single picklist when the app is in production can lead to data loss. Consequently, our earlier decision affects decisions we will have to make surrounding the subsequent data loss.

Another consideration for data architecture is data security. Nefarious individuals or state-sponsored actors understand the value of data, and they look to exploit vulnerabilities for their own advantage. Data architecture ensures that the proper security processes and techniques are applied to the data when it's at rest or in transit. Modern data architecture also needs to conform to data protection regulations such as General Data Protection Regulation (GDPR) and California Consumer Protection Act (CCPA).

Organizations recognize the value of data and derive insights from it. Moving data from one system to another is not done in vain, rather, there are clear business objectives that are to be achieved. The most common of these objectives is decision making based on hard data. Proper data architecture will take into account how data from a multitude of systems can be brought together to meet the operational and analytical requirements of the business. An intense topic of interest these days, which we will discuss in the upcoming chapters, is how to achieve that single, unified view of the customer commonly referred to as Customer 360, and data architecture plays a key role in that.

The benefits of data architecture

Having discussed the importance of data architecture, let's look at some of the benefits it offers:

• It sets the stage for discussion and easy communication with different stakeholders: Creating a data architect diagram can facilitate discussions with solution architects and Business Analysts (BAs). It also facilitates getting approval from security teams that are concerned with how data is utilized and the boundaries it's going to cross; for example, a multi-national organization that has multiple legacy Customer Relationship Management (CRM) systems will want to address how data is going to move and be stored across continents in consideration of compliance with the General Data Protection Regulation (GDPR).
• It plays a vital role in driving non-functional requirements (NFRs): NFRs are related to the quality of the system being designed, such as performance, usability, and maintainability. Considering maintainability, for example, if the architecture is well defined, we will be able to enhance our application with relative ease compared to when the architecture has major flaws and in certain situations may require a complete redesign of the application, which is a costly and time-consuming endeavor.
• It enables change management: Change is inevitable. Now more than ever, internal and external forces are driving change at a rapid pace. Internally, enhancement requests, new business processes, and technological changes drive this change, whereas externally, raw market forces such as competition, geopolitical changes, and regulatory policies can drive this change. Having a well-defined data architecture that is properly documented and uses commonly understood language and standards enables stakeholders to respond to change quickly.
• It enables fast ramp-ups: Part of the change that we discussed in the last point also applies to changes in resourcing, meaning people in the company come and go. Having a good architecture established can be very helpful in training new personnel. Take the example of a new hire who joins the support team of an AppExchange partner that sells a popular recruitment app. Having the data model and reviewing it with the new hire can cut short the time needed to ramp up the resource to provide quality support to their customers.
• It is reusable: If an architecture was used once for an application and it was successful, it can be easily adapted by other areas in the enterprise or used for similar-natured projects in the future. Architecture work is intense and time-consuming and for large projects, it requires a lot of collaboration with multiple stakeholders. Reusing architecture eliminates or reduces the need to put in the same level of effort as the first time and this alone can translate into hard dollar savings for an enterprise.

There is also the quality aspect: when you are reusing your architecture the second or third time, you will be thinking of further improving it rather than rethinking the architecture from scratch. Over time, this cycle of continuous improvement can lead to an architecture that will start to be accepted in the company as a reference architecture. More and more, projects will start to adopt it, or the Enterprise Architect (EA) may mandate it as the starting point for designing other projects.

Having learned about the importance of data architecture and its benefits, we will next discuss in detail a data architect's responsibilities in the next section.