I came across an interesting article forwarded to me by some information architecture friends. The article on the discipline and role of Information Architects (IAs) was written by Jesse James Garrett in 2002 and the issue of defining the roles of information architects that they were struggling with back then, are very familiar issues that we are now facing as BAs. If you enter the phrase "defining the damn thing" in Google you can still find remnants of that debate.

Garrett argued that there is a discipline known as information architecture as well as a role known as information architect and that they evolved hand in hand, but that the time had come for change. Similarly, just as there is the discipline of business analysis, there is the role of the business analyst.

If we define the discipline based on the role then we may potentially be too broad, as the role of a BA varies from organization to organization and encompasses BAs working as commercial, process, financial, technical and systems analysts. Organizations representing business analysts are looking to certification or accreditation as a way of defining the role, and bringing in some level of standardization in order to decrease ambiguity in the marketplace. Garrett, however, cautions that if we go down the track of defining the role we inevitably threaten someone's sense of identity. If the BA's role differs from the organization's job description, then does it follow that they are not business analysts?

Alternatively, if we define the role based on the discipline, then whatever the field of business analysis is, those who are specialists in this field are business analysts. This definition however could, in practice, become too narrow. The potential to be "boxed in" may result in BAs having little influence or control over important aspects of projects, where BA competencies and capabilities are of great value and add strategic value to organization goals and objectives for process improvement.

As a BA I'm more often involved at a strategic level.  Rather than my involvement with projects ending with the delivery of requirements, I'm utilized throughout the project: I bridge the gap between the business and the technology team; review processes and operations; as well as investigating and advising on the project's impact and dependencies on other systems and programs initiatives across the enterprise.

All this activity means my role is not easily defined. This is not because I'm trying to be all things to all people (the Project Manager, the Business Analyst and the Systems Architect) or take over another project team member's role, its more a reflection of the discipline of analysis being increasingly seen as a core capability and that the frameworks and tools used for analysis can be drawn upon for expertise throughout the life of the project, and through all the programs across the enterprise.

In short, as a business analyst I do lots of things. Don't put me in a box or label me and don't predefine what I do ... it limits the possibilities for my involvement to add value within projects, between projects, across programs and across the enterprise.

Garrett suggests that we seem to be at an impasse in the definition debate:

 "Any definition broad enough to encompass the role is too broad to foster useful discussion of the discipline; any definition narrow enough for the discipline is too narrow for the role....basing either definition on the other means one is going to be insufficient. Trying to do both at once isn't working, producing a classic chicken-and-egg problem".

This is where our business analysis "Community of Practice" can come together to shape the future of the profession. We should define the scope of what is business analysis as a discipline. Once we achieve this end, this will empower us to look at what the discipline offers in the way of frameworks and tools to interested practitioners, as the specialists in this field.

Ultimately, the definition, role, responsibility, and the future of BAs will be determined not by us, but by organizations that will base their decisions on their resourcing needs. It is therefore up to us as a Business Analysis Community to continue to promote what we do and how we do it, and share our knowledge, understanding and expertise within the community. By doing this as a community, we can go out to organizations and showcase the capabilities and competencies of business analysis. This will show the value of the discipline regardless of the role within the organization.  Instead of prescribing what a business analyst is or isn't, let's talk about our frameworks, our theories and what tools are out there to get the job done.

Maria is the Regional Lead for a Business Analysis at SMS Management and Technology and provides advice to her colleagues on developing requirements specifications for appropriate IT systems to support clients' programs and initiatives. She can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it. .