The world has infinitely more stuff to be "done" nowadays. At least in the sense of building/running an institution that uses technology, there are many roles that are involved in making things work. The world of IT and technology in general makes the speed and variety possible. We now have a platform of IT that is globally scale-able if we can put some new thinking to the old problems of "getting things done".
There are great organizations that do this well, and they use "modern" IT principles to achieve this.
Fundamental to engineering a modern IT (or infrastructure organization) are the three roles of Architecture, Engineering and Operations. Some would say Architecture is encoded Engineering-history, but for now, we will keep them separate.
The popular definitions for these roles are about "output" delivered or the "domain" of discourse. The personality drives that determine the actual performance are not discussed, as far as I can see, in a holistic fashion in these definitions.
To make the point clear: there is an existential pleasure in being that applies to each of these roles. Without understanding that, we run the risk of putting in a round peg in a square hole when we move people around these roles, or even allocate people to these roles. People aren't fungible, but the dry definitions can lull us into entertaining that very thought as we "scale" the world.
So, I want to make a case for an interpretation that goes to the heart of what it means to do those functions as a "human being".
To me, it all starts with the human faculty of being one with patterns.
We are all pattern machines. We imagine, dream, deign, conceive, abstract, create, build, preserve, destroy, encode, decode, consume, grow, deplete patterns and pattern pools.
NOTE: In the below roles, these are styles of functioning, and ways to behave. It is not something that IDs a person (someone can engineer one thing, support/operate another, and architect yet another thing).
Architecture is the mindset that helps define hierarchical patterns in a domain of activity. An architect places the fundamental functional pieces of the pattern puzzle up in the air, so that the assembly into a workable "thing", "product" or "solution" is easier than assembling it all from first design principles. In that sense, they set the "meta pattern" to generate viable patterns.
Engineering is the systematic improvement to deliver a better solution for your audience, customer, business (your constituency). An engineer makes, builds patterns and pattern machines. They can use architecture principles, or take the help of a mature operations team to reduce the workload, but essentially, the mindset of an engineer is to build patterns.
Operations is the discipline of maintaining the promises you made to your constituency, and keeping them well heeled. An operations person remembers and preserves patterns that were promised. They keep the "lights on".
How do we put them together?
Although that seems like orthogonal sets of things, combinations can exist. An operations person can absolutely engineer a better process. An engineer can, and often must, operationalize every bit of context that they can, so that they can reduce the amount of engineering they need to do, as well as the kind of engineering they need to do.
As an example: you can maintain a business critical function by operating it without any change, or by engineering the operations once in a while so that you save effort and money, or by architecting a continuous process of engineering so that you can operate better and better over time.
Another example (for hiring): If you take a person who predominantly wants to preserve patterns, and place them into a creative role (operations mindset in an engineering role), they will succeed up to a point. But their solutions will lead them into certain types of "architecture" that may prove to be "too slow" (but "entirely reliable in a well constrained environment"). Examples are engineers working on traditional enterprise like solutions in version 10 (not version 1) - where the architecture of infrastructure is fairly high quality and fixed, the patterns that bind the solution are mostly fixed. Most of the greatest engineering work here will be in improving the operational quality. Fundamental creation engineering is going to sound "risky" and may not be properly funded, even if it is the right thing to do.
If you want to engineer, find the place where you can build patterns.
If you want to deliver excellent operations, find the work that allows you to guarantee and deliver a bounded promise.
If you want to architect, find work that allows you to specify the principles to create and preserve building blocks.