• How can the Chief Architect Absolutely Guarantee Value?

    Why does the business demand change?   This is the fundamental question you should asking yourself as a Chief Architect before doing any architecture work.

    Many current IT strategies and architectures are failing. Senior business executives report that fewer of 25% of IT projects achieved defined project level goals. Fewer than 12% of fundamentally advanced the business strategic goals of the enterprise.  Why is this?  Why are failure rates so high?  Why should the Chief Architect be concerned?

    Many IT projects are focused on the wrong problems at the wrong time.  As the chief architect, your focus must be in providing value to the business in the big picture scheme of things.  Many project managers fail to use the appropriate and prescribed methods to determine whether or not a project should continue or be canceled.

    Projects can typically start to run off course because the IT department feels they should be run … and should keep running.  If we only start IT projects that are deemed to have some value to the business — whether it’s legislative changes, support of a technology refresh or enhanced business functionality, then we as chief architects have a better chance at success.

    Is it possible that it is purely the project perspective at fault for these dismal numbers? It may very well be as projects that just run on auto pilot.  Without a continual review of what the original business drivers were at the beginning, Architecture Governance audits, and the lack of concern that they continue to be on check may be the reason.  It is possible that a program or project portfolio approach would lead to success?

    In performing a project portfolio exercise along side our architecture planning we align that business needs and business values with the projects that are described and put on the table.  Consider a review of each project with the perspective of ranking it against their counter-parts for pure business value and business drivers and need.  Would the chief archtiecthave a better chance to attack the projects that matter to us most each and every year and provide value time and again?  It’s worth a thought.

    If we also use the enterprise architecture plan as a guide post as to which projects should emerge from IT, as well as from the strategy perspective the chief architect also has a better chance at crafting the best possible project portfolio for the upcoming year.  Is there a need for enterprise clarity on the value of IT to business?

    I believe it absolutely is required.   We need to ensure that the business understands the value of bringing enterprise architects and leaders from the IT to the table when business decisions are made.

    Often the chief architect or CIO knows where the IT or technology can be leveraged in order to gain competitive advantage.  We also know when the business strives to achieve something that may align with the project application package solution.  Business and IT strategies have been misaligned in the past.

    Often the IT strategies are driven from the technology perspective only and things that we feel we would like to clean up, upgrade, play with or tinker with.   Instead, if we align the IT strategy with the business strategy each and every year the business shall receive something that they ask for and value.  At the end of our development work they will feel that IT has served them well.

    This will greater our relationship with the business and their opinion of the IT professionals installed in our organization.  We need to architect in the ability to thrive on change.  Isn’t this really what the business truly asks for and needs on a continual basis?

    We as chief architects need to architect out everything that inhibits change.  We need to be weary of this when we compromise our solutions and suggesting ideas and changes back to the business.   They should not even be on the suggestion table as we don’t want a business to fall in love with something that just has nothing but havoc wreaking in their future.

    Tags: , , ,
    Trackback: Trackback this Post

  • Get it done faster!  If you just can’t get started, there has got to be a better way.  I’d love to see more agile EA get done, so today I’ll share the most common and critical parts of an EA Plan.  Here is the checklist I use when creating plans for my clients and customers.

    The Enterprise Architecture plan is a process as well as document set or repository that contains the written plans for the vision and development of the Enterprise Architecture.

    There are many recommended components, of which many are included here. It is my recommendation that you consider creating a shell document/presentation with the following titles in order to keep the information you collect. As well, it can act as a quick guidepost for your endeavours.

    1. Vision Statement including Strategy
    2. Business Drivers & Goals for the Enterprise
    3. Participants/Contributors in the Planning process
    4. Leadership & Sponsorship
    5. Guiding Principles
    6. Approach & Strategy to the EAP
    7. Current State Section
    8. Target State Section
    9. Transition Plan/Roadmap
    10. Next steps/Issues/Outstanding

    If you include all of these in your shell document, the rest is fill in the blank.  Even if you have to go through and fill in what you know for sure, or your team can collect, you can always go back and validate what you’ve added.

    Don’t spend a lot of time on the sections that you are “surmising”.   Put a few key points down and find a stakeholder to validate.  It’s easier to throw darts at the wall than start with a blank page.

    Tell me what you think?  Do you use all of these sections?  Have some of your own you’d like to add?

    Happy Architecting

    Sharon

    Tags: , , ,
    Trackback: Trackback this Post