Easy to me means not technically challenging. Over 90%+ of the enterprise integrations in my careers are tier 1 - 2 easy in the context of software engineering

Easy to me means not technically challenging. Over 90%+ of the enterprise integrations in my careers are tier 1 - 2 easy in the context of software engineering knowledge. It's usually a really convoluted form of "fill in the blanks in a form and pray it works." But these are all complicated in that you could literally take the smartest person in the history of the world and make about the same rate of progress as if you had taken a pretty average person to do the same thing. These sorts of problems tend to be related to wicked problems. For example, there's a bazillion side effects to consider, meetings to be had about "what does this field mean to you actually?," and other things that are of business importance but are a complete snore to the programmer implementing them. You're not talking about whether to use singly or doubly linked lists or which datastructures to use in an integration almost ever, but you're talking about how well it will scale from the perspective of a business and how its own rules and patterns of use work. Business algorithms might be something both hard and complicated of a topic, but unless your business is actually something technical such as algorithmic trading, scientific & technical research, etc. your business domain skill level is probably more about depth of knowledge than whether you're really smart or anything in itself. Also, SOAP was a very popular "standard" but those of us stuck in the pits of writing tons of XML-RPC SOAP code for years knows that it was hardly ever more standardized in practice than "REST" is today.