There is a very interesting article that came across my LinkedIn newsfeed today. It came via a “like” by one of my contacts. I can’t tell whether it’s posted to any EA forum. The theme of the piece is duality.
The premise of the piece is that enterprise architects must possess a dual nature because of two vastly different aspects of the job. These facets are the need to be a change agent and the need to be a controller. The post begins with the very familiar lament that EAs are constantly forced to prove their value to their organizations. I think the tenor of this article is that EA and being an enterprise architect is hard and really exhausting.
The article IS well written. So are many other articles with which I disagree.
Why does EA and the enterprise architect have to prove their value to their organization? Most organizations do not pay for functions or for people who don’t add value. The constant need to defend your value proposition must be terribly exhausting. It’s also really perilous. Perhaps it’s because these EA practitioners have an incorrect idea of value. Perhaps they are using a flawed model for their EA practices.
The job of EA is to understand what the business is trying to do and why and then design strategies to get them there. The business leaders have done this for the basic business and for any changes they believe are important. This leads to another question. Why isn’t the enterprise architect among the business leaders? Is it because the enterprise architect is really a senior technologist and not a business management type? I find this to be true in most organizations that don’t have effective EA programs.
The idea that an enterprise architect is a change agent can really head in a bad direction. I can see the need to justify one’s existence if the changes proposed aren’t resonating with the business leaders. Why in the world would an enterprise architect propose a change that has such shortcomings? Why not work on making those changes the business leaders want happen? Freelancing trying to find changes that resonate with you and trying to sell them to the business leaders is hard. They have other things on their minds.
Most enterprise architects frame every change as a technical problem with a technical solution. Many times an effective enterprise change involves a complex business process. This process has so many exception paths hung on it that nobody knows what the process is really supposed to accomplish. Instead of devising a complex and expensive technical solution, an inexpensive simplification of the process is really all that’s needed.
I find the controller facet the most troubling. At this point when the business leaders don’t understand you, you now want to start pushing the technical people around. I think the real problem with our enterprise architect is that he doesn’t have any friends outside of the EA team, if there is such a team.
If your idea of enterprise architecture has the enterprise architect involved in system construction, you’re not working at the enterprise level. You’re working in IT and you’re a systems architect or network architect or applications architect. We need people in all of these roles. What we don’t need is for them to delude themselves into thinking they work at the enterprise level. The only way an architect working in the IT department is working at the enterprise level is when the enterprise is in the IT business. If you work for any other organization with a different business, an IT person is not THE enterprise architect.
In summary, I think this idea of dual nature only serves to complicate EA and the duties of the enterprise architect. If the architect is REALLY working at the enterprise level, he understands what the business leaders need and why. He then works to help make it happen for them by working with other architects in lower levels of the organization and coordinating, not controlling. There’s no need to sell what you’re trying to do because the buyers are already bought in and they trust you to devise the way to make it happen.