I really liked learning the SunTone Architecture Methodology – specifically the SunTone cube, which helped me visualize and make connections to infrastructure. What I liked less is the focus on Java design patterns, some of which are outdated, and a focus on (although a little understandably) Sun technology. The problem is these days – knowing the Sun way of doing things (EJB3, JSF, etc) is not the only choice. There is definitely a gap there for a more comprehensive Java Architecture course that comprises of all mainstream Java technology and help make the choices between them. Overall, I found that it was a good opportunity to focus and learn for a week on architecture and design. I’m glad to find that UML is still relevant in the face of agile development, although people haven’t talked about it much in more than 10 years.

SunTone Architecture Methodology
To aid in the development of enterprise applications, Sun Java Center formulated the SunTone Architecture Methodology (SunTone AM) in the late 90’s. Enhancing RUP with the SunTone cube, it has now evolved to have more agile influences. SunTone AM introduced the SunTone cube to describe primary concerns in enterprise applications. The three faces on the cube represented layers, tiers, and systemic qualities.

Layers
Layers are usually in the domain of infrastructure architects, where the application sits on top of infrastructure components.

• Application – software
• Virtual Platform – interfaces to the middleware for decoupling
• Application Infrastructure – middleware
• Enterprise Services – OS
• Compute & Storage – hardware
• Network Infrastructure – network

Tiers
Tiers are well-known to application architects. They describe how an application is decomposed into modules to reduce coupling and enhance system flexibility. Annoyingly, tiers are sometimes called layers, when not in the context of SunTone.

• Client Tier – browsers, standalone clients
• Web Presentation Tier – HTTP requests
• Business Tier
• Integration Tier – interfaces with resources
• Resource Tier – DBMS, mainframe, EIS

Systemic Qualities
Systemic qualities help establish the quality of service that a system can deliver. Different systemic qualities impose different constraints on the design of a system. This list correlates to Non-Functional Requirements (NFR) that when prioritized help make choices in system design that take quality, time, and costs into consideration.

• Manifest Qualities
  • Performance
  • Reliability
  • Availability
  • Usability
• Operational Qualities
  • Throughput
  • Manageability
  • Security
  • Serviceability
  • Testability
• Developmental Qualities
  • Realizability
  • Planability
• Evolutionary Qualities
  • Scability
  • Maintainability
  • Extensibility
  • Flexibility

The Multiple Choice Exam
A lot of passing the exam has to do with learning the terminology.
The multiple choice exam tests knowledge from roughly 8 areas:

1. Application Design Concepts + Principles
   • encapsulation, inheritance, separation of concerns
2. Common Architectures
   • 2-tier, 3-tier, multi-tier, rich clients vs. browser/thin clients, web services
3. Integration + Messaging
   • communication w/ external systems, WS+XML over HTTP, JCA, JMS
4. Business Tier Technology
   • Enterprise Beans, Enterprise Classes, Stateful/Stateless Session Beans, Message Driven Beans
   • CMP/BMP, JDO, JPA, ORM, DAO, JDBC, JAX WS, EJB 3.0
5. Web Tier
   • Web Framework, JSPs, Servlets , JSF
6. Applicability of J2EE Technology
   • Designing modular solutions, SOA, measuring NFR, refactoring
7. Design Patterns
   • GoF Design Patterns
   • Core J2EE Design Patterns
8. Security
   • Client-side security: WebStart, applet deployment
   • potential threats
   • encryption, hash, SHA, asymmetric vs symmetric
   • JAAS

Resources

• SunTone Architecture Methodology
• The Java EE 5 Tutorial
• Gang of Four Design Patterns
• Core J2EE Design Patterns

• people
• teams
• projects
• requirements
• architecture
• modeling
• testing
• documentation
• process
• knowledge
• outsourcing
• tools

From the above, I believe that teamwork and testing are becoming increasingly relevant and valuable in our professional.
I must agree with him that these topics were either not taught at all or they were not taught very effectively due to the lack of focus given to these “non-technical” topics (with the exception of architecture – which usually didn’t get ). At least that was how it was when I was at university (I graduated in 1996 at U.C. Berkeley). Perhaps there is more focus on them these days. At that time, they were starting to realize that being able to work in a group is important for the students into workplace. So they started putting people in groups to do assignments. I believe in teamwork because it is better for the company as a whole. A team that can work together and share knowledge amongst members is more valuable to the company than an individual who is supposedly `really good´. If this individual does not share his/her knowledge, then the company gets only limited benefits of the individual’s potential. In a story that I heard from Jeff Sutherland – one of the creators of Scrum – the combined effort of a team out-performed the effort of a ‘really good’ individual – an individual considered 5 times as good as the other team members. This performance was measured when the Scrum master kicked the ‘really good’ individual out of the team. Turned out that he was disrupting the performance of the other team members by refusing to work together with them.

Another topic is increasingly relevant these days for a developer is testing. Again, testing is hardly ever taught in school. I’m glad to see as over the years testing has become more and more prominent. Any developer that does not know or does not care about testing is definitely old-school and out-dated. A good developer cares about about writing testable code and has is equipped with a list of testing tools in his skillset.

Here are some of the great quotes from the talk:
A fool with a tool is still a fool but a dangerous fool
Tools are not enough, but proper use of the tools is what is important. Companies often decide on new tools without investing in training for these tools.

Software is developed by people not by process and tools
I have been always saying about agile is that it puts the human element back into software development. That is the really that it has an effect on motivating people. Feedback motivates people. Doing a good job motivates people.

Software development is like a football game – lose together or win together
When you play football, you don’t say, “I did great – I scored 3 goals – but the goalie, he let in 5 goals – he’s terrible.” Either you win as a team or lose as a team. Winning or losing may come down to your ability to work as a team.

Think big, build incrementally
This reminds me of the discussion about whether people prefer to use user stories or use cases in agile. A good explanation of the difference highlights the reservation that people have about user stories as being too narrowly focused. With requirements as with architecture, it is important not only to keep the big picture in mind, but to find a good balance between the big picture and the details. Some companies have a good grip on the big picture, while losing sight of the details, while some other companies focus on the detail without a big picture, resulting with an inflexible system.

Architecture without executable code is a hallucination
This is something that I feel strongly about. I call myself a hands-on architect – perhaps I should call it non-ivory-tower architect. The real world is not perfect like it seems from the ivory tower. Architecture is only valuable when it has been proven. Ivar says: Start by building a skinny system to demonstrate that all critical risks have been eliminated.

Law of Nature: People don’t read documentation
Only write the essentials and leave room for conversations and self-discovery later. In school, we are taught to think for ourselves, but often in the workplace, especially a big company, we are asked on our first day to read endless documentation. Honestly, I do a skim through of the table of contents and maybe the first pages. It is a pain to read through a big document. Write down the essentials with attention to bringing across the main ideas in a few words as possible.

The smart way to do testing: We are all testers!
Clean up after ourselves. Testers are the real thinkers.

I really agree with what Ivar ended the talk with:

We cannot all be equally smart, but we can all become smarter.

You got a team of people, so why not make sure everyone is working at their best potential.