Jaa

Don't walk in with a problem until you have a solution

  • Artikkeli

Enterprise Architecture is a source of chaos, obstacles, and high-level fights. Any organization that has an EA team is saddled with inefficiency and cannot possibly make an agile decision. They are smart people, who can be used on other ways much more productively.

I'm guessing that this is the argument that some folks are now saying about EA in Microsoft IT.  Why now?  Because things have changed.  You see, as a result of the leadership of our C-level executives, EA in Microsoft IT has teeth.  This is a first.  We actually have the ability to influence something.  Not all of us have figured that out, unfortunately, but for me, I'm going gangbusters. 

And the effects are startling.  A very large project that has been spinning money out of control for months had defined some scope that overlapped with the applications I'm on.  So I used consulting techniques (Thank you Sierra Systems Group) to get people to do what needed to be done.  I saved $6M this month.  I'm feeling pretty good.  If EA could do that as an annual average per app architect, we would save the company $120M per year.   Personally, I think that is conservative.  I think we could save up to $200M per year if we really got going. 

So, why would some folks be saying bad things?  Because our process involves oversight.  We come in to a project at key points to review.  Good architects do more than 'seagull' the project (Fly in, make a lot of noise, crap all over everything, and fly off) but I'm sure that, in some cases, we are percieved that way.  Not every team is aware of the need to cooperate with EA, so their only experience would be limited to the oversight role. 

Better teams would work with their architects as the project goes along, touching base on key decisions and generally inviting him or her to major project status meetings.  That way, if a decision was made that is not good, the architect knows before 'review-time' and a minimum of resentment is generated. 

On the architect side, we need to be "bringers of solutions," and not "bringers of obstacles."  So if I say "no" to one thing, I have to say "yes" to something else. 

It's common sense.  I know, but it was hit home for me again this week as I had to pour ill-will over a very visible project for a decision that they made over a month ago... We are all kicking ourselves for not seeing it earlier.  That said, I have a really good team of passionate people who want to succeed.  We will write up a solution over this weekend, and clean it up on Monday, and present it on Wednesday. 

I need to be the bringer of solutions. 

If I don't, I'll deserve that criticism.

Comments

  • Anonymous
    July 02, 2006
    PingBack from http://technote.thedeveloperside.com/?p=27
  • Anonymous
    July 03, 2006
    Hi there!

    "Don't walk in with a problem until you have a solution" - I think this statement is a good one, but very difficult to achieve in reality. We Enterprise Architects are often organizied in a central department and our aim with EA is to focus on holistisc cross-organisation and long term interests. One of our job is to review and give support to the decentralizied development departments. Our focus is EA and we can therefor not give solutions to project- and systemspecific problems (=solution architecture). The specific solution of problems and projects are decentralizied and our collegaues out there are much better then us to solute those problems. We have not deep and specific tech. competences to do that. We can poiint out problems and challenges, but the real solution must be done decentralizied at the projects with our reviews.

  • Anonymous
    July 04, 2006
    Hello Asim,

    It is true that it is up to the development project teams to fix technical problems.  However, from a pure governance point of view, a valuable EA program is not focused solely on technical problems.  Most of the problems that we will bring to the table to strategic alignment problems, and those are much harder to fix.  In that case, we not only point out the problem, but for those project teams that have never fixed a problem like this before, we need to provide as many specifics as possible to assist in solving them.
  • Anonymous
    July 06, 2006
    Sometimes the key insight is sensing the problem and defining it properly. Enterprise Architects can certainly help do that even if they don't bring a solution. I'd go far enough to say that the best Architects I've seen have been better at defining problems in a simple way rather than crackerjack solutionheads.
  • Anonymous
    July 13, 2006
    I am much agreeing in Piyush´s statement. The often situation in projectrelated challanges is that the problems are not veldefined. In this case it is good that we Enterprise Architects can come from outside and see and define the problem objectively. Regards Asimblogged.com
  • Anonymous
    July 23, 2006
    The comment has been removed