Freigeben über

Actionable Enterprise Architecture through Feedback

  • Artikel

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.

Comments

  • Anonymous
    August 26, 2007
    PingBack from http://msdnrss.thecoderblogs.com/2007/08/27/actionable-enterprise-architecture-through-feedback/

  • Anonymous
    August 27, 2007
    The purpose of EA is "INSIGHT, TO DECIDE (FOR ALL STAKEHOLDERS)". Use this as criterion to judge EA: if the stakeholder does not understand it, IT IS NO ARCHITECTURE!

  • Anonymous
    August 27, 2007
    @Michael, OK, so there's purpose and role and level of detail.  That isn't the point of my post.  If I produce a model that injects insight and communicates decisions, a model that the IT teams understand, that doesn't mean they will use it. Sure, I can "govern" them into it with a hammer.  That doesn't work to build trust.  We need to get 75% of the projects using the models because the WANT to before I can worry about governing the other 25%.  We tried a governance-first approach and it failed. The other choice, and the one we should have been doing all along, is not to govern, but to listen.  Get the dev leads and solution architects to have a stake in the success of EA.  Make their lives easier.  Take fights off of their hands.  Give them a shield that management respects. An architecture that no one uses is an architecture... it just is not an actionable one.   That is what I'm trying to say.

  • Anonymous
    August 28, 2007
    I covered a related topic in my blog "Get out there!" some time ago which talked about your item 2 - participation.  It talks about the practical day to day things that my team did to be relevant and to get feedback.