A Developer's OOA for Being a Business System Analyst and Why Use Cases Are Important After All

A Developer's OOA for Being a Business System Analyst


------------------------------------------------
A. The Qestions


Recently, I am considering two questions:

1. What is the advantage of a developer being a business system analyst?
2. What is the advantage of object-oriented analysis (OOA)?

Those two questions are related: OOA can be mastered by a developer; therefore, a developer can be a good business system analyst.

I must immediately indicate that this does not mean a non-developer business analyst cannot master OOA. We must remember that the origin of OO concepts (Object-Oriented concepts) is from AI (Artificial Intelligence), which is modeled after natural human thinking. A lot of non-developer business analysts are talented natural OOA thinkers. Further, developer business system analysts must work with non-developer analysts – it is team work, and people must learn from each other: typically, developer analysts will learn a lot of domain knowledge from non-developer analysts; and non-developer analysts will learn a lot of programming knowledge and formal OOA techniques from developer analysts.

Having said the above, the focus of this blog is to point out what developer analysts can contribute to an analyst team, because this aspect is not often said.



------------------------------------------------
B. When


Before I start, I want to point out when this contribution can be especially important. It is after the main architecture is decided, designed, implemented, and completed. After the main architecture is done, the major focuses of all projects are analysis. However, architecture is a continuous effort. In the context that major architecture effort is completed, and analysis is the focus, it is important that there is a built-in mechanism within analysis to address architecture issues (i.e., “derivative requirements”, “architecture requirements”). Again, this “built-in” mechanism is not crucial when the architecture is actively being designed and implemented; however, it is critical afterwards.

For outsourcing projects, customization projects, and configuration projects, it is often that we are in such a situation that the architecture is “completed”. Further, because the completed architecture is not done by the same team or developers who are doing the “configuration” development, for those projects, it is especially important that the analysis explicitly consider and specify architecture requirements.


------------------------------------------------
C. The Answer


Now, let's start. My central argument is that developers’ OOA experience is formal, structured, and intensive; as a result, when developers use OOA to do business system analysis, they can be more focused and more efficient. Immediately I want to point out that being more focused and efficient is not necessarily more effective. Again, it is team work of all analysts, both non-developer-analysts and developer-analysts.


An OOA developer analyst can immediately abstract “use cases” from mockups, and is capable of directly using database tables as “glossary” and use the data as “examples” of the “concepts”. As a result, they can think “use cases” and “entity objects” simultaneously and systematically, and reach a proper abstraction very fast. This is the root cause of many other good things:

(a) They can think about automated (i.e. not screen oriented) testing from the very beginning. Because tests are more dynamic and cover more combinations of scenarios, they help them to get the right level of abstraction faster.

(b) They can think about the “boundary” situations and testing data from the very beginning.

(c) As a result of the above, the result of the analysis is easier to be designed and implemented by developers. Further, because of the right level of abstraction, the implementation will be more stable.

(d) Note that “workflows” and “things” are not as abstract as “use cases” and “entities”, as a result, the latter two have more abstraction power.

(e) Developer analysts read books like “Analysis Pattern”, which can be a rich and power source of right abstractions.



------------------------------------------------
D. Non-OOA (VB6) Paradigm Is Bad


VB6 paradigm is from VB6, and OOA/OOD cannot originate from VB6. However, OOA/OOD can be applied to classic VB development – I know this because I have been doing that for more than 10 years, applying OOA/OOD in C++/Java to classic VB. However, that should be the reason to underestimate how harmful classic VB paradigm can be. Do no make the mistake I made!

Also, non-OOA developers can be business system analysts. However, they have less advantages, and worse, are less compatible with non-developer analysts, because OOA is more “natural”. I know it can be counter-intuitive -- Java/C# are more advanced, however, they are also more accessible to common sense business people.

Many VB6 developers do not know and cannot know OOA. I did not realize this clearly until recently. Note that I used VB6, however, I have been used C++, Java, and .Net the same time when I use VB6. I did not realize the big difference between using-VB6-only and using VB6 as a scaled down version of Java. One important element that I now realize this is from the blog discussion with Vikas (http://survic.blogspot.com/2006/07/domain-modeling-or-data-modeling.html).

Vikas emphasized the difference between OO domain entity model and database design. I did not feel that way, and, frankly, from pure know-how point of view, I currently still do not. However, now I realize that conceptually the difference is indeed critical. I now also understand why Rocky (http://www.lhotka.net/weblog/) emphasizes OO so much. Those are the veterans of fighting old VB6 mindset. I was just too naïve -- I have to admit that. OO is not as easy and natural as I thought it was to a VB6 programmer who had never touched other programming languages before -- even he/she is very intelligent and very smart, and is an excellent VB6 programmer. OO thinking is a paradigm shift.

This revelation hits me very hard. Now I am more a UP guy than a XP guy, simply because XP does not emphasize OO that much – XP almost lets you feel that it can be anybody’s tool, regardless OO or not. As a result, it is more adaptable as a methodology; however, that kind of suggestion that you can do programming without OO is very harmful. Note that I know in XP, you have some OOA/OOD techniques by using some cards. However, that is simply not the mainstream thing nowadays.

http://survic.blogspot.com/2007/01/18-best-practices-from-systematic.htmlhttp://survic.blogspot.com/2007/01/why-up-is-important-and-why-use-cases.html

The “using UP to fight VB6 paradigm” happens so fast, now, I even need to reject my very recent stand saying that “use case” is not important. Again, from know-how point of view, mockups are more important, and the formalities of "use cases" are harmful. However, from conceptual point of view, “use case” is crucial (see below for why). Also, “use case” is better than XP’s “story”, because “use case” implies there is an “OO” context.

You may ask, come on, what is exactly wrong with VB6 or non-OO, especially at the analysis stage? To be frank, it is a paradigm shift, so, it is the whole thing. However, we can still enumerate some.

The most obvious thing is that they are always overly enthusiastic about some implementation details too soon and too much. Such an attitude makes a lot of VB6 developer be incapable of learning "big techniques", and incapable of handling large projects that needs real team work.

The second most obvious thing is actually very ironical: they do not have “concepts” (i.e., objects) in their thinking (only some interweaved “algorithms”), therefore, they cannot use database tables as the concepts, therefore, they treat database and (testing) data separate from serious programming thinking. The last step is the irony: VB6 is supposedly always integrated with database. How to “explain” the irony? If the project is small enough, and the database is technologically bound (pun intended) by those notorious pre-.net data-binding techniques, then, VB6 is great, for anything beyond that kind of toy-like thing, VB6, its paradigm, and its developers create big messes.

In practice (i.e. at know-how level), entity models can be simplified to such a degree that it does not need any effort after you have a good database (the core of my previous arguments). However, conceptually (i.e., logically), they are extremely important – they are the most important thing in enterprise programming. I now agree with Vikas and Rocky totally about it. Again, I disagreed with them in the past, because I did not realize how harmful VB6 paradigm can be, and how much inertia the VB6 paradigm can be.