8 OTTEC (123 Enterprise Computing) Issues
Enterprise Computing (EC) has been the niche of the Java platform; its sweet spot is to have at least three developers, three months development, and thirty end users -- I made the numbers up, but you got the idea.
OTT stands for, well, real simple, "One-Two-Three", which refers to "one developer, two weeks development, and three end users". Obviously, it is about small applications. Traditionally, it is the niche of "departmental computing", in which classic VB is the king.
However, in hindsight, we now know better. OTT is still enterprise computing, for the following reasons:
(a) Many OTT products (or subsystems) consist of bigger systems, and they are mission critical;
(b) An OTT will have a long lifecycle time, during which it usually grows; and even it does not, its maintenance and small enhancements will cost resources and time far more than "one-two-three".
So, OTT is OTT Enterprise Computing, hence OTTEC (or, 123 enterprise computing).
Neither classic VB nor Java can handle OTTEC. Note that I am not talking about the languages per se; I am not even talking about the platforms. I am talking about the techniques and cultures that are carried with VB and Java. To carry out OTTEC, we need C#. It will borrow techniques from lightweight Java world (i.e. non-J2EE world), and will push those techniques to their lightweight extremes. Just to be fair to classic VB, I want to point out again that classic VB was the king of the OTT niche; as a result, classic VB carries the right culture for the sense of how "heavy" the techniques should be.
Note that VB.net is functionally the same as C#. We can use either VB.net or C# for OTTEC. It seems that it is inevitable that we will use both VB.net and C#. For a team, you may feel that you can "standardize" on one language. Then, very soon you may find that you need to use an in-house or an open source product, that uses precisely the language other than you have standardized! As a result, it is inevitable that a competent programmer should know both.
Having said that, I guess we need to know that OTTEC requires borrow and modify techniques from Java, and C# is very close to Java, both syntax-wise and community-wise -- most (but not all though) first-generation open source projects in .net are ported from Java and are in C#.
However, there are some good open source projects originated from VB.net, one prominent example is CSLA, http://www.lhotka.net/ArticleIndex.aspx?area=CSLA%20.NET (CSLA has C# version also).
OK, you may say, enough concepts, tell us about those "techniques from lightweight Java world" and how can we push those techniques to their lightweight extremes.
Before doing that, I need to list eight issues that those techniques try to solve. After all, techniques are just the "means" to some "ends"; and we need to know those "ends" first. However, I also noticed that some of those eight items sound more like techniques, instead of "ends" -- in "technical" context, it is not easy to tell apart "techniques" and "ends" -- let's assume we can justify that they are "ends" by themselves.
1. Have flexible logging
2. Wrap database access
3. Centralize transaction handling
4. Centralize communication handling ("remoting")
5. Centralize security handling
6. Centralize logging (this is different from flexible logging)
7. Separate UI and business logic completely
8. Have automated unit testing for business logic
I will not elaborate why we need to solve those issues. For that, please read any articles that essentially describe "lessons learned" in classic VB projects, and read those articles that essentially recommend "frameworks used" in Java projects. Note that in the latter category, the articles usually say how "lightweight" they are. However, if you used classic VB, or/and if you did some OTTEC, you know that they are still too heavy. That leads to my next post -- to be continued.
P.S.
Why OTTEC is important? -- if you know the importance of classic VB in a company (regardless what Java, perl, or C/C++ people have told you), you know the importance of OTTEC; and wait, there is more. Once we can do OTTEC in .net, and apply good Enterprise Computing techniques, then, we can divide bigger projects into many OTTEC projects. Then, more than 80% of Enterprise Computing are OTTEC! Effectively, this is an extreme vision/version of Extreme Programming (Test Driven Development).
Since we are talking about XP/TDD, I should point out one thing: because OTTEC is so lightweight, although it is double "extreme" of XP, it "cuts corners" (or, “lightweightize”) on some of its "extreme" techniques. For example, in OTTEC, there is no need and no time to unit testing UI; and there is no need and time to use mock objects, since we do not do intensive framework development and the testing is relatively coarse grained -- typically, only those facade methods are unit tested, and the testing purposefully includes database access code. Therefore, mock objects are not necessary. Also, because the code in unit testing does not use mock objects; the code is more ready to be pasted in UI code. This means there is no “extra” time that is “wasted” in unit testing – in OTTEC, every minute counts.
Note that this does not mean you do not need to know mock objects. When you use frameworks, you got to run their unit tests, and so you got to know mock objects. Also, to take full advantage of the nature of open source, to be a competent user, you got to be a contributor, therefore, you got to use mock object to develop frameworks or tools.
OTTEC is flyweight XP/TDD. Note that for XPers orTDDers, it may sound paradoxical; becuase they are used to feel that they are the most agile doves; and now, here are the flies ;-)
posted by survic at
11:19 PM
4 Comments:
Interesting. Waiting for the post about the techniques. Do you have some code?
I have a lot of code :-) I need to put them in context; hence the blog. Stay tuned; right back with a lot of code.
As an OTTEC practitioner, I do not re-invent frameworks. I just use them. If I feel I need to do some framework development, I participate those projects. I do not mix OTTEC and framework developments.
Before I put out my own code, you can get warm-ups by getting familiar with the following tools and frameworks:
Log4net
http://logging.apache.org/log4net/
MS application blocks (a.k.a. enterprise library), the data access block
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/entlib.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/EntLib2.asp
Nhibernate
http://www.hibernate.org/343.html
Springframework
http://www.springframework.net/
Casltle framework
http://www.castleproject.org/index.php/Main_Page
CSLA framework
http://www.lhotka.net/ArticleIndex.aspx?area=CSLA%20.NET
Nunit
http://www.nunit.org/
It sounds like that you believe many tiny small projects are the norm, or even the preferred mode, for enterprise computing. I do not agree. This is actually downside of TDD, or, I should say, the impression I get from TDD.
To do enterprise computing, you need architecture design.
Architecture Design via Configuring Open Source Frameworks, Design and Coding
Architecture design can be done by “configuring” well-known open source frameworks.
Because they are well-known, as a result, your design is “only” a “metaphor”, and can be easily understood and remembered by team members.
Note that other than “architecture design”, the difference between “design” and “coding” should be reexamined. We all know that designing screens is certainly a kind of coding. The same applies to designing database tables and business classes. To me, because we have mature visual programming IDEs; because we have mature and reliable reverse engineering tools; and because we have more and better forward engineering tools; as a result, the difference between diagrammatic “design” and “coding” is really not that significant and relevant anymore.
More elaboration on “configuring” well-known open source frameworks:
(a) By using the word “configuring”, I want to remind us that as “application” developers using C#, VB, Java, or Perl, we are competing with another “strategic” option: on-shelve systems. Further, I feel that the best way to compete with on-shelve systems is to learn from it. However, before I point out the “learning” part, I want to say that nowadays general purpose development platforms like .Net and Java are so powerful, for most companies, it makes less and less sense to use on-shelve software systems. However, if you observe carefully, you will find that although inflexible by-design, on-shelve systems are pretty powerful; and their power comes from their predefined architectures.
So, here is a prediction or hope: once most people realize that several well-known open source frameworks have already solved almost all of the architecture design issues for almost all systems, in-house developments can then compete with those on-shelve systems even on the strongest aspect of them: time -- we can develop a system at the same timeframe as to “configure” a on-shelve system.
(b) By “configuring”, I do not intend to trivialize “architecture design”. I whole-heartedly agree that “architecture design” is the most important thing in any development in enterprise computing. However, I do feel that the “architecture design” should be less time consuming -- it is simply wrong to spend a lot of time on "architecture design" for a certain project. Too many projects are paralyzed because of that.
(c) However, at the same time, I believe “configuring” is much more difficult than “pure” design. Too often people believe that as long as they have some experiences, and know some principles of object oriented design, plus a few dozens of design patterns, then, they are set for architecture design. I say no. It is not even close. Before doing architecture design, the designers (senior developers, team leads, or architects) must know several open source frameworks inside out – they must know how to use them; how to develop them from their core to non-essential parts; how to tear them apart and put different parts together.
(d) Why only open source projects -- isn’t that too limiting? No and no. You can certainly add more proprietary frameworks on the table. However, any proprietary products must be compared with related open source projects. There are two reasons for this: (i) open source projects are free; (ii) open source projects have source code, so, you can study them thoroughly and contribute to them, or simply change them in your products.
I will add more open source projects to my list; I will also add some proprietary products. However, I do want to point out that, believe it or not, the list I have given is indeed the “core”.
(e) Now, let's return to the original topic: the vision that many tiny projects consist of an enterprise system.
Once we know that “architecture design” is intense but rapid, and tend to converge; once we know that those swarms of nano-flies have build-in homing calls, and can interface with each other; then, there is no reason to worry. In TDD terms, this means we develop in vertical slices. This does not mean we do not have horizontal systems; it is just that the horizontal systems are designed and adopted rapidly, and are configured and enhanced incrementally. Sounds impossible? Let’s see! Surprising? Yes. It simply means we need new techniques: logging, wrapping, IoC, AOP, custom classes, custom class data binding, and façade unit testing …, stay tuned.
Post a Comment
Subscribe to Post Comments [Atom]
<< Home