IT Role Players

Today I had a conversation with someone about the difference between an analyst and an architect. This blog entry comes out of this discussion where I share my opinion about various Information Technology (IT) roles.

• Analyst - Someone who spends time analyzing, decomposing the subject matter and sometimes provides the best option depending on the requirements. This person is not involved in coming up with a noveau solution but rather is involved in doing detailed analysis. There are requirements analysts, business analysts, process analysts, chain-management analysts, financial analysts, technical analysts, security analysts, program analysts, etc. etc.
• Architect - This role is a confusing one. I have heard that it is every developer's goal to be an architect or this person is nothing more than a technically savvy project manager. I have also heard that an architect is nothing more than a glorified analyst. After doing Architecture for eighteen months, I have to say it is a hard job. (Don't get me wrong. Analysts also have a hard job since they have to extract their analysis from information which is explicit and implicit). Architects take the analysis from the analysts and synthesize a solution for the problem. The architects have to consider the tactical constraints and its alignment with strategic goals. This person has to constantly ask himself, "Does my proposed architecture satisfy the customer needs, align with the strategic roadmap, meet the project deadlines and can it be implementable with the current resources (i.e. resources, infrastructure, standards)." There are enterprise architects, application architects, software architects, solutions architects, infrastructure architects, services architects, data architects
  
• Standards Person - This person usually work in a Technical or Functional Group defining standards for a particular domain. He or she needs to have good analysis skills, architecture skills and most importantly have excellent written and oral communication skills. This person needs to level expectations with the organizations they represent in the Standards groups and at the same try to push their organizations requirements into the standards specifications. They have a hard job of strategically aligning the standards, (they are working on) and their working bodies goals and with the organization's goals. Word smithing skills should help. There are standards people are involved in technical standards, and process standards like Software Development Lifecycle (SDLC) and Configuration and Change Management processes.
• Engineer - This person is a problem solver and he is usually involved in the "weeds". Usually the architecture aligns strategically with the organization's goals, meets all high level requirements and meets all other constraints. However this person addresses the finer problems within the overall architecture and solutions that maybe temporary fixes or configuration changes. For example there exists a mission critical system which was architected perfectly however the user base has increased eighty five percent and currently the system is experiencing a significant lag time which is affecting a business process. The next release is in six months. This is where the Engineer steps in. He determines the problem, designs a solutions and implements it. He documents the problem, design and implementation for the architects in the next release. Voila! The engineer has saved the day again. There are software engineers, systems engineers, process engineers, test engineers, etc, etc.,
  
• Developer - This person takes the high level architecture, designs the low level design and then implements it. If the architecture doesn't address the details because the architect doesn't have the time to design low level specifications or if the architect is not familiar with the technology then he or she can leave it to the developer. There are usually software developers.
• Programmer - If the architecture is extremely detailed and granular then the programmer has to implement the design. This is done where systems are designed to interfaces.
• Administrator - This person usually administrates an IT function. A system administrator administrates the system by maintaining and optimizing it within the constraints defined by the architect and the engineers. There are system administrators, project administrators, program and organizaton adminstrators.
  
• Project Manager - This person is responsible for managing and delivering a project which has beginning and end states defined. This person has resources to manage and is responsible for the appropriate deliverables to be completed within the project timeline. This person is not strategic but his or her main objective is to meet the end state with the project constraints.
• Program Manager - This person is responsible for managing a program which inconsists of on-going projects, projects to be executed and projects that were completed. This person is strategic since he or she need to program goals however they meet their strategic goals via projects which are tactical in nature. These people are comfortable dealing with project managers and their projects.

Please let me know what you think. These are my thoughts and I haven't spent any time validating if my definitions meet PMBOK or PMI standards.

IT Architecture = Communications

For the last six months or so, I have been working for the US Government as a Services Oriented Architecture (SOA) Technical Lead. Eventhough that is my functional title, I act more as a Information Technology (IT) architect. It is my first job where I am an IT architect. At my previous job I was a part-time XML data architect where I did alot of data modeling, data analysis and then defend why I modeled certain data structures a certain way. When I was not a XML data architect, I was a JEE developer. Eventhough developers aspire to be an architect because they can get to design the systems and leave the grunt work to other developers, this may not be true when the developer becomes an architect.

Couple of summers ago, I took a class to become a Java Enterprise Architect and it is there I learnt that an architect doesn't have a set role. As a developer or a project manager, your roles are pretty much defined but an architect's role is ambigous. In the class, I was taught that one of primary responsibilities of an architect is to see his system or project succeed. In some projects, he can be coding and developing reference architectures and in other projects, he is basically working with the project manager in refining requirements. After being an IT architect for the last six months, I have to say that the instructor was absolutely correct. An architect's role is ambigious to a project but every project must have an architect. An architect is a rare breed because:

1. he understands what is being built and why it is being built
   
2. he can look at code and have code level discussions about the software code.
3. he understands the business problem and why the system is a value to the customer
4. he can work with business analysts in refining requirements or make them more abstract which might give the development team more flexibility
5. he can sit with the project manager and hash out a realistic Work Breakdown Structure (WBS)
6. he can recommend modifications to the project scope if the project is running behind schedule
7. he doesn't need to be the best programmer in the team
8. he doesn't need to design the system but rather review them
9. he doesn't need to write a test plan but he can evaluate it
10. he doesn't need to be a guy. Women can be architects too.

And the biggest trait an architect should have is that he or she should be able to

COMMUNICATE

with various stakeholders and he or she should be able to discuss the system in technical, non-technical, and business terms. Architects should be willing to exchange ideas with other architects and they should humble enough to accepts mistakes if they made them.

The role of an IT architecture will expand as more businesses go into collaborative modes of information exchange since they need to be aware of standards and they should understand the newer technologies. So for all aspiring programmers in the world, it's time to shelf the pocket protector, clean the stacks of burnt or blank CDs, get a haircut, stop living on Red Bull and be more social. Try to interact with your teams and peers since a great idea is bad idea if you cannot communicate it and a better idea is to have your good idea validated with others.