Inside Architecture

Notes on Enterprise Architecture, Business Alignment, Interesting Trends, and anything else that interests me this week...

February, 2006

  • Inside Architecture

    Paying to get to the new Enterprise Architecture


    I need to rant.  I ran across an article on the IASA web site that provides tips for knowing if your Enterprise Architecture is mature.  One of the tips asks "If you have a bunch of architecture projects defined, do you have a process for getting them funded..."

    Huh?  Since when is Architecture a "bunch of projects?"  Yes, you need a project to collect the strategic requirements and to create the high-level systems architecture, future-state application portfolio, and migration plans.  However, after that, is it really a "string of architecture projects" to move to the new plan? 

    Yes, there are projects needed to change code to more to a new structure.  Yes, those changes cost money.  Yes, someone has to pony up that cash.  However, if your architecture doesn't actually deliver any value, on a project by project basis, why are you doing it? 

    If your architectural change delivers value, then you can justify that value as 'changing the app to reduce the cost of owning it.' 

    If the cost of the change exceeds the value in the short term, perhaps your migration plans show that the app doesn't adopt the new architecture until a business-driven change is actually required.

    It is not wrong to migate to an architecture slowly, over time.  Time can be your friend.  You get better at delivering value on the architecture, and the team gets better at using the architecture, and risks associated with adopting the architecture are minimized. 

    And you don't need to go to the CIO and beg for millions... honest.

  • Inside Architecture

    Patterns and the Peter Principle - The positive effects of recognizing good application design


    Old developers don't die... Sometimes they move up.  Think about it.  Have you ever met a manager who was a stellar Assembly developer once.  How about RPG?  (When I first entered management, the team could point to one time in my past when I wrote EasyTrieve code... if you can call EasyTrieve "code").  I can't count the number of dev managers or dev leads that I know who once wrote code in Visual Basic 3.0.

    The problem is that design moves on, even if a dev manager doesn't.  This isn't wrong.  In fact, it is perfectly normal.  Our managers rely on smart teams to keep up, and they do their best.  No, the lack of advanced design skills in management is not a problem.

    The lack of design skills in the design team... that's a problem, and the fact that most managers can't tell that their design teams stink because their design skills are not exactly "cutting edge"... That's the flip side of the same problem.

    The Peter Principle says "A person will be promoted through the ranks of a corporation until they reach a position where they are utterly incompetent, and there they will stay."  In some corporations, this means that nearly all of management is essentially incompetent.  (At Microsoft, we reorganize management so frequently that incompetence tends to show up and filter out... but sometimes good ones leave as well.  That's another blog post altogether).

    The Peter Principle in design says that excellent application design will go unrecognized, and poor application design will go unpunished as long as the manager was promoted before he or she learned how to design anything.  In some IT shops where I worked in the past, this was the primary rule.

    Design was delegated to the ranks of the hero.  The system could not support the building of excellent design skills, or require excellent design artifacts, or even reward excellent design expressions, because the group manager was utterly incompetent in the skill of "recognizing and rewarding good design."

    Therefore, developers who cared would first learn good design, then try to force their team mates to use good design, and then, after mountains of frustration, would leave.

    If this is you, I have good news: you do not have to simply suffer in silence.  You can get off the merry-go-round.  Your first task is to learn how to EVALUATE good design, and then teach others (especially your manager) how to do the same. 

    If you have a hard time convincing your manager to learn good design, then set up a competition in your company, with open submissions and a judging panel (made up of good designers) who will evaluate submissions and give a quarterly prize.  Hang a poster next to the elevator or the water cooler announcing the winner.  Pitch in $20 for a 'desk trophy' that the winner gets.  (I spend more than that schmoozing with internal customers on a monthly basis).

    Once your team begins to recognize what good design looks like, it will be much easier to convince people to spend time and effort on improving the overall process so that good design becomes normal, and not the product of heros.

    Everybody wins.  And who knows... maybe you will be the one they recognize next...

Page 2 of 2 (8 items) 12