Forgot your password?
typodupeerror
User Journal

On Lawn's Journal: Staying ahead of the curve

Journal by On Lawn

So I've been looking back on my career. It is amazing to me the technologies that I was innovating with before their day.

I've been working on Linux since it was a toddler (pre 1.0). I've been doing automated image installation since before Ghost and Kickstart; windows and Linux unified directory services with LDAP+Kerberos before Centrify; and unified network on a scalable hardware platform before HP, Dell, Oracle, Microsoft and the like.

I was never the lone pioneer. There were others working on each technology at the time. Some were open with their ideas and I gained a lot from them. Others, like Amazon and Google's work on scalable infrastructure, kept them as proprietary secrets of strategic advantage.

I never found these technologies in an effort to build my career or be on the leading edge. I've spent some time playing with different technologies at home, and to be honest none of them seemed to go anywhere.

But these career choices seem to be remarkable in that they occured purely when focusing on enabling researchers or simplifying systems management.

For Linux, the need was given to me to explore, the Computer Lab needed to have a mature/complex environment to enforce security and be open enough for education. They found Linux, and simply found me a willing person to develop it for them.

For the imaging system, it was a need to administer 100+ workstations for a call center on my own, while the other corporate call centers had a ration of one FTE per 10 workstations. Automation was the only way to accomplish that. The need to make my job easier was also behind the LDAP+Kerberos.

But it wasn't until I found my way into large companies that I found an entirely different kind of need. A purely business created need -- the need for simply scaling architecture. The PMO process is, inalterably by its very nature, a waterfall approach to change. While large companies can benefit from economies of scale, the PMO processes seem to work on an economy of inflation -- the bigger the change more the inflation of resources needed to enact the change.

Hence the need for scalable architecture arose from the need to change and grow with as little imprint in the PMO as possible.

Now, PMO oversight is a business justified expense. I am in no wise critical of what value project management brings a large organization. But it is, and will continue, to be an inflationary environment which continues to drive evolution towards architectures which minimize its footprint in the PMO.

Right now I'm working on just what that means -- how do you minimize the PMO footprint of your architecture? What principles are developing that show what exactly is best to simplify, and where is the flexibility that needs to be pushed to soft-tooling rather than hard-tooling?

What are your thoughts? No place to find venerable IT workers fighting against the machine than Slashdot, no?

This discussion has been archived. No new comments can be posted.

Staying ahead of the curve

Comments Filter:

How many QA engineers does it take to screw in a lightbulb? 3: 1 to screw it in and 2 to say "I told you so" when it doesn't work.

Working...