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
As enterprise architects, we attempt to capture business strategy and put some alignment to our IT Strategy, and formulate an IT Current State and IT Target State architecture. The IT plan is the people, process and technology initiatives that we plan for the year, and potentially two or three threes out to move towards IT future State.
We have to have an understanding of the business strategies, priorities and external business environments to drive the overall strategic IT objectives. Analysis of the business changes and priroities drive the characteristics of the IT products and services, IT governance and the required IT capabilities.
IT Architecture is how we plan, and the basis for the efforts that we employ during the year to move closer to our goals. Definition of the technology, application and data architectures enable the IT strategy. Each must align with the business architecture, or functions and processes that we perform as an organization to sell or provide service to our customers. Effective IT planning is derived from tactically focusing on closing the gap between current state and target state.
The technology landscape is where my thoughts lie today. IT strategy is a business driven lifecycle, and it’s difficult to jump directly to the technology landscape when reviewing the linkage and relationships from the business. IT planning is an on-going event constantly refreshed to meet the shifting future state. It makes sense after we determine which data we need, and what solutions we will use to provide or manipulate that data. It is only after this point that we can determine which technologies we will use to deliver these solutions.
What if we consider the big jar and the stone philosophy? We have a large jar, and we fill it first with big stones, then smaller stones, then pebbles, sand and water to fill it. Our large stones in the area of technology architecture shouldn’t change often. Meaning – if we have an IBM mainframe solution, using a Nortel or Cisco network, and HPUX server farm, we’ve determined how we general want to continue to operate. Although we may have quite a mixture, we should generally know what our general direction is on the larger technology components each year – or which direction we intend to move as big changes are made.
These technologies will rarely have wholesale changes. Our technology landscape will generally stay the same, yet each year we must consider which larger and smaller scale changes should be made. There are none that should be made purely for sake of change itself, nor for the sake of “cool and new” technologies, unless innovation is our core business product.
In saying this, we as technology architects have the best chance of putting together our target state with the most certainty. Each solution and information requirement will cause us to change direction somewhat. We as technology architects should attempt to map how our technology components match to the business drivers in our strategic plans, but if this isn’t possible for us, or resides with our enterprise architects, it behooves us to have a very good understanding of the categories of technology components that we carry, the ones that should be slated for replacement, and those that should be enhanced.
Technology Landscape is most likely the most straight forward target state of the three domains. The minor stuff like lists of specific point software, appliances, etc. can be added as our needs are nailed down.
If technology architecture interests you, watch our seminars page at www.architectbootcamp.com for more information.
]]>The place I spend many minutes were incredibly equipped to deal with the disaster. They have a DRP appropriate for their size and focus. We had PC’s to work on in another facility within 120 minutes. The PC’s were not equipped with the software which most of us needed, but we were able to spend some minutes doing something productive in most cases. Two departments were sent home, as there were only so many PC’s, and only so much spare space.
In contrast, there were vandals who were also disgruntled employees of a large tenant company in the same building in which I spend many minutes. They decided to use the fire hoses on the top floor and play games by filling the stair wells with water to express their discontent. Their employer decided to only pay them for a small portion of the day of pay they lost for that same electrical interruption. With only four weeks before Christmas, and being paid only marginal amounts over minimum wage, can you see the point of aggravation?
Now all companies affected must pay an insurance company to clean up their messes in offices that span the building, and the insurance company gets to collect several premiums because all tenants affected must pay, and the restoration company will pretend that they can do all of the work and make things right. And, next year and for the next five, all of these affected companies will get to pay some rich insurance companies extra premiums for bad experience.
Do I sound facicious here? I definitely am being so, as I have been the victim of water damage once and had to use that same restoration company. Believe me – you don’t ever want to encounter this so go right home and make sure you have the bullet-proof hoses on your washing machines, buy a water beetle and hook it up to your alarm system, and definitely ensure that the little birdies outside aren’t making nests in your bathroom vents so that vents are forced open and pipes may freeze.
Also – I am facicious because I have seen that tenant who employs the vandals exploit their staff, vendors and suppliers. If they would have coughed up the dough to pay a full days’ pay, or had a disaster recovery plan to enable the workers to do something else productive, none of that would have happened.
I continue my attitude as I had dinner with colleagues the day following the incident. We all shared work experiences and customer stories of the places in which we are spending many minutes. I found it humourous, then aggravating that one was spending two years of a client’s money creating a DRP and they still didn’t really get the point. Most companies who embark on DRP’s shouldn’t really call them that. They should call them their “how to get my technology all up and running”. Most have limited budgets and cannot begin to create a plan to recover everything. What about the business?
Why bother? Is everything that important? Is the little system that your company uses to catalogue the books in your IT library, or the research reports employees create when they really should be doing something else important? Yes – these things are great to have, if you actually had a reason for creating them, but is more than a back up really that important.
You knew I’d eventually get back to Architecture – I always do. I eat sleep and breathe the stuff. A great EA can completely replace the need for the kind of DRP these companies think they need. If your business functions are well (and I don’t mean completely) documented, and you know which ones you need to keep the $ rolling through the doors, and what their priorities are, why spend the equivalent of three or four peoples salaries in a year paying a consultant or two to write you a plan to recover everything you have as fast as you can? Believe me, some stuff can wait, and a backup of the data is likely sufficient.
If you need to get help on a DRP plan, I suggest you find someone who understands the concept well. If you want to completely document your technical architecture, good for you, but tying it to the recovery plan will only delay the process. The two should be separate endeavours and it should be pretty easy to figure out which one comes first. Key word is should.
There – the satiristical side of me. I promise to behave next time out – this was a tough week to feel productive.
]]>