Inside Architecture

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

May, 2006

  • Inside Architecture

    Patterns of IT Simplification


    I have started to develop a first cut at a pattern language for IT Simplification.  I find that simply creating the list has helped to organize my thoughts and to think about the list of possibilities, in general.  It also helps to identify which activities should be considered 'patterns' and which should be considered 'anti-patterns.'

    As soon as I get a first good list, I will post an article on this blog.  I'll follow up later with a book (perhaps). 

    If you'd like to assist me in creating this pattern language, Please contact me via this blog site and I'll get you on a distribution list for the patterns so far.


  • Inside Architecture

    The leader of the band is tired...


    Nothing will bring you back to earth quicker than the illness of a loved one.  As I type this, my father lays in a Critical Care Unit struggling for each breath.

    If my life has an architecture, and can be understood as components, I'd have to say that the architect who helped me to build my hope, my faith, my family, and my love of all humanity is laying in that bed. 

    As a child, I used to sing along with the radio.  I learned so many songs, I've long lost count.  One song I used to tease my father with was "Cats in the Cradle" about a father who doesn't spend enough time with his son.  But in reality, the ribbing wasn't fair.  The time he spent with me helped to make me who I am.

    If I had to pick a song that comes closer to representing my feelings for him, it would be an old Dan Fogelberg song, "The Leader of the Band"

    I thank you for the music
    And your stories of the road
    I thank you for the freedom
    When it came my time to go
    I thank you for the kindness
    And the times when you got tough
    And, papa, I dont think I've said,
    "I love you" near enough

    The leader of the band is tired
    And his eyes are growing old
    But his blood runs through my instrument
    And his song is in my soul
    My life has been a poor attempt
    To imitate the man
    I'm just a living legacy
    To the leader of the band

    For those of you who read this, and who believe in the healing power of prayer, I ask that you say a small prayer for the healing of Dr. Anand Malik.

  • Inside Architecture

    A single taxonomy of business capabilities


    I've blogged in the past about the value of standards.  I also have seen many efforts to create taxonomies: a standardized breakdown of some general area, down to specifics.  One that is popular with the Microsoft Enterprise Architecture team is the MS Motion Taxonomy, which is a breakdown of business capabilities created as part of Microsoft Dynamics.

    A capability is a 'container that holds people, processes, and tools needed to solve a specific business problem.'  For example, the business may have the capability of paying outstanding invoices in the financial area.  In Contoso, that may mean that a person runs a month-end report showing the list of payables, prints individual checks, prints labels, and then spends some time 'envelope stuffing,' and lastly updates the financial system to reflect their work.  In IBuySpy, that may mean a highly automated daily process.  For IBuySpy, perhaps some invoices can be payed electronically through EFT, so the tools select and transmit those transaction.  For those vendors that require actual checks to be printed and mailed, the tools will electronically compile and transmit a batch to a check printing and paying service.

    The processes were different.  The tools were different.  But the business capability is the same.

    That's the value of a taxonomy of business capabilities.  Note that capabilities are not processes.  The process for 'Procure Office Supplies' can be substantially different from 'Procure Raw Materials' for some very good reasons.  These processes will USE specific capabilities from the business, like the ability to negotiate contract terms, and tools like an procurement intranet site for corporate employees to purchase their office supplies.  However, these high-level processes will share the need for the capability of 'pay outstanding invoices.'

    We are working on the next level beyond these business capabilities at the moment within EA, and I will blog about that later.  For now, I wanted to introduce the notion of Motion.

  • Inside Architecture

    Just say "no" to your architect


    A good friend once told me that she knew the exact day when she went from adolescence to young adulthood: it was the day that she realized that saying "no" to her mother was, at that time and in that place, the absolutionly postively right thing to do.

    In a certain sense, the word 'architect' is not well understood or well defined.  Different organizations are struggling with just how much power or control an architect should have.  To be effective, an architect must have absolute decision rights over some aspects of systems design, but they must not have that right at all levels below that.

    In other words, just because the architect decides that System X is composed of components A, B, and C, that doesn't mean that the architect can, or should, design the components.  The component designer (or sometimes application designer) should design the components. 

    I'm not saying that the long list of people with architect next to their name doesn't contain folks who can do more.  Not that at all.  Every architect probably has some skill in application design. 

    What I am saying is that, for large projects, or in the case of enterprise architecture, there needs to be a clear understanding of where architecture ends and application design starts.

    And then, for the folks who work inside the fantastic and sometimes naieve boundaries defined by their architecture, the snooping of the architect becomes meddlesome, irritating, and unwelcome.

    Let your designers shine.  Start by getting out of their way.

  • Inside Architecture

    Consider: are there Patterns of IT Simplification?


    Are there patterns to the IT Simplification Process?  I think there are.  To quote Christopher Alexander, father of the patterns movement:

    Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.

    As an element in the world, each pattern is a relationship between a certain context, a certain system of forces which occurs repeatedly in that context, and a certain spatial configuration which allows these forces to resolve themselves.

    As an element of language, a pattern is an instruction, which shows how this spatial configuration can be used, over and over again, to resolve the given system of forces, wherever the context makes it relevant.

    I believe that not only is it possible to describe the context of IT Simplification scenarios, that it would not be all that difficult to do.  The axes of data would not be "how much do your objects vary in relation to one another," or "how do you isolate the issuing of a command from the implementation of it," but rather something more reflective of the business environment of IT: "how do the politics and relationships of the people involved play in the decision-making process."

    You see, at the end of the day, the reason that some IT portfolios are not controlled has more to do with people than technology.  So the patterns have to reflect the array of situations that people find themselves in.

    I'll see if I can come up with a pattern language soon.  I'll publish here first. 

  • Inside Architecture

    Leverage, Buy, Build - the EA Simplifiation Motto


    One of the key principles of Microsoft EA is Leverage - Buy - Build.  Meaning: if you want to invest in a capability, you have to invest in an existing enterprise system if it provides that capability (Leverage).  If there isn't one, then you buy a COTS package.  (Luckily, Microsoft sells a number of business COTS packages, like Microsoft Dynamics, so naturally, inside Microsoft, they get first pickings), and then lastly, you build a solution.  You should reserve the decision to build something new ONLY for those situations where building it will give the company a competitive advantage.

    That's a pretty steep bar.  We set it last year, and I think we are still learning it... it is starting to completely sink in now that we are planning the next fiscal year's IT budget.  All of the projects are being reviewed, and any that writes code has to show that the code goes to competitive advantage. 

    That can be difficult to do.

    The easy part is Buy.  For a company flush with cash, it is simple to buy a solution.  No one will complain about the cost, really, when you consider that a purchased package is nearly always 10% of the cost of developing it from scratch, so if there are "extra features," no one will care.

    On thing that is hard, for Microsoft IT, is Leverage. 

    We have notoriously independent business units, and they don't want to 'depend' on one another.  So any mention of 'using another groups' code' is usually met with scorn.  This attitude has seeped into IT so deeply that it is hard to change, but change we must.

    So I'm currently working on a situation where one group has a tool, and a lot of expertise, in an area where another group has a manual process.  Now, the group with the manual process wants a tool, but they don't want the tool that already exists... Oh, no, they want their OWN tool. 

    IT is not built that way.  We are more like a Japanese car company.  We build something new, and it isn't pretty, but we improve it year after year, and after a while, it is darn good.  So, if there is a tool with some age on it, it may be the best tool in town.  On the other hand, it may be written in VB6 and badly in need of a rewrite as well.  Even so, it is better to invest in an existing tool, even an old one, that it is to create a new tool from scratch when the business capability overlaps.

    Otherwise, you have this:

       Team A had old tool Foo, while Team B has new tool Bar.  Team A wants to replace Foo, but they don't want to move to Bar because the new tool has only half the features they are used to.  Team B won't move to Foo because it's old and because they just finished investing in Bar, and they want to get their benefit for the investment.

    This merry-go-round never stops.

    So, when Team C says "I want Jellybeans" and you know that they mean Foo, make them onboard to the Foo tool, upgrading the tool to meet their needs as well as the needs of its existing users.  Refactor.  Replatform.  Reuse.

    Over time, the number of tools in the portfolio drops.

    And that, my friends, is the point.

Page 1 of 2 (9 items) 12