Training Course - Real Life Enterprise System Design

I am offering a training course on real life enterprise system design from this month.

This course discusses fundamentals of software design principles and patterns, and the focus will be the practical aspects of design patterns. We are going to review UML from a practical point of view, and will examine some of the widely applicable object oriented design guidelines and principles. The main body of this course will explore the most popular GoF design patterns and J2EE patterns, and examine how they are used in popular Java based software, and investigate how they should be used to address Java based enterprise systems design and architecture challenges. We are going to examine the implementations of several successful open source constructions: Jakarta Commons Chain and Pool, OpenSymphony xWork and SiteMesh etc.. We will also cite intensively examples from JDK and J2EE implementations and specifications for the same purpose. For the benefit of students’ career development, we are also going to discuss how design fits into the various processes in software engineering, and the current trends in software industry as far as patterns, design and architecture are concerned.

This is NOT the usual course about design pattern concepts. While it certainly helps to prepare for the Sun Enterprise Architect for Java Platform certification, we intend for it to be really helpful to the real life and daily practices of developers, designer and architects.

The ultimate goal is to help software engineers to design and develop better software. After the course, it is expected that participants will be able to

(1) To fully master the classical design principles and patterns
(2) To thoroughly understand couple of popular and powerful software constructions
(3) To be able to use those design principles and patterns in real life scenarios
(4) To understand the context in which design and architecture happens

I hope this course will play a role in upgrading technical professionals from coder to developer, for developer to designer, from designer to architect, and play a role in starting and establishing a great career in software industry. I intend for this course to be helpful to developers, designers and architects at all levels, from beginner to senior!

The following is an outline of topics I am going to discuss:

1. UML Primer
2. Design Goals and Guidelines
3. Design Principles
4. Best Practices and Packaging
5. Design Patterns Overview
6. Factory Method,Abstract Factory, Singleton and Monostate, Service Locator, Object Pool and Jakarta Commons Pool
7. Composite, Decorator and Open Symphony SiteMesh
8. Static and Dynamic Proxy, Memoization, Virtual Proxy and Lazy Load
9. Façade and Session Facade
10. Iterator and Value List Handler
11. Command, Chain of Responsibility, its implementation in Commons Chain
12. Mediator, Observer and Service Activator
13. State and Strategy
14. Template Method, Visitor and MVC
15. Patterns, Farmeworks and Real Life Enterprise System Design
16. Appendix I: Data Access Object
17. Appendix II: ThreadLocal, Context Object and OGNL
18. Appendix III: Open Symphony xWork
19. Appendix IV: Other GoF Patterns

This course will be the base for a further, more advanced course on enterprise system design and architecture: Architectural Concerns in Enterprise Systems. In this second course, I will discuss several constructions and techniques widely used in enterprise system such as Configuration, Manageability, Callback, Cache, Clustering, Lazy Load, Bulk Data Access, Pool, IoC, AOP and Byte Code Engineering etc.. We will again use open source software as examples to explore the rationales, implementations and usages of those constructions and techniques. This second course will open shortly and people interested in it are encouraged to take this real-life enterprise system design course first.

S.S. Chern Passed Away...

The well-known mathematician S.S Chern passed away on Dec. 3rd. 2004 in Tianjin, China.

He shaped to a large extent the current state of mathematics research in China and had influenced several generations of Chinese mathematicians, among which I was a member for around 10 years..

An accomplished scholar himself, S.S. Chern established three successful research institutes in China and in U.S in a period of 50 years, and cultivated a great deal of top mathematicians across the globe.

S.S.Chern and C.N Yang represent the best examples of traditional Chinese intellectuals in modern age.

I have been always moved by those examples.

Case Studies in Systems Architecture and Design

In several previous blogs, I advocated a new way to conmunicate architecture and design knowledge in software industry. That is the case study approach, as applied in management training.

I have some spare time at this moment and decide to experiment it myself. The plan is to open a course “case studies in systems design and architecture” in the coming January.

Here are the major topics for the course: (1) some essential technologies that are more effective than others in addressing architectural concerns such as Custom Class Loader, Java Reflection, Byte Code Engineering and AOP, and how they are used to address architectural concerns; (2) design patterns at the code level and systems level, and how they contribute to solve architectural problems. The course will be driven by major architectural concerns and problems, and I will use study cases from open source, from JCP specifications, from JDK and J2EE to analyze the issues and to present the solutions.

For those interested in this course, please pay attention to my further reports on advancement in preparation here at my blog.

Training in ORM with Hibernate

I am offering a training course in ORM with Hibernate. The training intends to cover both conceptual and practical topics. Ideally after the training, participants should be able to develop typical J2EE applications hands-on with Hibernate, and become fairly knowledgeable of all the common issues working with ORM tools in general and Hibernate in particular.

