Inside Architecture

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

January, 2006

  • Inside Architecture

    A service by any other name...


    In a meeting yesterday, we discussed the various 'types' of services.  There are some pretty passionate folks, and each person came to the meeting with their own taxonomy in mind.  The problem with labeling services with a 'type' is that you have to have a good idea of what you will do with this attribute.  Is it used to describe the service behavior or the service logical domain?  Is it used to describe that behavior to a developer, to a business person, or to another enterprise architect?  Does it matter who the source of the taxonomy is?

    The IASA is working on creating a taxonomy, but that may take a while.  In the meantime, we have a long list of standards.  The Microsoft DSI has some terms.  Microsoft Biztalk has some terms, as does the WCF (Indigo).  Then, outside the Microsoft world, there are taxonomies from the analysis organzations (Gartner/Meta, and others) as well as from software and hardware vendors. 

    The net result of having no standard is that every organization invents one. 

    Including, unfortunately, mine.

    (We may end up with multiple taxonomies, one for architects that describes some particularly useful aspects of the behavior, and one for business consumers to describe a disjoint set of behaviors that has to do with business capabilities).

  • 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?

  • 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

    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 3: Guesses for Estimates


    Basically, in IT work, we usually need to figure out, early on, if a project is "large" or "small" and budget accordingly... so we ask an experienced person or two to examine the requirements and figure, based on experience, how much it will cost.  Then, if you are in a high-ceremony process like TSP/PSP or RUP, you will go through an entirely seperate round of estimation later on, after the requirements are better understood, to figure out a "cost" to earn value against.

    The first one is expected but unnecessary.  The second is simply foolish and wasteful.  Neither work very well.

    A tool would be very simple to construct, using the notions of function points or story points, to meet both needs.  The basic idea of tools like these are to enter specific measurable aspects of the REQUIREMENTS into an interface, and have it produce a number of hours it will take to create the program.  These measurables can be the number of fields of data entry or data reporting, the number of new and changed user interface screens, the number of navigation pages, etc.  You actually avoid some, but not all, of the infrastructure, since those are usually choices that are made in a similar manner for each project.

    You measure the first project, enter data, get a bad forecast, and use it.  Then you take the actual data from the END of the project and key it back in.  This makes the model more accurate.  You then use the estimation model to create the next estimate, this time a good one.  Keep this loop going.  After a few dozen projects (which in a large IT shop should take less than a year), you have a model that is ALWAYS more accurate than guesswork.  Always.

    There was a time when using guesses for estimates was necessary.  That time is over.

  • 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...

Page 1 of 2 (10 items) 12