I like this post. I consider what The trends are positives for 2012.
Glenn:
Taking a more Agile approach, hybrid BA/PM, better interaction (i.e., presentation skills) with stakeholders, etc., are all great forward steps. The question I have is: Are BA's mature enough to grow along the lines you mention.
I really doubt it. I will go so far to say that vast majority of BA's can not even articulate how to accomplish the basic essentials of analysis.
Without knowing how to logically partition a system and unawareness of the non-sequential nature of systems, to give two examples, BA's can not move on move to the higher level goals that you mention.
Tony
Tony: I am not quite sure what size work environments you gained your experience, but in large financial and government agencies, the lines of communications can get complex. The CEO or VP of Marketing doesn't care how a server disk will be partitioned. Executives only care about results. The role of the Business Analyst is to make sure the stakeholder requirements are communicated (written or verbal) to the server engineers. I remember having a two hour conferfence call with 150 people discussing the pros and cons of a double nic network card. BA's are essential to the success of any large enterprise application especially when there are heavy deadlines and stressfull situations.
Glenn:
By " logically partitioning a system" I mean dividing up the business requirements in a way that leads to effective decomposition. And effective decomposition of requirements is necessary in complex projects.
Common dictionary definition of analysis: Partitioning a system into its component parts and then examining how the parts interrelate. Analysis, especially of systems, is largely about partitioning.
With out partitioning skills, I do not think that BA's are near being able to move on to higher level goals.
Tony
Glenn:
I like the post as well. I totally agree with the trends and it is a very positive indication that BAs will play a critical part in the success of projects as always!
Tony:
I am not sure what you mean by the statement "vast majority of BA's can not even articulate how to accomplish the basic essentials of analysis."
This is really not true.
I have been a BA for at least 15 years now and I see that many BAs do have the maturity level and are already playing the critical role with stakeholders, involving themselves with business case and roadmaps for the organisation.
I have been through at least 9 different organisations during the last 10 to 15 years (as a contracting Senior BA) and have seen at least a few BAs in every organisaton with that level of maturity, width of knowledge, playing a great part in large projects.
I am not sure whether your experience with BAs is where someone who is not a professional BA is playing the role of a BA.....
Charu:
Let me give you an example of what I am talking about. Especially iIn larger scale analysis efforts, effective decomposition (i.e., partitioning) is needed to handle complexity. And this decomposition often needs to go downward many levels If this decomposition is not accomplished in a logical way, the result is a mess.
What guides you through a logical decomposition of the system at hand?
Note: This is an example of a basic, key, fundamental BA skill requirement that very few BA's are even aware of. Not even the BABOK really talks about the need for such skill. And with a knowledge of the basics, BA's can not move up the maturity scale.
Tony
Hi there Tony,
You make some valid points in your comments and others that are somewhat of a cause for concern. I think it's a hasty generalization to comment;
"Are BA's mature enough to grow along the lines you mention.I really doubt it. I will go so far to say that vast majority of BA's can not even articulate how to accomplish the basic essentials of analysis."
My approach to this is that BA's really have had a bum rap in getting executives and management to buy into the value of business analysis, I believe both parties are to play and as a consequence we are really only starting to see investments in competency development for both functional skills and soft skills. Being a senior business analyst I'm certain that you would agree with me that you simply didn't not jump into this role with an inherent ability to " how to logically partition a system and unawareness of the non-sequential nature of systems". With experts such as yourself I would hope that some of your time is coaching and mentoring some of the intermediate and junior BA's to inherit that which is so vital and critical to the success of requirements management and development activities.
Glenn:
You and I must live in different worlds. Based on alot of experience I will go further than my initial statement: to me it is really shocking how many at the executive director level can not articulate how to accomplish some of the basic essentials of analysis.
The basic skills that I refer to - like how to partition a system for effective decomposition - are not skills that require alot of experience to understand. I learned these skills in an introductory Requirements Specification course back in the 80's.
What has happened since the 80's? My observation: the increase drive for firm due dates has caused analyst to, move away from performing analysis to seeking the safety of implentation. Hence, alot (most?) of BA's are really implementation coordinators of some sort.
Now adays if BA's perform analysis, it is typically analysis of smaller scale systems. Hence the populatity of small scale analysis techniques such as BPMN and Use Cases (both of which, for example fails to provide any significant provision for decomposition).
Regarding the trends that you mention in you article. To me it is clear that Business Analysis can not move forward until the focus is once again on the essentials of analysis.
Tony
Tony,
While we might live in different worlds I think fundamentally we are in agreement that there is much learning and development to done by business analysts today, further to that, this can only be accomplished with an inherent understanding, strong support, and a continued investment in time for enterprise wide requirements activities.
I am in total agreement that the drive for firm dates has forced the hand to sacrifice quality, this for me is a reflection of the lack of consideration for quality competency as a result of the lack of understanding of the role, much as you have stated in your opening line of the last comment....
I do appreciate your comments and feedback, thank you.
Glenn:
Thanks for your informative feedback!
Tony
Tony:
Thanks for providing the clarification - I understand what you are saying.
There can be no book or theory teachning how a BA accomplishes this skill of effective decomposition in large scale projects - this purely comes from a basic "common sense" that BA has to have to be a professional BA (well, this is my definition of a BA - without this, a person cannot claim to be a BA, in my opinion!)
Any person to be caled a BA must have had some ability to analyse current scenario / processes and map the future scenario / processes. Without this skill, we do not call a person a BA.
Havign said that the above skill is with a person, and we have called this person a BA, then comes the functional understanding of the "TO BE" scenario / processes.
Again, without this functional understanding and clarity, the whole project does not commence or cannot mvoe towards a solution.
Assuming that we have now started moving towards a solution, decomposition or logical break-down is a basic need without which we cannot proceed with even prioiritisation or plot parallel tasks or even think of the critical path for the project.
While I agree with the needs for such skills, what I am trying to say is, any one who calls himself or herself a BA must have these natural abilities that comes from soem experience + common sense + a natural flair (just like how a novelist has a natural flair with language / vocabularies).
It is actually such skills / abilities that makes a person move towards a BA profession.
And, apologies for missing the spelling (typo) mistakes - again a natural skill a BA should not have missed!
I think it is worthwhile to distinguish Business Analysts from Business Systems Analysts. IT Analysts vary in their breadth. Some are more technical, some are less so. Some are very much about the software life cycle, some prefer the big picture. A lot depends on the environment rather than the analyst. A great deal of work done by some business analysts in my organization is project management, research, strategy, methodology, modeling (in addition to requirements, testing, and so on). What's being challenged is not only the BA role but the role of the IT unit as a whole. Let's also not forget that Business Analysts in some organizations have nothing to do with IT at all. So, we should not assume that BA=BA when we ascribe characteristics to them.
The focus on "decomposition of system" feels dated to me personally. As I am not a Business "Systems" Analyst, perhaps it's outside my sphere. I would say the skill in question is, more broadly speaking, organizing information, and it's not limited to systems (broadly or narrowly defined), and includes synthesis to a great degree. Moreover, factors like systems thinking, design thinking, prototyping, service (as opposed to functional) orientation, and BPM are challenging traditional approaches to how systems are described and what the "system" is.
These observations certainly do not reflect a majority of organizations (or even my organization), not yet, but there are promising trends on many fronts. That's where my thinking is heading in any case. Cheers.
@Tony: I now understand your perspective. if you would like to make suggestions for the next IIBA BABOK review here is their link: iiba.org. Chapter 6 and Chapter 9 address Requirements Analysis and Technicques.
I agree with VMalik a BA is different than a BSA, but I notice lately most companies would like to hire a BA with some system analysis skills. ( I guess to save money).
The "decomposition of a system" can be very complex and quality should not be sacrificed.
Gathering requirements and partiioning a system for NASA or the military obviously requires an engineer or Lead Architect to breakdown or architect the system based upon IEEE method vs. a finance workgroup application which may use IIBA knowledge or the Zachman Framework.
When I am reviewing a large enterprise, the first thing I do is to review what "hardware" or "software" companies they have partnered with and then understand what "process or business initiative" needs to be improved (for example, billing or accounts payable).
For new BA's, all the tools and methodologies can be overwhelming.
I also apologize for my spelling typo's and grammar. LLMABA.
@Glenn, it would be great to understand what enterprise architect tools (i.e., Enterprise Architect, or IBM Rational) are being used by various industries.
Thank you for your article. It helps to keep me focused.
LLMABA
Comment for Charu:
I must disagree with your statement that there is no therory to conducting decomposition of a system. Data flow diagrams for one are largely all about a formal, logical approach to decomposition.
Decompositon of a not-really-large system can go down 4 to 5 levels. Such requires more than common sense.
Tony
Tony:
I think there is a difference between Technical Decomposition and Functional Decomposition.
Functional decomposition depends entirely on the system / industry, business priority and what is deemed as the most important part of the system functionally and a logical breakdown of the solution / system.
Assuming that Agile methodology is used, the high priority business requirements will need to be implemented first.
But to implement the high priority business requirements, of course, the BA will need to work together with the Architects and senior developers in understanding the architecture of the proposed solution, the technical complexities and dependencies.
The approach that is usually taken is to look at how do we implement the high priority business requirement by starting with the necessary dependent technical elements.
What I meant by "BA common sense" is functionally splitting the system into logical parts ..........and this will entirely depend on the functionaliy and the functional components of the system. It does come from a full understanding of the functionality that the BA will need to have after havign gathered the business requirements and taken part in the finalisation of the functional solution.
I have not come across much guidance of how someone functionally breaks the system ...........and this is what I was trying to express.
I totally agree with you on the Technical Decomposition side.
Charu:
I focus most heavily on the unchanging (i.e, essential) business requirements. This means I deprioritize the mechanism used to accomplish a function/process. Let's say, to keep things real simple, that it is an essential business requirement to be able to add together two single digit numbers. There are various mechanisms (i.e, means) that could be use to accomplish this task: a J2ee platform base servo modulator, a person, electronic circuits, or Fido the wonder dog (yes a dog can be trained to add together two single digit numbers - I saw it on TV).
My primary job as a BA is to indentity the essential business requirement: Add together two single digit numbers. Now whether the j2ee platform is the mechanism used to accoplish the funcgtion, or Fido the wonder dog, well that is an architect or designer decision.
Tony
Greetings one and all:
How does one decompose a system where the various components of the system are not independent? By this I mean a system where any change in one component effects other components of the system.
Regards;
Zarfman
Zarfman:
Are you talking about decomposing a systems analysis or a systems design?
I am a Business Analyst; I decompose the required behavior of businesses, both implemented manually or by automation.
Whenever I hear the word "component", it generally means the discussion is about design. Here all I recommend is the basic principle of structured systems design: Components should be highly cohesive (singular in purpose as much as possible) and loosely coupled (mimization of logical interfaces).
Obviously, if any change affects [all] the other compoents these principles where violated significantly and major redesign is required.
Tony
Tony et al:
Various contributors have written about business architects and enterprise business analysts. My understanding is these individuals attempt to analyze corporate entities.
Based on my experience corporations in general tend to be made up of management, sales, marketing, finance, accounting, treasury, engineering, production/manufacturing, R & D etc or some variation there of. I would assert that these corporate components as I tend to call them influence one another to varying degrees.
If the financial statements show that the bottom line is falling, how does the analyst figure out what caused the decline? Given these conditions perhaps decomposition has some sort of practical limit. I’ve been in these situations and solving them is not a trivial task.
However, I may wandered into some parallel universe and this is not the type of problem you’re discussing. If so let me know.
Regards,
Zarfman
Zarfman:
As I am sure you know, analysis is a big part of problem definition. Key is to know what analysis is. It is very surprising how very few BA's know this. If one looks up the word "analysis" in a dictionary, chances are that the first listed definition will read something like: "Analysis: Partitioninig an entity into its components and examing how the components interrelate".
Business systems are especially hard to partition as they can not be seen nor felt (only the mechanisms used to impelement them can). So business analysis is largely all about partitioning, leading to effective decomposition. To ponder the practical limits of decompostion is to ponder the limits of business analysis.
How far should decomposition (partitioning) go? That can vary. The Yourdon data flow diagramming method recommends decomposition down to a level where one can describe the internal processing logic of processes/functions using a 8 1/2" x 11" piece of paper.
But for Agile projects, that much decompostion is not needed.
Parallel universe? I'm in Cleveland.
Tony
Only registered users may post comments.
|