Inside Architecture

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

January, 2006

  • Inside Architecture

    Agile definition: Chickens and Pigs


    In agile project management, you have frequent meetings of the project team (usually daily).  The goal of these meetings is twofold:

    1. team members come together to present any "obstacles" that the group coordinator is charged with clearing and
    2. team members may provide any "daily data" (like the number of hours needed to complete the in-flight task). 

    These meetings are designed to be short, and agile methods like Scrum suggest that you ask everyone to remain standing during the meeting.  Fifteen minutes should be a reasonable meeting length. 

    In order to keep these meeting short, the only people who can speak are people who have obstacles or information that others need to take action on.  The key word is action.  If information isn't salient for 'right now,' it shouldn't be discussed in this forum. 

    The people who can speak are 'pigs.'  Other stakeholders may attend but they should not speak (much).  These people are called 'chickens.'

    The terms 'chickens' and 'pigs' comes from the statement: "In a ham-and-eggs restaurant, the pig is committed but the chicken is simply involved."  Numerous versions of this statement exist as jokes or humorous anecdotes.

    Why define this again? I went looking for a good definition of the "Chickens and Pigs" metaphor and my search didn't turn up a lot of useful hits, so I thought I'd add my own definition that I can link to. 

  • Inside Architecture

    Does SOA make eXtreme Programming (XP) obsolete?


    One of the promises of SOA and SOBA is that applications will be less complex, and therefore can be developed more quickly.  This complexity is reduced by having strict rules about how SOBA apps will leverage and reuse services.  In essesence, SOA takes an architectural approach to the problem of apps that take a long time to create, deploy, and modify. 

    Interestingly enough, Agile Project Management methods (like Scrum, XP, and others) solve a very similar business problem in an entirely different way.  Instead of breaking up the complexity of the application in order to speed up delivery, they address the process by which that large and complex application is created using methods that focus on embracing scope change (while controlling it), improving dev team communications (while reducing the time spent on it), and prioritizing the feature set. 

    Clearly, these two approaches are not tied to each other for success.  An XP project can (quickly) deliver a stovepipe app that is difficult to maintain.  A SOBA can be (quickly) developed using a heavy process like RUP.  However, both SOA and Agile SDLC methods use the same problem definition to justify their existence, and both purport that each, in its own right, is sufficient to solve the problem.

    Clearly, if one problem spawns two different solutions, you have to ultimately ask the question: are both solutions necessary? 

    In my opinion, SOA does nothing to address the fundamental problems caused by using a bad SDLC process.  Agile software development processes go a long way towards making life livable for the people who write code for a living.  On the other hand, Agile development processes do nothing to address the fundamental problems caused by system definitions that are too complex, refuse to consider reuse, and will ultimately cost a fortune to maintain.

    So, in a way, both are needed.  On the other hand, I think we need to frame the problem a bit differently so that there are clearly two different problems being solved.  That way, when SOA solves one, and agile methods solve the other, both can be measured independently of one another.

    My suggestion on how to reframe the problem statements to account for both---

    Agile methods solve the problem of software development processes that produce frustration, rework, long hours, and missed expectations.  These are very tactical needs tied directly to the act of developing software.

    SOA solves the problem of systems that embody multiple business capabilities in a non-reusable manner, thus forcing developers to re-invent the wheel every time a new application is created.  These are architectural needs tied to the business' need to deliver consistent solutions in a rapid manner.


  • Inside Architecture

    Project Management AntiPattern - PMs who write specs


    One of my favorite organizational mistakes, and I've seen this one MANY times, is asking your Project Manager to write a functional spec for the IT application you are writing.  I've seen this so often, I'd consider it a Project Management anti-pattern.

    Why is this bad?  Because there needs to be discourse (and disagreement) between the person who describes the system and the person who manages the project that fulfills it.  When you are building a house, the contractor and the architect discuss, argue, and debate.  When you are building a bridge, the engineering designers have constant feedback on the bridge as it comes into being.  Not so with IT projects where the project manager writes the functional specification.

    I'm honestly astonished when I run into this.  I've seen experienced project managers simply assert that "this is the right way," without even considering the conflict of interest that goes on in this condition.  If one person decides both the "stuff" that is in a project and the "plan" needed to complete it, the kinds of junk that comes out the other end is amazingly bad.  I don't care how "engaged" your business customer is. 

    The answer is for the spec to be written by business analysts who WORK FOR the business, REPORT TO the business, and SIT IN MEETINGS WITH the business.  Some folks like for these folks to be paid by IT but report to the business, but personally I don't agree.  Real benefits come when this is actually a business person:  They have to have more than IT responsibilities.  They have to understand the processes and constraints used by the business.  They have to be available to IT at a very deep level.  And they have to be financially responsible for success.

    More importantly, the spec is not dictated by this person to the PM.  The spec is written by this person.  Not just owned... written.

    Caveat: I'm not saying that this (bad) practice does or doesn't happen within Microsoft IT.  It definitely happens.



  • Inside Architecture

    Workflow visibility: driving levels of abstraction into functional requirements


    I'm sitting in a meeting typing a blog.  Shoot me.  However, there is a discussion going on about how a process may flow differently depending on the level of information that may be made available. 

    Earlier I described different levels of abstraction in workflow.  Recap: Business Unit View is high level-Unit-to-Unit.  Very document and message based.  Business Process View is mid level: items move from stage to stage based on conditions, and Work Step View, which is describable at the technical level (petri nets and workflow diagrams that techies tend to wrap themselves up in).

    The problem comes when there are a set of steps that need to occur in a workflow where the workflow has Business Unit implications, but where one unit doesn't want to expose the Process View details.  In other words, if group 1 sends a request to group 2, and then calls three weeks later asking about the status of the request, they shouldn't get detailed information about the person in group 2 who is stuck.  In a B-to-B scenario, for example, a hospital may send an insurance claim to a payer, and then call up in a few days asking if the claim will be paid.  Should the payer respond that there is a data or systems issue, or should they respond in the generic: "we are working on it.  Should be done in 10 days."

    The latter is more useful to business. 

    This only works if our systems allow for us to actually drive these levels of abstraction into our workflow execution systems.  Literally, an process should live within a "container" that provides information to external requesters.  That way, if the process changes within the container, or a particular step represents a process that is of strategic value, those process steps are not exposed.

    It's data hiding at the workflow level.  It's useful.  It is uncommon.  Let's fix this.

  • Inside Architecture

    Project Management Antipattern 2: Pardon My Dust


    I ran across this anti-pattern on a non-software project, but it definitely applies.  This one comes from painting my living room and kitchen.

    My wife and I did a little repainting last week as part of converting our unused formal living room into an exercise space.  Last weekend, we basically finished the change-work after installing light fixtures and a five foot by nine foot mirror.  However, it took until today for us to really begin moving furniture back into the adjoining (and also painted) dining room.  Why?  Because we had book shelves that didn't look good with the new colors, and because we needed more light now that the mirrors were installed, and because... yada yada yada

    It's scope creep, pure and simple, but not the kind that injects itself at the beginning of the project.  That kind is easy to stop.  Nope, this is an altogether different animal.  This is "pardon my dust" scope creep.  This one happens with full cooperation and insistence of the customer.

    I call this "pardon my dust" because a customer will be forgiving of a project's lack of completion as long as new features are being added.  There is hope.  There is a bright, shining future!  And there is one more dinner in a family room filled with dining room furniture...  We are forgiving of the mess because we are getting what we want. 

    As a project manager, especially on a Scrum or XP software project, it is tempting to simply "add another sprint" so that Features 88-94 can be added, especially since they are demonstrated monthly to the customer.  That customer keeps adding the next sprint, adding the next set of features, without ever asking for the deployment sprint to start!  (Deployment sprints are irritating.  You get no new features, it takes just as long, and you have to deal with messy details like QA reviews of the installation guides and maintenance documentation.)  The project manager has deniability because it's the customer who keeps asking for the sprint, and it's her money, after all.

    It's a trap.  The way out is for the project team to set, at the outset, a maximum number of new-code sprints between each deployment sprint.  I suggest three as a good maximum.  That way, the rest of the end users get an upgrade at least semi-annually, which should serve to keep frustration low. 

    Now to invite company for dinner...

  • Inside Architecture

    The Estimation Game: Do not confuse cost with size


    The cost of a project is a function of how big it is.  That isn't really a hard thing to understand... you'd think.  When I say this to a PM, they usually say "sure" with that look that says "say something interesting now." 

    Yet, when you ask for the cost of a new project, by providing a set of requirements, how many of those Project Managers respond by asking "how big is it?"  Not nearly enough.

    That should be the first question.  The conversation between the customer (Tom), the PM (Mary) and the Analyst (Wang) should go like this: 

    Tom: I want you to create a new report on our site for Acme Manufacturing to use.  Their CEO mentioned the need for one to our CEO over a game of exploding golf.

    Mary: Can you write down what this report will look like for me, Tom?

    Tom: I knew you'd ask, Mary.  Here's an example.

    Mary: Thank you Tom. (Turns to Wang)  Wang: how big is this project?

    Wang: (goes away and returns an hour later) The project is 130 Implementation Units, Mary.

    Mary: Thank you, Wang.  I will type the number '130' into my estimation model.

    Wang: Don't you want me to tell you how long it will take?

    Mary: That's OK, Wang.  I can figure that out.  You see, the last time I asked you for a size, you told me that the project was 165 units.  That project took 16 days.  The model says that this project will take about 13 days.  See?

    Wang: That's pretty cool.  I'm glad we decided, last year, to chose an industry-standard definition of an 'Implementation Unit.' 

    Mary: Me, too, Wang.  You see, it wouldn't matter if I asked you or Amy or Naveen.  All three of you would have calculated the size the same way, and my model would figure out the cost.  No need for guesswork, and the estimate is always the same.

    Wang: and it's more accurate too.

    Mary: Yep.  It's been right on the last six projects.

    Wang: what a change that is.  I'm glad to be out of the business of guessing 'time.'  Calculating the size of requirements is analytical. I'm an analytical person.  It's easy for me to do, and you get the numbers you need.

    Mary: (calling Tom on the phone) Hi Tom

    Tom: Hi Mary.  So how long will it take to produce this report.

    Mary: Sixteen to Nineteen work days.  Better say an even month.

    Tom: Your estimates on the last few projects was "right on the mark."  I trust you. 

    This is not a fantasy.  While the conversation is fictional, this kind of interaction has happened many times and will happen repeatedly for folks like Mary.  She uses estimation tools, and she understands the distinction between Cost and Size.  Do you?

Page 1 of 2 (10 items) 12