Clarifying the roles of Architect and Analyst

The diagram represents the boundaries and crossovers between Architecture and Analyst roles.

The Enterprise Architect:

• Needs to use the deliverables from all other architects to formulate the architecture of the enterprise.
• They should understand the roles of all other architects and define the architecture strategy for the enterprise.
• Recommends the strategy for developing the project portfolio to aligning with the Enterprise.
• Interacts with the Program Manager and business stakeholders to provide guidance over the project investment.
• They could be caught doing Program Management, Business Architecture, Application, Architecture, Application Architecture, Technology Architecture.
• Delivers strategic direction to the Enterprise (Includes all divisions of the business)

Business Architect:

• The Business Architect needs to analyse all business related information, processes, capability etc. to formulate the Business Architecture.
• Recommends the strategy for developing the project portfolio to align with business.
• They could be caught doing Project Management, Application Architecture, Enterprise architecture, Program Management and Business Analysis.
• Delivers Strategic direction to the Enterprise architect if one does not exist the business (Not IT)

Business Analyst:

• Should analyse the business and applications under the directive of the project portfolio (Project Manager\Program Manager) or the business architect.
• Are sometimes asked to do all forms of solutions, data and business analysis.
• Their deliverables are something that the all Architects uses to formulate the architecture.
• Often offers the best value given that they cross over so many role domains and that they are so cheap by comparison to all the other roles.
• Can be caught doing elements of: Project Management, Business Architecture, Application Architecture, Technology Architecture, Information Architecture, Solutions Analysis, Data Analysis and if they are really unlucky development, design and testing!!

The total cost of all of these roles is around the 1.5 million hence the reason why business analysts are a good value commodity. For a business analyst working in an environment where there is not the level of architecture support their work is often geared around fighting fires or applying band-aids. Business Analysts often aware of the impact of the band-aid strategy fight tirelessly to do the architecture that is required to make sense of the chaos, hence why often they mistake that the work they do around architecture as being substantial enough to qualify them as an architect.

It is often much easier to justify the need of a business analyst given that the benefits that they bring are more immediate. The true benefit of an architect having such a long turnaround time means there is a conflict between the justification of the role and the quarterly return expected from the CEO to the shareholders. Getting into this role means you really need to be focused on delivering quarterly benefits to justify your worth to the business. The only way to achieve this is through pragmatic method with clear success criteria. To all architects that want to succeed my advise is do not go in there to just to model, look for opportunities one or all of these areas: Increasing Revenue return, Customer satisfaction improvement, Reduced cost through improved efficiency.

When looking for a job in any of these roles it is important that you identify what other of these roles the company employs to truly understand what you might be getting into. From my own experience I have gone in as an architect and found that because the business analysis and project management capability was so weak I was forced to take on these roles otherwise face the doom of never achieving change that I had recommended as an architect.

Enterprise Architecture - Entity Relationship Diagram

Introduction:

With many sorts of EA tools and Meta Models surfacing and claiming to offered the best method of doing EA. Currently there are probably three very big questions that many Enterprises will ask when they get their EA tool or select a reference or meta model for their enterprise:

1. What information should we be recording?
2. What are the relationships between what we record?
3. What is the best method of recording this and managing this information?

The first part of this project is discovering what information we should be recording and how the information is related.

The Above Diagram:

The diagram has been initially constructed using what has been discovered in Zachman and FIAF as EA information components. The information components have been deconstructed and related in the following way to give the viewer an idea of what they should be recording when they are carrying out EA.

The most important part of this project is to obtain a meta model that will map directly to an ERD where a database could possibly be built.

The Project Objectives:

1. To identify all informational component of EA and create a dictionary for a common understanding of these components
2. To bring together all of the informational components of EA and identify the relationships between them.
3. To create a meta model that will map the informational component directly to an ERD where a database could possibly be built.
4. To maintain the ability to view the information from any point of view i.e. Zachman , FIAF etc:

I would like to thank the following contributors:

Please feel free to email me any information and state how it may be used to: maclarkson@hotmail.com