Here they are: for each category “Architect”, “Business Analyst” there are a number of sub-categories
I normally think of three levels of Architecture:
- Application – addresses evolution and delivery of a single application (small set of highly related functions), activities include:
- Partitioning functionality within an application.
- Developing best practices.
- Assuring flexibility to meet current and immediate business needs.
- Platform – addresses evolution and delivery of a multiple application for a particular business area (applications grouped by functionality/user community), activities include:
- Assuring a commonality of results.
- Providing for fine grained interoperability.
- Developing frameworks that allow multiple applications to ship on a common substrate.
- Building in flexibility to meet business developments on the planning horizon (this year/next year goals) for moderate-sized groups within the company (~100 people)
- Assuring that a substrate achieving these goals is in place so the applications can pick it up at the appropriate time.
- Identify core data elements and services that will be important over the strategic timeframe.
- Assure that there is an appropriate mix of flexibility/capabilities to meet strategic goals e.g.,
- If acquisition of companies is a strategic goal, methods for rapidly merging personnel, purchasing, and operational information systems are important.
- If acquiring products is a strategic goal, capturing data about supply and delivery chains etc. is important.
On the business analyst side I similarly think of three levels:
- Department Level:
- What are the processes involved in performing a function: including as is and to be states?
- Division Level:
- What is the external business goal that is being addressed?
- Is this the right way to address it?
- Should functions be merged/refactored?
- What are the strategic business differentiators going to be in the business that we want to be in 3-5 years?
- What must the business look like to support them?
At all levels there should be some time spent to look at potential inflection points that might radically change the structure of delivery and build in flexibility to address that potential, e.g.,
- For architecture think outsourcing, software as a service, location aware computing, etc.
- For business think increased competition in product acquisition, competition from generic products, regulatory/legal landscape.
How these various functions are actually assigned to people depends a lot upon the scale of the problem, the level of risk/uncertainty, the talents of the people involved, and the flexibility of the organization. At one extreme, a star performer building upon a solid platform architecture (in the sense used above) can be a combination business analyst/application-architect/developer for a system serving 50+ users in a non-validated environment.
I think it important that business analysts are able to understand the business processes and vocabulary well enough so that there is a good transmission of information between those expressing the needs and the analyst. This implies a greater stickiness between the analyst and the user community than is necessary for the architecture or project management functions.
Similarly there are commonalities in the level of abstractions used in the architecture level (Application, Platform and Enterprise) that imply that levels are sticker than business areas or technology.
In theory, project management is more transferable, but the stickiness here revolves around legal requirement, diversity of end use (geography, user types), system novelty.