The Enterprise Architecture Paradox

The other day, I received the nicest note from Ivan Lazarov, Chief Architect – Enterprise Business Solutions at Intuit.  Ivan wrote, “I recently read your book The CIO Paradox and a lot of what you wrote resonated with me. I even took the list of CIO paradox statements and with very little modification translated them to Enterprise Architecture Paradox statements.”

I really liked Ivan’s translation of the CIO Paradox into an EA Paradox, so I thought I would share it with all of you.  Note: Ivan’s changes from the original CIO Paradox are in italics.

• Your Role 

–You were hired to be strategic, but spend a lot of your time on operational issues and convincing operationally focused folks that they don’t want to “just plug the hole for right now.”

–You are the steward of risk mitigation and cost containment, yet you are expected to innovate and encourage engineers to experiment with multiple offshoots of existing capabilities, because otherwise they cannot get their modifications in the roadmap fast enough. Then you are accountable for the proliferation mess, the cost of running it and the consolidation roadmap “ASAP.”

–You are seen as a direction setter/approver for Technology, yet you are expected to be ready with the technology allocation maps the moment Business and PM decides to bring a new “exciting” technology vendor.

–Technology and IT Architecture can make or break a company, but EAs never sit on corporate boards and rarely even get invited to business executive off sites, where business strategy is decided.

• Your Stakeholders 

–You run one of the most pervasive, critical functions in IT, yet you must prove your value and justify what your team of Architects is working on constantly. 

–Your many successes are invisible; your few mistakes are highly visible. 

–You are seen as slowing down business outcomes if you insist on a thoughtful design phase, yet you are the sole responsible party for all “design issues” when you ease up that control. 

–You don’t get credit when you actually put effort to design it right the first time, because everybody thinks “this was the only good way to design it anyway” – everybody thinks they could have gotten there faster.

–You are intimately involved in every facet of the technology portfolio and business functions it serves, but you are considered separate and removed from it, because most of the time the business and delivery teams “make the final calls.”

–You are accountable for project success and business outcome, but the business or PMO has project ownership. 

• Your Organization 

–Your staff is most comfortable with technology, but must be good with people. 

–Your staff is doing more with less, but must make time for learning new innovative technologies. 

–You develop successors, yet the CIO almost always picks somebody else. 

–You are forced to enable very effective and cost-efficient overseas engineering sourcing by designing “a decoupled architecture”, yet you are expected to keep all distributed teams well educated and in complete sync when delivering the joint outcomes. 

• Your Industry 

–Technology takes a long time to implement, yet your portfolio of applications changes constantly. 

–Architecture is a long-term strategic investment, but the company thinks in “incremental outcomes.”

–Your portfolio of applications cost a fortune, yet you constantly have to remind folks that “Buy is better than Build” for Context vs. Core capabilities.

– You are an important stakeholder to vendor selection, yet they often go around you and sell to your business peers.