The Software Architect Elevator

Part V. Transformation

When setting up modern technology in a large IT organization, you’ll invariably find that there’s an impedance mismatch. Using elastic billing from a cloud provider won’t work well if you have to make an annual budget forecast anyway. And being able to provision infrastructure with an API call becomes a lot less exciting if there’s a two-month approval process attached to it. Therefore, the last and final leg on your architect journey is being able to change the way organizations work.

Change Is Risky

Bringing change into large organizations is rewarding but challenging, requiring you to utilize everything you’ve learned so far: you must first use your architectural thinking to understand how complex organizations work and which “levers” you may have. Superb communication skills help you garner support, while leadership skills are needed to effect a lasting change. Last, your IT architect skills are needed to plan and implement the technical changes necessary for the organization to work in a different way. As an architect you are best qualified to understand how technical and organizational changes depend on each other so that you can solve the Gordian knot of interdependencies.

Citing The Matrix one more time (after all, Neo is quite a change agent in a tough environment!), the exchange between the Architect and the Oracle draws the apt context:

• The Architect: You played a very dangerous game.
• The Oracle: Change always is.

Interestingly, in The Matrix ...