three common features for any systems or applications
"Eight techniques" and "three architecture goals" are good, but they are not the best ways to communicate to users and the management. To do that, we need a "simplified feature oriented approach", hence, "three common features" for any systems or applications.
1. REGRESSION TESTING (scripted testing, automated testing).
2. Reliable and flexible SECURITY-AUTHORIZATION.
3. Reliable and flexible SECURITY-AUDITING (it is code-based, i.e. not database system based) .
“Common” implies it is “architecture”; however, “features” means we insist on a “feature-oriented” or “XP style” approach. Note that those features are extremely useful for themselves – they are more ubiquitous than you think; further, those three features will lead to the body of the iceberg -- yes, I am saying they are just the tip: a comprehensive architecture can “naturally” emerge in the process of handling those three features, in an XP style: piece by piece, just do what is absolutely necessary for now, today. How? Because regression testing means pushing all business logic to the business layer, it immediately means custom class (or dataset with strong separation of UI and business layer) and databining. Reliable and flexible security-authorization immediately means centralized security checking, which means AOP façades or even AOP properties. Reliable and flexible security-auditing immediately means wrapping the database access layer.
So, those “three common features” directly lead to “three (architecture) goals” and “eight techniques”.
Because they are “feature oriented”, instead of “architecture oriented” or “technique/technology oriented” I will begin to use them as my top level thinking. This is important when we talk to users or management: users or management do not care “architecture” or “technique/technology”, they only care “features” (and rightly so). As a result, we must constantly train ourselves to use “feature oriented” languages – I guess this is the very core spirit of XP.
posted by survic at
3:59 PM
4 Comments:
You may say that security can be seen as a feature; testing is not. However, most power users know the power of testing and can easily accept that as a feature -- once you can show the differences in a smaller trial project. The reason: if developers cannot do regression testing, it means power users have to it themselves, manually! How about QA? OK, QA can certainly make things a little better (but with cost and time), but it does not change the big picture – in other words, we all know that power users are the final “QA”.
I ask myself, is it just a word game to use UP under the name of XP? No. The differences from UP are as follows: (a) I have very limited number of “architecture features” (only three!); (b) when we do those three, they are not treated as just “back-end”, they must be directly usable. For example, testing must begin the cycle of testing and deployment, and power users must be involved; security-auditing must be usable to show who did what; and security-authorization must be usable, and can adapt to changes along the way.
Also, those things are done, iteratively, together with other features. The design are done within a few hours or days; so, absolutely no “architecture paralysis”.
I changed the blog's wording a little bit. I begin to use the concept of "common features". I have to change the blog itself, because it is important, while at the same time, it create too much distraction to create another blog.
Post a Comment
Subscribe to Post Comments [Atom]
<< Home