Understanding Integration Requirements

Chapter 6 of Integration Architect, Part 1: Understanding Integration (See). Previous: Understanding the System Landscape · Next: Integration Patterns.

Chapter 5 drew what exists: the boxes, the arrows, and the inventory behind them. This chapter asks what the business needs from each arrow. The business will tell you some of it, in its own words: “when the opportunity closes”, “every night”, “real time would be great”. The rest, you have to find: how many, how soon, how sensitive, where the data may go, and what’s already in the way.

That’s the job this chapter teaches: turning what the business says into requirements an integration can actually be built to. It’s where the architect earns the title. Get the requirements right and the pattern almost picks itself. Get them wrong and the best tool in the world won’t help.

Steve Trucking runs through every module, with a few “what if” numbers where the scenario doesn’t say, labelled as such.

The ideas in this chapter

• Functional is what it does; non-functional is how it has to behave. The business asks for the first. The second, logging, errors, uptime, volumes, residency, is usually implied, and nobody will volunteer it. Discover the system on the other end yourself: its API, version, sign-in, change rate, tech stack and uptime. A monthly weekend outage found before go-live is a queue in the design; found after, it’s a weekend of lost orders.
• Listen for the shape before you think about a tool. Who starts the action, the source and the target, and how soon. Real time is synchronous: someone waits, and it’s the hardest to fulfil. Near real time is my name for the space in between, and it’s usually what “real time” really means. So ask one question: does someone wait for the answer?
• Steve’s Number of Zeros. When nobody will give you a number, throw numbers at them until they commit to the zeros. Convert to transactions, records and bytes per second, over the activity window, at the busiest season. Count transactions and bytes separately: they behave differently. Then run it again for three years out. Do your math early.
• Classify the data on every arrow. Start with the company’s own language of data, then map it to Salesforce’s sensitivity levels. The level decides what may leave, who may receive it, and what goes in the log. The best protection for a field on an arrow is not to send it.
• Success, growth and the law. A CRM succeeds when it meets the business requirements and people use it: a system nobody uses is useless. Plan for 30% growth a year when nobody has a number, and watch the child records multiply. Mark the residency zone of every system, and never send data across a zone without knowing what you’re sending.
• Constraints are already on the landscape. The other system’s capacity, Salesforce’s API allocations shared by every caller, what the network lets through, the windows when it may run, and the team that will keep it running. And once you choose a mechanism, its own limits too.

The path through this chapter

Six modules, each standing on its own.

1. Functional and Non-Functional Requirements. What it does and how it has to behave; discover the other system; what goes in the logs; where the data lives; and a checklist for every arrow.
2. Listening for the Shape of the Integration. The action, the source and target, and the timing; real time, near real time and batch; every flow behind one need; and from shape to pattern.
3. Steve’s Number of Zeros. When nobody will give you a number; four units; transactions and bytes; people are traffic too; the activity window; and three years out.
4. Classifying the Data. The company’s language; the exam’s three words; where Salesforce keeps it; what each level means for an arrow; only what the arrow needs; and the logs.
5. Success Factors, Growth and Regulation. Meet it, then get it used; 30% when nobody has a number, and the child records; the obligations that come with the data; and what crosses the line.
6. Constraints. Capacity; allocations; the network; time and people; and then the mechanism’s own constraints.

The reference page Steve’s Number of Zeros for Integrations has the method, four worked examples and a calculator to use in the meeting.

Each idea here is a seed. Chapter 7 turns the shape into a pattern. Part 2 picks the mechanisms, each with its own limits to match against this chapter’s numbers: Salesforce as a provider in chapter 8, as a client in chapter 9, bulk in chapter 10 and events in chapter 11. Protecting what you’ve classified is chapter 12, and watching every arrow is chapter 13.

When you’ve finished, check yourself with the chapter study guide: a checklist for the exam, the habits beyond it, the words to know, and a few questions.

What an architect decides here

• For every arrow, the functional requirement in the business’s words, and its non-functional requirements as numbers wherever they can be.
• The shape: who starts it, from where to where, how soon, and whether anyone waits.
• The numbers the business has committed to: transactions, records and bytes per second, in the activity window, at the peak season, today and in three years.
• The level of every field each arrow carries, what may leave, and what’s masked or never logged.
• What success means for this CRM, the growth rate for every flow, which rules apply to which data, and the residency zone of every system.
• The constraints: the other system’s capacity, the allocation each caller spends, the network, the windows and the team, and later, the mechanism’s own limits.

Beyond the exam: AI changes the requirements, not the responsibility. An agent is one more caller, and the person asking it is waiting, so its calls are effectively real time. It spends allocations, it reads classified fields, and it runs somewhere, so it has a residency zone too. And AI is good at a first draft of the requirements, but it gives you what you ask for, not what you forget to ask. Each module ends with what AI changes.

Explore

• Salesforce Architects, Integration Patterns (opens in a new tab): synchronous and asynchronous, and the patterns named for the shapes.
• Salesforce Architects, Well-Architected: Trust (opens in a new tab): the obligations attached to your data and jurisdiction.
• In the Data Architect course, Classify, Then Protect: the same levels, at depth.

Next: Integration Patterns