The training will be code-intensive. Typically, it will require 15-20 hours, with two-third of time in lecture and the other in working with codes. Of course, I can tailor this course for specific needs if required.

Here is an outline of the topics I will cover in the training. If any reader of this blog thinks it useful, please feel free to drop me an email yang927@yahoo.com, and we can discuss further.

· Session One: ORM, Configuration & Basic Mapping
o The Case for ORM
o The Solution: Hibernate
o Hibernate Configuration
o Hibernate Type
o Basic Mapping
o Lab One: Hibernate Configuration

· Session Two: Advanced Mapping & CRUD
o Inheritance Mapping
o Collection Mapping
o Component Mapping
o Persistence Life Cycle
o Basic CRUD with Hibernate
o Code Walk Through: Inheritance Example & The Blueprint Application

· Session Three: Association, Transitive Persistence & Fetching
o Mapping Association
o Polymorphic Association
o Transitive Persistence
o Fetching Strategies
o Code Walk Through: The Blueprint Application & Mapping Examples

· Session Four: Transaction, Caching & Queries
o Database Transaction
o Application Transaction
o Caching Theory and Practices
o Query Mechanisms
o Join and Reporting
o Architecture Review: Admin Web with & without EJB

· Session Five: Application Architecture and Development
o Hibernate in Web Container
o Hibernate in Application Server
o Development Scenarios
o Hibernate Toolset
o Lab Two: Applying Hibernate Tools

· Appendix: Advanced Topics
o Natural and Composite Key
o Legacy Data
o Trigger and Stored Procedure
o Hibernate Interceptor
o Demonstration: Various Examples

To Be a Good Project Manager

Question: Tell me the most difficult parts about managing a product launch? Look for deep insight into and understanding of PM issues - i.e. dealing with scarce resources, feature creep, etc.

Answer: My experience is consistent with the CHAOS reports from the Standish Group. The major issues deciding software project failure and success are (1) user engagement; (2) executive support; (3) clear business objectives.

In addition to those, I also feel the knowledge gap between business people or management and technical team plays a role. The issue is either business people or management mandate technical solutions for the technical team or technical decisions are not aligned with business strategy.

While processes such as RUP or XP can help to guide development efforts, people in my opinion are the most important factor to be considered in software project management. To certain degree, software development is still an art compared to a standardized activity as in manufacture. Along the same line, the culture of the operating company plays a major role. Any specific project management activity or practice has to be fine tuned with those factors in the operational context.

As far as resources and deadline are concerned, here is my observation: the various estimation method may give a project manager some hints, but only the real-life experience, and the complete knowledge of the team profile can give a project manager the peace of mind. Only knowing the issues, knowing the options for solutions, and knowing the strengths and weaknesses of people in the team can give a project manager the precise estimation. To get rid of all the issues with scarce resources and deadline, a project manager needs to get the estimation right in the first place. Otherwise, whatever the project manager is going to do is really making up for his mistake, and what to be cautioned in this situation is not to blame the team, unreasonably push the team. Instead, the project manager should demonstrate the professional integrity and confront the reality, try to balance the various pillars: scope, resources and quality etc., or to adjust technical implementation strategy (a technically savvy project manager should know all the options available to him and should know the consequences as a result of adopting a specific strategy).

Here comes my conclusion: an ideal technical program manager should have solid technical skills, outstanding leadership, should be savvy in business. It is not enough to just have project management knowledge or general management skills.

Spring Framework: Why the Momentum?

Spring Framework is the solution to several long-existing and tough problems facing the business and technology community.

The first problem is this. J2EE particularly with technologies such as EJB and JCA was designed from the very beginning to solve problems in enterprise systems; while enterprise systems as imaged by the designers of J2EE exist in reality and are of critical importance to businesses, they are by a great deal of measures only of a small portion of development projects. For majority of the requirements, J2EE is too heavy a solution for too light a problem. The consequences are (1) qualified resources are always in short supply and (2) therefore most of the projects are failing because not many developers are in full control of the J2EE technologies. To this, Spring Framework’s answer is “let us go to basics, and there are plenty of technologies that are more than enough to solve your problems.

The second problem associated with J2EE as practiced now is more intrinsic to the technologies themselves. That is, the missing of object-oriented paradigm.
Object oriented paradigm obviously has its credentials to dominate the computing industries since 1980s, EJB’s losing of object oriented features, and its lack of a better replacement essentially render the industry into a situation of giving up too much without gaining enough compensation. It is probably the underlying reason why Spring Framework, and for this matter, the whole light weighted container movement, is securing great momentum. They have lots of goals to achieve, but to rescue the advantages of object oriented paradigm turns out to be most appealing.

To be fair with the old J2EE technologies, Spring Framework is not only building its strength upon J2EE’s shortcomings (or failures as some extremists like to claim). Spring Framework has its own contributions to Java/J2EE community. Two aspects deserve mentioning here.

