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!

This week was interesting. The place at which I spend many minutes had a disaster. There was an explosion below the street, causing one unfortunate soul incredible burns, and an entire block the loss of power. Some residents nearby were without heat for over twenty four hours. That’s not good if you live in a winterious place.

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.