Skip to main content

Architecture, Engineering, Operations - iteration 1


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

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

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

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.

[...]








Popular posts from this blog

Why PI is not 4, math is great, and other mysteries.

The other day, I found myself with an interesting problem of approximating a circle with the enclosing square which seems to prove pi = 4.

The paradox was forwarded by a most interesting puzzle collector, Surajit Basu, a friend and life long inspiration. See Sonata for Unaccompanied Tortoise for why!



Here is the offending paradox:

























This is an example of how counterintuitive questions can be answered with a little calculus.

The key is to realize that no matter how closely we approximate the circle, the orthogonal lines of the approximation formed by inverting the square corners will never actually be tangential to the circle.

Note carefully that as you get closer to 90 degrees, the horizontal line is much longer than the vertical. Same goes with the approximation at 0 and 180 - the vertical line is much larger than the horizontal component.

If we take a quadrant of the circle - let's say the top left quadrant, moving counter clockwise from top to left -  we can imagine that each inf…

Ambition vs. Fear.

Most important things in life don't come to us. Nor do we get them by seeking/wanting them. It comes from letting go of the unimportant stuff.

The hardest part is letting go of the tendency to take the world as is. This is a habit of our past successes.

But success is not a destination, it is a STOP sign. You stop, wait, and move on. Too often, we are paralyzed by success into the fear of the new. We stall on the road to a new life. We need to break our inertia and move.

Our thoughts and thought habits are hard to break. But that is where we have to spend the most energy. Thoughts are always competing strands  - of worries of the past and anxieties for the future. For some of us, they are cleanly separated into rivers that nurture every place they travel. For most, they are like the torrents and trickles -- competing, rushing somewhere, stopping completely elsewhere, always mixing, morphing, competing, winning, losing.

Our thoughts are the potential difference between the two pole…

How transformation/change could be hard - an analogy from Life

The illusion of steady change
Most changes are gradual. Or it appears to be, as you read stories and narratives about successful people. Be it successful CEOs, scientists, artists, startup founders, you name it -- almost every one who has reached a state of success, it seems, has had a steady run of successes.

We want to believe that these fine folks transformed their lives because they worked hard,  had talent, or had help, or many other things -- and it was simply effort and reward.


But we all know this is not true. Otherwise, we'd be doing more of what we do best, every day.

What is it that can explain great changes? It is a transformation. Yes, it has gradual bits and habits thrown in. But in the end, they were ready to transform themselves. They were ready to re-work their brains, bodies and life into a new combination.

Example from the chemistry of Life
There is an example in Life that may shed some light. Treat this as an analogy, but it has some lessons.

To illustrate, …