Sounds like a pretty salesy headline, doesn’t it?  Well – I’ve got you reading and that was my intention.  It’s the same attention that you need to pay to your enterprise, your business or your organization.  Times are tough out there, and companies need you more than ever to demonstrate value, but also to roll up your sleeves and help to keep your company afloat.

There aren’t great job descriptions out there for Chief Architect’s.  To some companies, it’s head architect, top “smart guy/gal”, “IT Strategist” or even lead IT thinker.  You may be responsible for a very structured and detailed program, or you’ve been saddled with figuring out exactly what your job is.

Let me start by letting you in on three very important secrets that should be on your job description.  1. Risk.  2.  Risk   3.  Risk.

What do I mean?  Beyond everything else, you need to be your CIO’s eyes and ears when it comes to technology risk management from a really big picture perspective.  Their trusted advisor.  2009 is my year to focus on Perspective and the concept of dialing in and out on auto-focus as an architect.  Zooming In as a matter of fact.  The chief architect may be heads down in putting together an EA Program, Plan or Roadmap, but day to day work must be on their mind.

At any given moment, place and with any person in which you communicate, you need to be aware of the three biggest risks with respect to architecture in your company.    You don’t need to do any real work to create this list.  When you start with your company, use a default three, and each time you learn of something that has higher risk, move it to your list.

For example – if you have just started working at your company, your top three risks are

1. No Disaster Recovery Plan
2. Major Hardware failure in the gear that runs your most critical customer serving application
3. No risk management system

As you get to know and learn about the systems, technology and data in your organization, you will be able to replace these incredibly general risks with those that are more specific.  If you’ve been there for any period of time, you may not have this list posted anywhere, but you can probably derive it in about 90 seconds.

Obviously, you need to find out if there is a DRP and know what it’s all about first.  After that, find out from the highest ranking technology architect or engineer that you can find what they feel the biggest infrastructure risk is.  Something else you might want to consider is the new category of risks that is similar to those that everyone talked about when “pandemic” was the big buzz word”.   Two words – supplier solvency.  With layoffs and shutdowns, is your DRP supplier afloat?

Finally – learn what the organizations plans, systems and methods are towards managing risk.    If there isn’t a system, documentation, plan or program, that just became your number one task.  Talk to your CIO.  Discuss with the IT staff in your company.  Demonstrate value in Architecture in another dimension – AVOIDING risk as a strategy.  Know when risk is discussed, where it’s documented and what the next steps are to manage or remove the risk.

As the Chief Architect, you should be your CIO’s trusted advisor.  As their trusted advisor, you need to both protect them, as well as look forward to their future.  Any future plans must include the removal of risk as well as creating great plans for the opportunities that exist.

In my next posting, I’ll include the Big Three Secrets for planning and opportunities!

Happy Architecting

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.

Way too long since the last post – mybad.  Too much book!

Sounds like a pretty sales-y headline, doesn’t it?  Well – I’ve got you reading and that was my intention.  It’s attention that you need to pay to your enterprise, your business or your organization.  Times are tough out there, and companies need you more than ever to demonstrate value, but also to roll up your sleeves and help to keep your company afloat.

There aren’t great job descriptions out there for Chief Architect’s.  To some companies, it’s head architect, top “smart guy/gal”, or even lead IT thinker.  You may be responsible for a very structured and detailed program, or you’ve been saddled with figuring out exactly what your job is.

Let me start by letting you in on three very important secrets that should be on your job description.  1. Risk.  2.  Risk   3.  Risk.

What do I mean?  Beyond everything else, you need to be your CIO’s eyes and ears when it comes to technology risk management from a really big picture perspective.  2009 is my year to focus on Perspective and the concept of dialing in and out on auto-focus as an architect.  The chief architect may be heads down in putting together an EA Program, Plan or Roadmap, but day to day work must be on their mind.

At any given moment, place and with any person in which you communicate, you need to be aware of the three biggest risks with respect to architecture in your company.    You don’t need to do any real work to create this list.  When you start with your company, use a default three, and each time you learn of something that has higher risk, move it to your list.

For example – if you have just started working at your company, your top three risks are
1.    No Disaster Recovery Plan
2.    Major Hardware failure in the gear that runs your most critical customer serving application
3.    No risk management system

As you get to know and learn about the systems, technology and data in your organization, you will be able to replace these incredibly general risks with those that are more specific.  If you’ve been there for any period of time, you may not have this list posted anywhere, but you can probably derive it in about 90 seconds.

Obviously, you need to find out if there is a DRP and know what it’s all about first.  After that, find out from the highest ranking technology architect or engineer that you can find what they feel the biggest infrastructure risk is.  Something else you might want to consider is the new category of risks that is similar to those that everyone talked about when “pandemic” was the big buzz word”.   Two words – supplier solvency.  With layoffs and shutdowns, is your DRP supplier afloat?

Finally – learn what the organizations plans, systems and methods are towards managing risk.    If there isn’t a system, documentation, plan or program, that just became your number one task.  Talk to your CIO.  Discuss with the IT staff in your company.  Demonstrate value in Architecture in another dimension – AVOIDING risk as a strategy.  Know when risk is discussed, where it’s documented and what the next steps are to manage or remove the risk.

As the Chief Architect, you should be your CIO’s trusted advisor.  As their trusted advisor, you need to both protect them, as well as look forward to their future.  Any future plans must include the removal of risk as well as creating great plans for the opportunities that exist.

In my next posting, I’ll include the Big Three Secrets for planning and opportunities!

Happy Architecting
Sharon