Adoption, rather than Architecture, is the high order bit for Architects
Over the years I've noticed a strange phenomenon, sometimes the most logical decision isn't the decision made. Have you ever witnessed an unbelievably strong argument to build system infrastructure with all the right scientifically backed architecture documentation, ROI analysis, market analysis and compelling innovation forecasts only for it to be rejected? I have and wonder, why does this happen?
Other than times when an organization simply cannot justify the funds for the right project, there are other reasons for dismissing a sound, scientifically justified system architecture proposal such as:
- Organization alignment challenges are too great. For example, there are times when in order to build the proposed system architecture, organizations must collaborate with each other and this is percieved as an unwelcomed challenge. Think of the situation of building a 'core' system to be used by two or more different organizations, the organizations must collaborate on using them and understand the tradeoffs for sharing a central system. This can often result in a "I'm too different" or "I don't want to take on dependencies" excuse from the organizations involved.
- Not enough politicking or evangelism. I've seen individuals present and gain momentum for projects which deliver lesser value than others...and win. In sales, we call them "spin doctors". They are masters of influence and can get people chanting and believing a simple message without any sound justification.
We've all heard that an Enterprise Architect is a 'change agent'. I go one step further, all Architects are change agents. Let me give you an example, a project Solution Architect's responsibility is to ensure the software quality of the software the project delivers. They constantly influence the project team to build the right software solution that meets the needs of the key stakeholders as well as ensure the the longevity of the software. An Enterprise Architect is responsible for understanding the business' needs and influencing that the right projects are delivered and they have the right level of system quality.
The point I'd like to raise in this blog posting is that simply building architecture documents, whether it be fully fleshed or not, isn't the high order bit for an Architect. Adoption is the high order bit for Architects. Yes, I'm saying that the engineering aspects of an architect's role is not as important as the abilities to gain adoption of their ideas with the sole purpose of making change - the type of change that ensures the business gets the most value from their investment. Of course, if sound engineering is necessary to make change, then the Architect should do this...but only after careful analysis that this is the right thing to spend time on to actually make change.
I'm not saying that an Architect need not worry or spend time on building sound architecture. On the contrary, if an Architect doesn't do this, then I question the integrity of their ideas. What I'm highlighting is to not depend on sound architecture alone to impact change.
Interestingly, in order to gain adoption and make change, Architects must be leaders. Why? Because leaders are influential, leaders gain momentum, and most importantly leaders consciously understand when to lose and win the right battles in order to with the war. And the war Architects engage on is change.
To my fellow Architects out there, remember not to get stuck on engineering excellence. Architects are leaders and we use these leadership skills to obtain adoption and drive change with the sole purpose of ensuring that the business gets the most value from their investment.