Perils of the Pakistani IT manager

Though as abstract as the IT manager’s work may seem, life in the Pakistani corporate Diaspora does not come without perils and catches of its own.

Given that the technology turn over rate in most corporations is considerably high and  most IT services are still in their nascent stages and most IT managers find themselves furiously trying to integrate their IT departments technical expertise with the rest of the organizations business domain. though as laudable as their intentions are, the primary

A successl enterprise architecture project can help unlock an IT department’s true value to the business it supports. EA, as a discipline, allows an organisation to compare its near-term business objectives with its current technological capabilities and then make intelligent decisions about what it can reasonably expect to accomplish. Furthermore, the gaps that are identified represent opportunities for future IT investments.

Sound like a lofty endeavor? It is, but getting there isn’t as difficult as you might think.

Developing a good enterprise architecture program shouldn’t require a dedicated full time staff of specialists. A team led by a strong, focused manager can jump start an EA program by creating small deliverables that the business stakeholders can understand. (Hint: If your program’s objectives can’t be described in an elevator speech, have your team step back and simplify.)

Work with representatives from the business side to set up four easily understood documents. If the business people have a chance to offer input, they should be able to understand the business value of each phase of your EA program.

This discussion will focus solely on Phase 1 of an enterprise architecture initiative. This phase should include the following:

• The Foundation (principles and objectives)
• The As-Is Architecture model
• The To-Be Architecture model
• The Transition Model (i.e., a road map)

If you take the time to fully develop each of those documents, you’ll lay the groundwork for discussing valuable opportunities for improvement.

The Foundation document should state your organisation’s definition of EA success. You need to be specific here; avoid big words and esoteric ideas. Ask yourself what criteria will be important when you’re deciding how to balance IT-driven objectives with companywide interests. You might end up with principles like these:

• We evaluate solutions based on scalability, extensibility, interoperability and compatibility
• We use off-the-shelf tools
• We integrate enterprise security into all aspects of technology, from the physical to the virtual

Whatever they turn out to be, your principles should be reviewed with all members of the IT team and the business team. They will be used to drive all future discussions and decisions.

The four phases of EA

The first phase of an enterprise architecture project paves the way for the others.

1. The Foundation, the As-Is and To-Be Architecture Models, and the Transition Model. This phase establishes the criteria used to guide decisions about IT, models the IT architecture today, identifies where IT should be in three years and then describes how to get there.
2. IT Vetting and Communication. This involves an in-depth review of IT projects and the road map, as well as the plan for communicating with the business about the project.
3. Business Alignment and Governance. This phase contains a review of the business needs and the development of the processes needed to support them. It is interactive with the business.
4. Deployment, and Portfolio Metrics. The three-year road map is implemented, and metrics are used to continually track, review and refine the programs.

Once your Foundation is complete, you can move on to documenting both the As-Is and To-Be Architecture Models. These documents should graphically represent the organisation’s current and desired enterprise architectures. Remember, simple is better. Try to keep each model to one page. If you’re stumped, search the Internet for sample frameworks and look for examples from parallel industries. Be patient, developing the best model for your organisation will require a few iterations.

In the beginning, there may be a learning curve as the IT team determines the appropriate level of detail. There will be a temptation to list the hundreds (or thousands) of software applications that your organisation has, but it’s the summarised information that is critical to capture. Keep your EA team focused on developing a model, the details can be filled in as the team moves forward.

Your model could have a hierarchy like this:

• Enterprise (the complete environment)
• Domains (independent categories, like Infrastructure)
• Categories (logical subsets, like Network/Telecom)
• Elements (the most granular support functions, like Routers)

Once your team defines all the relevant technology domains for your business, the elements can be prioritised according to the ROI for each element’s improvement opportunity. For example, the elements could be colour-coded, with red drawing attention to a high ROI opportunity, yellow for medium ROI and green for a low ROI element. Don’t be afraid to change the ranking of each element on the To-Be Model as new information becomes available and corporate strategies change.

The road map

Finally, you’ll need to explain how you plan to help the business get from the As-Is Model to the To-Be Model. The best way to do that is to create a graphical road map. This is the final deliverable in Phase 1, and it’s a critical component that will help ease senior management’s angst about the path forward. This key transition moves the project from an IT focus to a discussion about the business and improvement efforts.

The road map should include deadlines for achieving each part of the To-Be Model, and it should show the organisation’s progress toward each goal. The road map should depict the phased implementation of projects so business people can review the timeline. If business executives don’t agree with the timing in the road map, they can speak up and make adjustments.

Using colour coding, the road map can also demonstrate how the business changes throughout the process; for example, along a three-year span, a project’s priority may change from green to red based on agreed-upon criteria.

The road map is a great asset that should be used to continually articulate the value of your EA program to senior management.

These four deliverables will become catalysts for meaningful discussions with your business counterparts using a common language. They’ll provide the business with insights for determining which IT projects to fund, based on the colour-coded priorities. And you’ll have a road map showing how you’re going to get from where you are to where you want to be.

http://www.computerworlduk.com/how-to/careers/3171/how-to-draw-an-it-road-map/