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.
It starts with the human faculty of being one with patterns.
We are difference engines for finding patterns. We imagine, dream, deign, conceive, abstract, create, build, preserve, destroy, encode, decode, consume, grow, deplete patterns and pattern pools.
Architecture
Architecture is the mindset that helps define structures and meta 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 resulting thing, product or solution is easier than assembling it all from first design principles. In that sense, they create a plan from working bits of the past combined with imagination.
Engineering
Engineering is the systematic improvement to deliver a better solution for an audience or constituency that will be better off handing the creation to you. An engineer makes and 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 new patterns and test it against reality.
Operations
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 drive real teams. An operations person can engineer a better process. An engineer must operationalize whatever context that they can so that they reduce the amount and kind of engineering they need to do.
Let's say you have a mission critical function. You are running it well. Is that good enough? You could function by operating it without any change. You could improve the operations once in a while by using design principles or engineering effort to save time and money. Or you can architect a continuous process of change so that you can operate better over time. Or you can replace the components with something that your organization can engineer from start to finish.
If you want to engineer, find the place where you can build new patterns that can solve a critical problem with the existing order.
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 observe what works, and specify meta patterns than others can benefit from.
The human angle makes for interesting approaches to mix and match these capabilities. 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. Over time, 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 solutions version N (where N is a high single digit or low double digit number). In their solution, the architecture is fairly high quality and fixed, the patterns that bind the solution are also deeply constrained. Most of the greatest engineering work here will be in improving the operational qualities. Fundamental creation engineering is going to sound risky in this space, and may not be properly funded, even if it is the right thing to do. The best thing to do in this case is to make an engineering effort, identify the feature vacuum that the current solution cannot address, and solve it with the introduction of newer architecture principles that won't be easy to splice into the existing work. Once you get a few customers using it, the operational data will help you to the next actions.
If you want to engineer, find the place where you can build new patterns that can solve a critical problem with the existing order.
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 observe what works, and specify meta patterns than others can benefit from.
[...]