One is to codify best practices of Java application development. Rod Johnson and his people are all real-life developers working on application developments themselves, comparing to those who start their careers as so-called system developer and never solve a single business problem with their systems. Real life developers are closer to the problems domain, and in Spring Framework Rod Johnson and his people share a lot of their hard-learnt lessons and experiences. It looks like their experiences are not measured by “years” as our lovely human resources people do, but by something you and I as developers care, or something the senior management should really care.

The second strength Spring Framework provides is to make into a consistent whole of all the popular and wide-used Java tool offerings in open sources. Most of those tools address particularly well for their specific concerns, it is time to combine them seamlessly together and to come up a total solution. Spring Framework tried on this and obviously has done this well. Associated with this point is that, Spring Framework is a framework that concerns with building applications, and is not one that lays at a lower layer concerning with system issues. In other words, it is an application framework, not a system framework. For most of developers, application framework is certainly more interesting.

As always, for the sake of my professional integrity, I need to make a disclaimer here. Spring Framework has its values, but it is not a solution for all application system problems; and I certainly think J2EE as advocated by the big vendors such as Sun, IBM, Bea and Oracle etc. is good and important, and for most of the high-end requirements, it is probably the only feasible solution.

Random Thoughts on Game Theory

I first met Game Theory 15 years ago as a college student majoring in applied mathematics. Back then, there were so many interesting things an ambitious young student could pursue; game theory did not have my attention for a long time.

Recently, I got some spare time to pick up the book “Thinking Strategically” by Profs. Dixit and Nalebuff. At this moment when I finish reading this book, I would say this is my most pleasant intellectual experience since I left campus.

Game theory is a major topic in economic study, and is also gaining momentums in business and management education recently. I would like to go a little bit further than most of other people would feel comfortable by claiming that, game theory is the scientific research of wisdom in its rational aspect.

I happen to read Stephen Covey new book “The 8th Habit” at the same time. It reminds me Dr. Convey’s most influential old book “The Seven Habits of Highly Effective People”. People knowing game theory can immediately put the 7 habits in the context of game theory. For example, “begin with the end in mind” is nothing but the principle of “looking ahead and reasoning back”; “Think Win/Win” appeals directly to the major topic of “Prisoners’ Dilemma” in game theory, or why co-operation is a better option than applying your dominant strategy.

There is another business bestseller for quite a while, “The Tipping Point”. It is obvious that the most rigorous explanation of tipping point is in game theory: the tipping point is the boundary beyond which one equilibrium state will collapse and the system moves to a new equilibrium state.

In business, “leverage” is a widely used term; but most of cases it is mis-used. To identify the opportunity for leverage and to catch the opportunity by making the non-intuitive right decision are everything but easy. It is in game theory that leverage is best defined and only by putting it into the context of game theory can leverage be mastered.

As a professional in software industry, I am interested in software project management. Looking from the game theory point of view, we may find lot of teachings in “conflict management”, “team building” and “motivation and incentives” etc.. need to be re-examined or more precisely explored. For example, we talk about conflict resolution methods such as “ Confronting”, “Compromising”, “Smoothing”, “Forcing” and “Avoiding”, and most of the existing literature only point out those methods and the consequence of applying them. We seldom see any discussion on what method should be used in what situation and how to avoid the non-intended consequences. But those topics are really the most important concerns to practicing project managers. I believe game theory provides a great framework to analyze and finally address those concerns efficiently.

In the book “The War for Talents”, the authors advocate an “open and trusting” workplace. This is a teaching that we can also find in all the other business books. But in most of those books, the argument, if any, is based on empirical evidence. Again, game theory can provide us with real insights here. Simply speaking, an open and trusting workplace is to remove the “prison” in the “Prisoners’ Dilemma”, therefore, people can engage in cooperation instead of always adopting their “dominant strategy”, which unfortunately is not necessarily the best for the business, or for anyone as part of the business.

In business environment, “team” is a buzz word, and nobody dares to challenge it. After seeing so many bad things are carried out under the name of “team work”, every time when I talk about “team work”, I usually add something like “in its positive sense”. Among those bad things, there certainly are purely evil actions from wrecked minds, there is one phenomenon which game theory essentially indicates as unavoidable and therefore should be tolerated: “the exploitation of the great by the small (Mancur Olson)”. In “Thinking Strategically”, the authors suggest that “find a large benefactor who act cooperatively and tolerates others cheating”. The lesson here is that complete fairness may not be a proper ultimate goal, and those great should be ready to contribute more. I guess this is what we label as “noble”.

It is just encouraging to see the fine art of wisdom becomes a science. Strategy is usually associated with experience, which actually means long enough time of “trial and error”. Once again, I am convinced that so many things that are categorized as “experience” can really be gained quickly without the prohibition of time if only you know how!