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

Disaster Recovery is typically years of planning for a major event where pandemic planning is essentially determining which pieces of your business is non-critical so that you may take it down gracefully because you don’t have enough people to run it. How many of you have business processes that are able to facilitate that question?

Years ago, I was responsible for figuring out which databases were critical to an organization I worked at because the century’s biggest flood was coming. What if we had to relocate and run our business else where? Which systems were the most critical and which databases would we need to make available somewhere else? We were situated at the lowest level in the city, and would likely have to move if our core flood prevention methods failed.

Now turn the tables for a minute – if I had a team of ten database resources working everyday to keep the systems supported, two system resources, a security guard and a building maintenance resource, how many could be affected by a pandemic if one should hit my city? Who would decide what needed to move? Or more likely – what database operation or support function didn’t need to get done for some undefinable future?

Now even more likely, if you have a call list, what are the chances that someone on that list would be affected? How would you contact the others to get replacements if the city or area is engolfed in chaos. As the presentation suggested, many wouldn’t want to leave their homes for fear of being affected by others. Do you have a plan in place by your business architecture as to priorities for keeping your minimum technologies running?

Just a few thoughts that got me thinking about what I might suggest to a few of my customers that have been thinking in reverse for years. Business Architectures must be in place and current in order to make such rapid decisions, and the value of these exercises is most often over looked.