1 February 2008

Nick Malik on Enterprise Architecture

One of the roles that project managers and business analysts interact with is the Enterprise Architect. PMs and BAs are different to Architects, but they all play around in the same space of designing and implementing the future of the organization.

I thought I should explore the role to deepen my understanding of it. So I went to Nick Malik, blogger and Enterprise architect at Microsoft, which is a largish organization that some of you may have heard of.

He was generous enough to share his views with us here;

1. EA, done right, gets involved before PMs do.
There is no project yet... just a business goal. EAs help the business decide if they should create a project, and if so, what area of the IT infrastructure to focus that project on. Once the project starts, EA is basically a governance job. So if you dislike governance (and we all do), and you find yourself wondering what value EA adds, perhaps you are missing all the work that goes on when you aren't in the room.

2. EA has two jobs: Project portfolio and Application portfolio.
If you look at their work from the standpoint of one, and not the other, EA people will appear to do crazy counterproductive things. You have two choices: try to see the world from both viewpoints, or trust your EA.

3. Business architecture adds the most value when they point out that the business is about to spend money on something foolish.
If your job as BA is to demonstrate alignment, without ever demonstrating a lack of alignment, then you are skipping the fun (and valuable) part.

4. The future cannot be found in an ivory tower.
That said, if someone doesn't spend a LOT of time envisioning the future, then an IT division is doomed to wander aimlessly. Support the envisioning work that your EA is doing. On the other hand, the ability to envision may or may not come attached to the ability to communicate. If you can't see how to use the work of an EA in your project, ask him or her to explain it to you. If he cannot, tell his manager. Don't let it lie. Things get worse when you (a) ignore the EA, or (b) allow a bad EA to linger. Every profession has a few turkeys.

5. Some EA folks assume that the PM will simply accept EA requirements into their project and "go sell" the requirements back to the customer.
If you meet an EA of this stripe, tell him to sell the requirements back to the customer himself. If he cannot, then the EA should pony up either the governance, or the cash, to get standardized or external requirements into your project. Don't sign up to spend your customer's money on standardized or external requirements unless the business signs off or funding appears from another source. EA is not free. Make him work for it. But once a requirement is in, treat it as seriously as any business requirement. If it is in, and funded, make sure it happens.

6. The EA is not responsible for organizing your project or bringing it to fruit.
The PM is. However, the way in which the project is partitioned, in the architecture, may place intricate interdependencies into the system, making a well designed project impossible to deliver. Therefore, keep you architect on a tight leash. If he creates an intricate design, especially one based on SOA, get him to also detail out the order in which the components are to be coded, integrated, tested, and rolled out. If you don't, you could end up signing up to drive in the Indy 500... in a bus... backwards.

If you would like to read more of Nick’s thoughts, his blog is “Inside Architecture”.

No comments:

Post a Comment