Inside Architecture

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

July, 2006

Posts
  • Inside Architecture

    Things I learned on vacation with kids

    • 7 Comments

    I took my kids to a regional amusement park called Silverwood in Idaho.  We had fun, but it's a small park.  Smaller than most Six Flags parks.  Two nice roller coasters.  Brand new water park attractions.  All in all a nice way to kill two days. 

    We took one of my son's friends along, so I had four kids with us, all between the ages of 8 and 12.  Kids at that age are playful and social and still enjoy spending time with Mom and Dad, so it was a good family experience.

    Things I learned:

    • You cannot stop a hotel door from swinging shut by putting your thumb in the door jam.
    • When the ice melts in your cooler, that bottle of CoffeeMate Coffee Creamer will not float upright.  
    • When floating on it's side, the top of the CoffeeMate Coffee Creamer bottle is not water tight.
    • Roller coasters + fried breads (elephant ears) = vomit
    • If you bring a board game with lots of little pieces in it, no matter how careful you are when cleaning up the game, you will end up wearing one of those pieces in your sock all the next day.
    • Just because you asked for adjoining rooms, and called to verify that you will get adjoining rooms, and prepaid to get adjoining rooms, that doesn't mean you will get adjoining rooms at Days Inn. 
    • The hotel version of "Free Continental Breakfast" is edible if you bring along meats from your cooler.  You can save a lot of money over eating breakfast at IHOP by simply supplimenting the hotel's offerings with your own items.
    • No matter how good you are at wrapping things in cellophane, water will get in if you put it in the cooler.
    • Frango mints (chocolates from Macy's) are wrapped in cellophane.  It is not water tight either.
    • Wet frango mints are pretty gross.
    • If you have a kid that refuses to get in the water, put him in a swim suit.  Then go to a water park.  Then get in the wave pool.  Scream with delight.  He will follow.
    • Waterproof sunscreen isn't.
    • Every park posts signs that say "no running."  Kids ignore them.
    • Bring bandaids for when kids ignore the "no running" signs.
    • Sometimes, the magic show tries to sell stuff (Dollywood).  Other times, the magic show is of near-Las-Vegas quality (Silverwood).  Don't judge one park by the experiences in another.
    • A picnic at a rest stop in the middle of a desert on a very hot day is a very short experience.

    All in all, the cost of tickets: $350. 
    The cost of hotel: $650. 
    Four days with four kids: priceless. 

  • Inside Architecture

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

    • 6 Comments

    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.

  • Inside Architecture

    Becoming more visionary

    • 5 Comments

    These past few months have been very difficult.  Without a good vision in place for where our architecture should go, we've been making decisions about literally dozens of large projects: are they working towards the right goal?  Are they aligned with strategy?  Do you reflect the principles? 

    To be honest, without having the destination clearly described, all those decisions are arbitrary and subjective.  We need to become more visionary.  We need to get out in front, describe the way that IT should be, and then sell that vision to the business.

    That way, we are doing a lot less of arguing with solution owners about whether their vision of an application matches the principles, because we helped the business to understand what the application should be in the first place.

    It's a hard transition to make.  We don't traditionally have that role.  The business is not used to listening (or being listened to, to be honest). 

  • Inside Architecture

    The SOA and simplification paradigm shift

    • 3 Comments

    In order for SOA to deliver in its promise, we need to change the way that the requirements analysts approach problem solving. This is critical.  I can prove it.

    When I gather requirements from the user, I can't just ask "what do you want?"  The question is meaningless.  I have to

    • understand what is going on, then
    • envision a new process, then
    • suggest the new process with alternatives. 

    In that process, I am making assumptions about what constraints to apply to the process.  Is there anything I cannot do?  The only constraints are to reduce costs or automate manual processes.  That is not enough.  

    When a company decides to implement a commercial software package to solve a problem, a different approach takes place.  It goes like this:

    • understand what is going on, then
    • compare it to the process favored by the tool, then
    • decide where it is feasable to extend the tool, then
    • suggest the tool's process with possible extensions. 

    In order for SOA to work, in order to gain flexibility and agility and reuse, we need to follow this second process, even if we are solving a problem with composition of existing services... even if we are not purchasing software... even if 100% of the components are home grown.

    THESE STEPS MUST APPLY.

    It is this second process that assumes that the company already has an answer. It is this second process that requires teams to solve their problems by FIRST considering whether an existing answer is "good enough" and SECOND considering the cost of extending it.  We will never achieve simplification without doing this first.

    Training the requirements analysts to think this way may be the single largest shift towards SOA.  It may be the most difficult thing to do.  Yet, I am convinced that this is the only way to accomplish it. 

    Proof: The project I've joined is staffed with truly intelligent, earnest, hard-working people with good intentions.  However, they followed the first process above.  They developed a "shiny new" process and that drove the needs for a "shiny new" tool, even though the company already had a couple of tools for the exact same thing.  They never ever considered looking at those tools, or constraining their solution by those tools. 

    We must constrain our solution to existing tools first.  Those tools don't have to be something we are buying.   They can be, they must be, the things we already own. 

    SOA depends on creating services that will be reused.  Unless we choose to reuse them, then that promise of reuse will never be fulfilled.

  • Inside Architecture

    Simplification requires dev capacity - like aircraft maintenance

    • 3 Comments

    Simplification reduces the cost of maintenance.  The business probably doesn't want to think about it, and they really don't want to pay for it.  However, in many situations, IT has no choice.  By reducing the number of applications, reducing the number of redundant data stores, making data paths simpler and more measurable, and driving for more consistence in non-value-add processes, the company can reap real benefits in cost savings. 

    However, simplification requires a couple of things.  It requires project teams to change processes and code.  It requires support teams to manage the data shifts and all the ripple effects.  It requires release management coordination to make sure that new features and simplified systems do not conflict.

    Where does the money for that come from?  This requires the business to pay for this work.  It requires that IT have staff and resources to dedicate to it. 

    Think of it like aircraft maintenance.  When a jet airplane is being repaired, it has to be pulled out of service... for a day or two or ten.  But the airline cannot simply cancel the flight because the aircraft needs a routine tune-up.  The airlines have some capacity, in terms of aircraft seats, set aside so that they can allow the aircraft to be inspected, maintained, and returned to service. 

    So when an airline decides how many flights per day to set up, it has to plan on a certain amount of excess capacity just to cover the number of planes needing service.  It does not apologize for these costs.  The cost of your airline ticket includes the cost of maintaining other aircraft. 

    And you don't complain.  Why?  Because you want YOUR aircraft to be working when you get it. 

    Similarly, the IT department needs to have excess capacity, in terms of project teams and hardware space, to cover the costs of simplification. 

    This requires real leadership to pull off, but it has to be done, especially in larger IT departments where there are many developers writing code.  In these environments, the amount of overlap is substantial, so the benefits are large.

    So for every five project teams that you can use in business-requested maintenance or new features (airplane flights), you need a sixth team for IT driven simplification (aircraft maintenance).  That team needs project managers, product managers, developers, testers, release and code management, and support members.  Full out teams.  The business does NOT get to drive the efforts of these teams.  IT does, as needed, with the guidance of Enterprise Architecture or the EPMO.

    Without this capacity, you will never be able to solve, or fund, Simplification.  It's a cost of doing business.

    Last note, when I say "Simplification", I'm not talking about consolodation.  Sun is spending a lot of time talking about the savings that a company can earn by moving software from multiple servers to a single Sun server (lower power, lower rack space costs).  That is consolodation, and it is not specific to Sun servers.  You can get the same benefits from any server consolodation. 

    This reduces ongoing run costs, but not the costs of maintenance.  In fact, it may increase the costs of maintenance somewhat by placing more complexity on a single server and decreasing the redundancy.

  • Inside Architecture

    Just when is standing your ground a Career Limiting Move (CLM)?

    • 2 Comments

    Yes, we have an acronym for it.  CLM -- any action within your scope of control that you could do, maybe even should do, but which you are likely to pay consequences for, repeatedly, for about the next five years.

    Sometimes I wonder if testers get pinged on Sev-1 bug reports?  I doubt it.  MS has a very healthy testing culture. 

    On the other hand, if your job isn't 'Tester' but your role includes "review" of someone else's deliverables, let's face it... either you are a tester or you are a noisemaker.  A tester is someone who points at the emperer and says "No Clothes" without fear of reprisal.  A noisemaker says "Odd choice in clothing, sire.  We think your traditional garb is better."

    In other words, a tester is allowed to simply point to the problem, without having to consider if it will delay a project or cost additional resources to address.  When a tester points out a defect, it is never a CLM.  When a noisemaker does, it might be.

    Today... I envy testers.  I'm still standing. 

Page 1 of 3 (18 items) 123