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 attention.  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.

Want more info on Enterprise Architecture?  Visit the portal

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

Happy Architecting
Sharon

If you ask just about any IT Director, Manager, or even PM, they’ll tell you that Architects are amongst the toughest resources to find.  I’ve experienced this so often either when helping clients build their teams, or when I’ve tried to build them myself.

Architect Boot Camp training was designed to help organizations train their own staff, or to help those in IT who have an affinity towards high end design & IT Strategy, but want to hone or learn Architect Methods, Process and Approach.  The objective is to deliver the theory, while using real life scenarios and then practice through case studies and exercises.

This fall our IT Architect Boot Camp workshop is now full, and we have but one spot left in our Solution Architect Workshop.  We had to move to larger space to deliver the workshops, and I’m sure with the great mix of staff and experience, they’ll be a good experience for all attendees.

If we can’t find architects, we’ve got to grow our own.  We need to optimize our IT dollars, and now more than ever we need to make sure we’re building and designing the right things.  Just ask John Zachman - he’ll tell you that Architecture is the ONLY way we can improve our success rate.  Only three days to go until the start of this first public offering this fall, so this blog entry will have to be short.

By the beginning of November, there will be several more architects ready to provide value to their organizations.  We must applaud organizations who believe that investments in their people are good ones, and won’t be impacted by rough economic times.

Happy Architecting

Long time, no type. I’ve been busy - but now have the time that this deserves.

I’ve just spend a near year acting as the Chief Architect at a large Canadian insurance company, and have many thoughts and insights I’ve love to share.

Here is one of the first.

Often, an architect, especially the chief architect, is asked to make an architectural decision. Typically, an IT resource is asking him or her to make the decision, but what needs to happen is the requester has legwork to do.

Typically, a high level assessment of what would be required to deploy the decision in the prospective environment is necessary. It is typically works done by their team, or by operations, or an application team.

The goal is to provide you with some key drivers you can use to make an informed decision. Although we would not perform a detailed assessment of the technology or solution, we would examine it at a high level the with the resources at hand.

The requester should then present this to the architecture team so they can make this architectural decision an informed one, and ensure the deployment on the platform of choice is valid.

In detail - the requester needs to do the following:

1) Assess and document the root problem being addressed.

2) Provide an overview of each option / alternative.

3) Give a Summary of evaluation criteria

4) Give a Comparison of each alternative relative to evaluation criteria.

5) List of “Implications” and “Impacts” of the recommended decision (assuming they have a recommendation).

Ideally, we’d like to reach a conclusion in the meeting together. Typically, questions that arise because resources are asking for a decision tend to raise a lot of questions when presented for the first time - leading to take-away work to gather specific information /research to feed a final downstream decision.

Time is usually in short supply, we’ll attempt to work to the goal of a recommended decision within the meeting and the architecture team can provide guidance on the type of trials, prototypes and tests required in order for them to either raise this to the architecture review board, or make their decision.

Happy New Year! It’s nice to be back again and writing about my favorite topic.

This spring I’m speaking at the Enterprise Architectures Conference on Quick Wins in Enterprise Architecture so I thought I’d share a bit of the content.

Enterprise Architecture as a new program within a company or an organization is difficult to kick off. Often there are so many things that need to get done, that we are overwhelmed. We might resort to following recommendations or readings we might find in a book on EA, or from a paper, or even a framework.

Many newbies will get a framework and attempt to start filling in the cells. Others might pick up Spewak’s book, or some other writing and start with a pure planning method in which we capture Goals, Drivers, Strategic Direction and then Current and Target state with hopes that it will eventually turn into a migration plan and eventually projects and a set of standards and principles.

If you make a quick list (take no more than a hour to do this) of the things that you would like to include in your plan and then EA projects that are most needed at your organization. In speaking with my CIO today, he said that a list of what we had depicted graphically with a target state mapping and then a status for each technology with respect to “contain, expand, conclude” or other such terminology to state plans for their use going forward. Even in a very large organization this is relatively attainable unless you are very distributed.

It is perfectly acceptable to have multiple technologies within a domain. For example, you might designate one database technology for small and medium applications, and another for large enterprise applications or solution specific applications where there is none or little choice.

Statements as to whether or not you will acdept or embrace open source, and the types of platforms that are suitable for technology “families” or categories of activities to be performed on one particular type of service (Unix flavoured or Intel for example), is also very helpful. General guidelines will help teams when they are searching for solutions.

Well - this is just a hint of what will be included in my topics and further writings.

Happy Architecting!

Mergers & acquisitions – Calling All Architect’s – We’ve Got a Merger & Acquisition

What are your IT Project Priorities – do you have one of those “Yours, Mine & Ours” situations???

What I mean is that when a business decides to buy another company, or merge with one, often there are multiple perspectives to project priorities. If one business arm decides they need a bigger sales force, and another wants to gain proficiencies in a manufacturing process, there may be conflicts. Add the fact that the IT area wants to streamline, yet add or upgrade technology infrastructure, we’re cooking up a recipe for missed expectations.

The IT Architect needs to understand what the end goals are by the business when creating the architecture. If you want to read more on ensuring you understand the right messages and goals, why don’t you check out my information site - Mergers & Acquisitions and the Information Architect is an article that addresses this topic.

It’s a sample exerpt from our eZine “The Architect Abstract”. Head to the site to sign up to get a copy every week, or view the sample articles to whet your appetite.

Happy Architecting!
Sharon