Implicit factors when architecting solution

Pranshu have mentioned about the skills required for an architect here. I want to add some more implicit factors that I have encountered while architecting solutions that can make difference between success and failure of a project.

Whenever I start work on architecting solution for a client, I make sure that I identify and keep an eye for the following

1. Identify the stakeholders – It is very important to identify the stakeholders in the project.
1. Business Folks - The business folks will provide the requirements, timelines, and scope and budget availability.
2. IT Folks - The IT folks will provide the details on the existing architecture, business applications, architecture vision and roadmap, maintenance schedule for the existing applications, environment guidelines, and standards around development, tools to be used and so on.
3. 3rd Party Vendors - In these days of multi vendor strategies, you may have to work and co-ordinate with the multiple vendors at the client organizations. If the other vendor is strongly entrenched, he/she can make your life miserable. The success of the project will depend on the co-operation. There have been cases where delay by the 3rd party vendors might disrupt your schedules and quite possibly even the blame might come on you for not managing the project properly.
4. SME – Next important group are the SME’s. It is very important to identify and blocking their time from the requisite SME’s on the project. You might want to book their calendar in advance. Lot of times, key people who understand the system might have left the organization (that’s why client gave you this project), so you may have to look at alternate avenues.
5. End User - This group might be internal. So make you meet the key people and understand their expectations from the project. They will form the key factor in the User Acceptance Testing phase of the project.

It is very important to carry both the parties along if we want to make a successful delivery. Further, identify the person who will be signing off on the artifacts that get produced.


2. Identify the priorities – Any project will have the following pull factors
• Time
• Money/Budget
• Scope

It is very important to identify the priority of each of these for the identified stakeholder. It will help you in identifying which is critical factor when architecting the solution. E.g. If time or go-to-market is critical factor, you might want to look at creating a simple solution. If scope is huge or not defines properly, going for an iterative approach will be preferred choice.


3. Identify the standards – Understand your client organization standards for everything – documentation, quality, software, hardware etc. The sign off on a deliverable can get struck because it does not satisfy the requisite standards of the client organization. Most of the Fortune 500 organizations have Software Review Boards – that take a call which software (including open source libraries) can be used for projects within the organization. Anything new, means more paper work and time to get the requisite approvals. Again here, the key IT folks can help you in getting the approvals on a fast lane.

Besides this, you still need to go through the rigors of approaching the project as defined. But the factors mentioned above are not really part of the regular project architecture and management process.

Filed in: Programming