Part I of a new series, "Architecture, Agile, and personal re-invention"
Architects and analysts have a lot in common, and I've been some combination of both for quite a while. We deal in abstractions, because we have no choice – it's what we're paid to do.
The challenge is always to remain relevant. It's easy for others to point fingers and say "ivory tower" but often when one is trying to understand large landscapes it's just not possible to go deep. And in many cases, there is no need to. It doesn't add value.
For example, as a practicing enterprise architect in the "business of IT" capability area, I had a portfolio of about 60 systems, most based on commercial software. Each represented a team of people well versed in the specifics of their system. It would have been counterproductive for me to develop platform expertise in ANY of those systems. I would have been seen as both “meddling” and “playing favorites.” My job was to understand the overall city and I didn't need to go into the basements of each house.
However, understanding a “city” or a "landscape" is only a partial metaphor. They are OK mental models in periods of relative stability. But information technology as a social force has become more dynamic.
I had some nagging feelings about this. I had started to feel inauthentic, in my writing, teaching, and work on the IT4IT Agile Workstream. Agile, Lean Startup, and product-centric approaches are transforming enterprise IT, and there is a very different set of assumptions at the core of this transformation.
Sometimes, if you don't go to gemba, if you don't spend time at the coalface, you get too detached. You do wind up in the ivory tower, in a bad way. And for me, the coalface is the set of practices centering on DevOps. It's not about any one language or tool pipeline, but it is about a system with the tightest possible feedback loops in the creation of new technical functionality. And the mental models humans use in understanding, describing, socializing, propagating, and improving that system.
So, when the Dean asked me to develop a lab for my course, it converged nicely with the IT4IT work and my desire for a deeper understanding. I decided that if I was (as the IT4IT Agile workstream lead) going to propose an architecture supporting Agile approaches in the enterprise, I would start by actually building out a baseline "microkernel" for DevOps and seek to scale it as a simulation. And I would use that simulation in my class on IT Infrastructure.
I would re-skill and re-invent myself, starting with hands-on work. With a broader agenda, something I don't have even one-quarter baked yet, of using these simulations to address troublesome abstract, semantic debates that keep cropping up in IT management discussions. More to come on that...
This is no longer "something I intend to do." Calavera is in its first alpha release and being actively used by my students. This next set of posts will cover what I did, what I have learned, and where I need to go next.
It's all part of a self-designed, self-managed improvement program for the remainder of my career. I'm excited and enthusiastic about it and look forward to every learning session. It's taken me on quite a journey through virtualization, open source, and a variety of cutting-edge technologies. The next few blog posts will continue to tell the story. I'll cover the new tools and techniques as well as their impact on how we understand and use information technology at scale.
So, having decided to re-skill, how would I proceed? More on that in Reinvention Part II: Tools and Techniques.