This is my third post on Feedback loops and EA.
At the Gartner EA Summit in the spring, I was chatting with some folks at lunch, and the question came up: what’s the biggest criticism of EA in your organization… and the answer was nearly unanimous: “your models are great, but we can’t really use them when building systems.” In other words, EA is not actionable.
I’ve been thinking about this one a lot. As I build out the Integration area, I’m trying to avoid the stain of “non-actionable EA” by directly engaging with the project teams. But direct engagement isn’t enough. There has to be a feedback loop.
Traditionally, EA teams will go off and create a set of models that describe how the world should look. There may be some strategy in there, as well as some wishful thinking. When the project teams get going, we hand them our work and say: here’s your shiny solution! They thank the EA politely and then get around to building an app that doesn’t take the EA models into account at all.
The IT teams get no value out of EA.
This engagement model has to change. The IT teams have to have skin in the game. The good men and women building our systems need to feel ownership of the EA models. They need to feel like those models represent their interests, and carry their career forward. They need to be incented and rewarded through the connection with EA models.
Today, in many organizations, including my own, this rarely happens.
I can see the need for a number of feedback loops:
1) Models. The first loop needs to take models into account. When the EA team comes in with a model and the IT team ignores it, it was not valuable. If the IT team comes in with a model and the EA team ignores it, same thing. Both behaviors must change. But if both sides keep pointing fingers saying “that guy has to change first” then we are no better than schoolkids fighting in a playground. Someone has to be the first to own up. I believe it should be the EA team that starts by accepting feedback from the IT teams. That starts with models. We need to take our models, compare them to the models of the IT teams, and where they differ, we need to work with the IT teams to figure out what needs to change… in the EA model. This includes data models, reference architectures, and taxonomies.
What parts of their design really are “enterprise?” I doubt anyone asked most IT teams that question, and they get to try to answer. With a few rounds, we can create a good answer, and I’ll bet that the part we agree on, will be the most stable part of the design. The IT team will buy in.
2) Participation. The second loop is one in which we measure the relevance of our communication processes by looking at how each team participates with the other teams. Who comes to one another’s meetings? What ideas are shared? What decisions are made? In order to develop a feedback loop, folks have to actually speak with one another. They need to participate in the success of one anothers’ projects. This participation builds trust and connects the most important, and the most difficult, type of integration: between people. This kind of peer-to-peer feedback crosses in many directions. not just EA <–> Solution Arch, but also Solution Arch <–> Solution Arch.
3) Incentives. Once a year, in our organization, every employee comes before their manager for a performance review. The process is fairly involved, and there is a lot at stake. In Microsoft, stock awards and cash bonuses ride on the results of your performance review, and employees will work very hard to make sure that their review looks as good as possible. If part of that review process includes being rewarded for participation, involvement, and consumption of models from other teams, then the behavior will occur more frequently. Of course, and organization can tie itself into knots if EVERYONE is supposed to reach out to someone else before getting anything done. Striking that kind of balance is difficult, but not impossible. Regardless of difficulty on the management side, getting incentives in place to encourage the right amount of cross-team collaboration will go a long way towards creating the kind of interdependency that is necessary to make Enterprise Architecture actionable.
At the end of the day, Enterprise Architecture is not a team or a set of models. It is a system of interacting variables, people, incentives, and relationships. We all have to believe that the goal is worth pursuing, and our management has to support us in pursuing it.
With feedback, EA can become actionable. Without it, I cannot see it happening. EA is a culture shift. Until folks make the shift, EA folks are going to struggle with the bars of the ivory tower where their organization locks them away.